ERP upgrade checklist

Any ERP

ChecklistIntermediate6 min read

In short. An upgrade is safe when you know everything you have changed, test each business process against a fresh copy of production and have a rollback plan with a deadline. The work is mostly inventory and testing, not the install itself.

Written for Administrators, report writers, developers.

The install step of an ERP upgrade is usually the shortest part. What takes the time, and what causes the problems, is everything you have built around the standard product: custom reports, business rules, integrations and forms. We use this checklist to find those pieces, test them and have them working before users log in.

It applies to a version upgrade of any ERP, on premises or hosted. For a cloud product that updates on the vendor's schedule, the same list applies to each release window, with less control over the date.

Plan the upgrade

Name the target version and the reason for it. A fix you need, a feature you want or staying on a supported release. The reason decides how much new functionality you test.
Check the supported upgrade path. Some versions cannot be reached in one jump, and each intermediate step is its own upgrade.
Check platform requirements. Operating system, database version, browser, client and third-party component versions may change with the release.
Pick the upgrade window around the business calendar. Avoid month-end, year-end, physical counts and peak season.
Name owners. One technical lead, one business lead and a tester for each process area.

Inventory what you have changed

Everything on this list is something the vendor did not test for you. NIST SP 800-128 is a useful public reference on keeping a baseline of configuration and changes.

List customizations and business rules. Code that runs inside the ERP is the most likely thing to break when the vendor changes an underlying object.
List custom reports, forms and queries. Changes to table structures, column names or report engines can break these without an error, returning wrong numbers instead.
List integrations. EDI, ecommerce, shipping, tax, payment, banking, CRM and any scripts that read or write ERP data. Note which API, file or table each one uses.
List scheduled jobs and scripts. Nightly jobs are easy to forget because nobody watches them run.
List database objects you added. Custom tables, views, triggers and stored procedures may be removed or blocked by the upgrade.
List third-party add-ons and their supported versions. An add-on vendor may need its own upgrade to match yours.
Retire what nobody uses. Every item you remove is one you do not have to test.

Read the release notes

Read the vendor's release notes for every version between yours and the target. Changes accumulate across versions you skipped.
Mark changes that touch your inventory list. Match changed areas to your customizations, reports and integrations, and flag each match for testing.
Note deprecated and removed features. Anything you rely on that is going away needs a replacement in place before the upgrade.
Note new defaults and settings. A new setting that is on by default can change behavior nobody asked to change.
List known issues and fixes. Check whether any known issue affects a process you depend on.

Prepare the test environment

Refresh the test environment from a recent production copy. Testing on old or thin data misses the edge cases that live in real transactions.
Mask or protect sensitive data if your policy requires it. A test copy of production is still production data.
Disconnect or redirect outbound integrations and email. A test system that emails real customers or sends real EDI documents causes real problems.
Upgrade the test environment the way you will upgrade production. Time each step. This run is the rehearsal for the production runbook.

Regression test by process

Write test scripts by business process, not by screen. Each script is a transaction someone runs every week, with the expected result written down before testing starts.

Process	Examples to script
Order to cash	Quote, order with special pricing, backorder, pick, ship, invoice, credit memo, cash receipt
Procure to pay	Replenishment suggestions, PO, receipt, invoice match with variance, payment
Inventory	Transfer, adjustment, cycle count, unit of measure conversion, lot or serial tracking
Pricing and rebates	Contract price, quantity break, vendor rebate accrual, customer rebate
Finance	Journal entry, period close, financial statements, bank reconciliation
Integrations	One inbound and one outbound transaction per connection
Reports and forms	Every customer-facing form, and each report finance and management rely on
Security	A sample of users per role can do their job and cannot do what they should not

Run every script and record pass or fail with evidence. A screenshot or report output makes a pass reviewable.
Compare report totals between old and new versions on the same data. A report that runs but returns different numbers is the most dangerous kind of failure.
Retest after each fix. A fix to one customization can break another.

Check performance

Time the slow, important transactions before and after. Order entry, pricing lookups, large reports and period close.
Run a batch job at production volume. Posting, invoicing and replenishment runs expose problems a single transaction will not.
Check database maintenance after the upgrade. Statistics and indexes may need rebuilding after large schema changes.

User acceptance

Have process owners run their own scripts. The people who do the work notice changes that testers miss.
Show users what changed on their screens. A short session on the changes saves a week of support calls.
Get written sign-off by process area. Sign-off is the go decision for each area, recorded before the window.

Plan the rollback

Take and test a full backup before the upgrade. Until you have restored a backup, you do not know it works.
Write the rollback steps and the deadline for using them. After users start posting transactions in the new version, rolling back means losing or re-keying that work. NIST SP 800-34 is a public reference for planning recovery.
Decide who calls the rollback and on what criteria. Agree it in advance so the decision is quick.

Communicate

Announce the window, the downtime and what users need to do. Include when to stop entering transactions and when to expect the system back.
Tell trading partners if integrations will pause. Customers and vendors on EDI or portals need to know when documents will be delayed.
Post a short list of visible changes and who to call. Users forgive change more easily when they were told first.

Upgrade and verify

Run the production upgrade from the rehearsed runbook. Record actual times and any step that differed from the rehearsal.
Run smoke tests before opening to users. One order through to invoice, one receipt, one payment and one test transaction through each critical integration.
Check scheduled jobs are enabled and running. Upgrades often disable jobs, and nobody notices until a report is missing.
Reconcile key balances. Inventory, AR, AP and the trial balance should match the pre-upgrade figures exactly.
Watch the first days closely. Hold a short daily issue review for the first week and through the first month-end close on the new version.
Update your inventory list. Record the new version, retired items and any changes made during testing, so the next upgrade starts from an accurate list.

Next steps

Start with the inventory of what you have changed. It decides the size of the testing effort, and most teams find items on it they had forgotten.