# Prophet 21 Upgrade Checklist > Source: https://netray.co/tools/p21-upgrade-checklist > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: Free Tools ## Short answer A phase-by-phase checklist for upgrading Prophet 21: scope, test copy, customizations, integrations, cutover and the first week after go-live. ## Category epicor ## Erp Epicor Prophet 21 ## Industry Wholesale Distribution ## Audience - P21 administrator - IT manager - Project manager ## Tool **Kind:** checklist **Scoring Note:** Critical items are the ones that most often cause failed cutovers or a rollback. Do not schedule go-live until every critical item is done or has a written, accepted risk. **Groups:** #### 1. Planning and scope **Items:** **Text:** Confirm current version, target version and the supported upgrade path with Epicor or your partner **Critical:** true Read the release notes and list changes that affect your modules **Text:** Name a project owner, a business lead per department and a technical lead **Critical:** true Agree the cutover window with sales, warehouse and finance, avoiding month end and peak season Set a budget for testing time, partner hours and temporary backfill Check hardware, database and operating system requirements for the target version #### 2. Environments and backups **Items:** **Text:** Restore a full copy of production into a test environment **Critical:** true **Text:** Verify that production backups restore successfully, not just that they run **Critical:** true Document database size, growth and maintenance jobs before the upgrade Mask or restrict sensitive customer and bank data in the test copy Keep a frozen pre-upgrade copy for comparison and rollback reference Confirm licensing and user counts carry over to the new version #### 3. Customizations and reports **Items:** **Text:** Inventory every custom report, form, trigger, DynaChange rule and user-defined field **Critical:** true Retire anything unused so you do not test or migrate dead items **Text:** Retest custom reports against the new schema and sample data **Critical:** true Check any direct SQL views, stored procedures or Crystal-style reports for changed tables **Text:** Confirm third-party add-ons are certified for the target version **Critical:** true Record which customizations were changed or removed and why #### 4. Integrations and devices **Items:** **Text:** List every integration: EDI, ecommerce, payment, tax, shipping, punchout, BI and warehouse scanners **Critical:** true **Text:** Test each integration end to end in the test environment with real sample transactions **Critical:** true Confirm API credentials, endpoints and certificates are valid after the upgrade Test RF guns, label printers and receipt printers with the new client Roll out the new client or desktop software to a pilot group first #### 5. Testing and training **Items:** **Text:** Write test scripts for quote, order, pick, ship, invoice, receive, return, AP and AR cash application **Critical:** true **Text:** Include month end, tax, and commission or rebate runs in testing **Critical:** true Have real users run the scripts, not only IT, and log defects with owners Run a parallel check of key reports (inventory valuation, AR aging, open orders) old versus new Train users on changed screens and publish a short what-changed guide Define go and no-go criteria in writing before cutover week #### 6. Cutover and post go-live **Items:** **Text:** Freeze changes and complete a final backup immediately before cutover **Critical:** true **Text:** Document the rollback plan and the point beyond which rollback is no longer possible **Critical:** true Run the upgrade rehearsal at least once with timing recorded Verify integrations, printing and scanning before opening to all users Staff a floor-walker and a defect triage rota for the first week Review performance, error logs and scheduled jobs daily for the first two weeks Hold a lessons-learned review and update the runbook ## Content **Intro:** A Prophet 21 upgrade touches customizations, integrations, reports and every user. Most failures come from skipped testing or an unknown integration, not from the upgrade routine itself. This checklist walks the phases so nothing important is discovered on the morning of go-live. **Sections:** #### How to use the checklist **Body:** Work through the six phases in order, ticking items as they are completed and flagging those that are not applicable. Critical items are marked because they are the ones that most often cause a rollback. Use it as a shared status page in project meetings and export the result to PDF for sign-off. Run the checklist twice: once at planning to scope effort, and again before the go and no-go meeting to confirm readiness. #### Why the test copy matters most **Body:** An upgrade rehearsal on a real copy of production shows you timing, data issues and broken customizations before they affect the business. Restoring from backup also proves your backups work, which many teams have never checked. Insist that users, not just IT, test using their real daily scenarios, including edge cases like returns, special orders and drop ships. Anything that is only tested by the administrator will fail on the first real order. #### Customizations and integrations **Body:** These are the two biggest sources of surprise. A report that reads a table directly can break if the schema changes. A third-party add-on may not yet support the target version. An integration may rely on a credential or endpoint that changes. Inventory them all early, prune what is unused, and test each with real sample transactions. If a vendor cannot confirm support for the target version, that is a schedule risk to raise immediately. #### Common mistakes **Body:** Skipping month end testing is common, and the first close on the new version is the worst time to find a problem. Scheduling cutover at peak season or quarter end compresses the safety margin. Not writing down a rollback point means nobody knows when it is too late to go back. Finally, treating training as optional leaves users working around changed screens in ways that create data problems. **Cta:** If you want custom reports and queries reviewed for upgrade impact, we can help analyse your exported report and view definitions and flag the ones that need attention. **Faq:** #### How long does a Prophet 21 upgrade take? **Answer:** It depends on version gap, database size, customizations and testing depth. The technical upgrade itself may take hours, while planning and testing commonly take weeks to a few months. Allow time for at least one full rehearsal on a production copy. #### What breaks most often during an upgrade? **Answer:** Custom reports, direct database views, third-party add-ons and integrations. Standard screens usually work, but anything built on assumptions about tables, fields or endpoints needs retesting. Inventory them early so they are not discovered during cutover. #### Do I need a test environment? **Answer:** Yes. Upgrading production without a rehearsed copy is the single biggest avoidable risk. The test copy proves timing, shows customization problems, and lets users practice before go-live. #### When should I go live? **Answer:** Choose a window away from month end, quarter end, year end and your seasonal peak, with leadership available for decisions. Many distributors upgrade over a weekend with a half-day buffer before Monday opening. ## Search terms prophet 21 upgrade checklist, p21 upgrade plan, epicor p21 version upgrade, p21 upgrade testing, p21 cutover plan, erp upgrade checklist distribution, p21 customization upgrade, p21 go live checklist --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json