In shortBefore a Priority upgrade, plan the version path, take a verified backup, upgrade a test copy first, find exactly what's customized, compare it with the target version and fix the critical items. On the day, freeze changes and keep a rollback plan ready. Afterwards, run your test scenarios again and watch the first days closely.
Plan
- Choose the target version and the path to it. An upgrade goes through every version in between, not just the last one.
- Agree on who owns what: IT, your Priority partner, developers and key users.
- Set a budget and a downtime window, with room for fixing what you find.
- List the interfaces and external systems that talk to Priority.
Prepare
- Take a full backup, and confirm that it restores.
- Create a test environment from a copy of production.
- Inventory your customizations against a clean reference of your current version.
- Compare with the target version and grade the findings by risk.
- Fix or re-apply the critical items — in the test environment first.
- Write test scenarios with key users for the processes that matter most: orders, invoicing, inventory, month-end.
Upgrade day
- Freeze changes to production code and setup.
- Run the upgrade on the test environment first, then on production.
- Keep the rollback plan and the backup ready.
- Run a short smoke test before users return.
After the upgrade
- Run the full test scenarios again in production.
- Check interfaces and scheduled jobs.
- Watch errors and user reports closely in the first days.
- Record what changed, for the next upgrade.
Where UpgradeGuard fits
"Inventory your customizations" and "Compare with the target version" are exactly what UpgradeGuard automates: a deterministic comparison with clean reference versions, with graded findings and the reason for each.
Frequently asked questions
What causes most problems after a Priority upgrade?
Customizations to Priority's standard objects that the new version replaced or changed, and code that depends on tables and columns that changed.
Can we skip versions?
Not in the sense of avoiding their changes: an upgrade installs every version on the way, so check against each of them.
Who should be involved?
IT, your Priority partner or developers, and key users from each department, who know which processes must work on day one.
Last updated 19 October 2026.