The short answerCompare every procedure, trigger and SQLI program in your system with a clean reference copy of the Priority version you run today: anything that differs is your customization. Then compare those same objects with the target version to see which ones Priority also changed. The objects that both you and Priority changed are where an upgrade breaks, so review them first.
Why it's harder than it sounds
After years of development, few teams have a complete list of what they changed. Developers move on, quick fixes go undocumented, and installed Priority fixes make standard code look customized. Comparing text by hand across thousands of objects is slow, and it's easy to miss the one change that matters.
A six-step method
- Take a clean reference of your current version. You need an untouched copy of the version you run today to compare against.
- Find what's yours. Every procedure, trigger, SQLI program and column that differs from the reference is a customization — or an installed fix.
- Separate installed fixes from your own changes. Code that matches a newer Priority version is Priority's own fix, not a customization.
- Compare with the target version, and every version in between. An upgrade installs each version on the way.
- Grade by risk. Start with collisions — objects both you and Priority changed — then removed or retyped columns, then the rest.
- Review the code side by side and plan the work. Turn the findings into a work list, with an owner and a test for each item.
By hand or with a tool
By hand, this means exporting definitions from two environments and comparing them object by object, which works for a handful of objects and breaks down at hundreds. A tool can run the same comparison the same way every time, so your developers spend their time on the items that need judgment.
How UpgradeGuard does it
- A small Search Agent runs in your Priority environment and reads metadata only: the definitions of tables, columns, triggers, SQLI programs and procedures. It never writes to your database.
- The comparison with clean reference versions is deterministic code: the same inputs always give the same report. AI writes only the short Ninja Review summary at the top.
- Every difference is graded Critical, Medium, Low or Info, with the exact reason, and critical triggers come with their before-and-after code.
- Your database credentials are used only for the session and are never stored.
- Today, severity grading covers triggers and table columns. Procedures and SQLI programs that differ are listed so you can review them; they aren't graded yet.
Frequently asked questions
Do I need access to Priority's source code?
No. The comparison uses your own environment's metadata and clean reference copies of Priority versions.
Is it safe to run against a production environment?
The Search Agent only reads metadata and never writes to your Priority tables. A read-only database login is still the safest choice.
What about procedures without a severity grade?
They're listed in the report when they differ from the reference, so nothing is hidden. Grade them by hand, starting with procedures that use objects flagged as Critical.
Can I share the results with my Priority partner?
Yes. The report downloads as a PDF you can hand to your partner or development team.
Last updated 19 October 2026.