Migrating from one ERP system to another is one of the highest-risk projects a distributor can undertake. Done well, it delivers immediate improvements in accuracy, speed, and visibility. Done poorly, it creates weeks of chaos, customer complaints, and cash flow problems that take months to untangle. The difference between a good migration and a bad one is almost never the software itself. It is the preparation, planning, and disciplined execution around the change. This checklist walks through the full lifecycle of an ERP migration for a distribution business, from early planning through post-go-live stabilization.
Phase 1: Scope and planning
Before any software is selected or any data is touched, leadership needs to agree on the scope of the migration, the success criteria, and the constraints around timing. Skipping this phase is the most common cause of project failure because it leads to shifting expectations during execution. Get these decisions in writing before committing to a timeline.
- Define the business outcomes the migration must deliver (reduced order-to-cash time, better reporting, route workflow, etc.)
- Identify the systems being replaced and any systems that will continue running alongside the new ERP
- Set a target go-live window that avoids peak season and major customer commitments
- Assign a project lead with authority to make decisions and an executive sponsor who is accountable for success
- Identify subject matter experts from each functional area: order entry, warehouse, purchasing, AR, AP, and management reporting
- Agree on a budget that includes software, implementation services, data work, training, and contingency
- Document current-state workflows with enough detail that the new system can be configured to match or improve them
Phase 2: Data preparation
Data preparation is almost always underestimated. Legacy systems accumulate years of inconsistent customer records, duplicate items, inactive accounts, and historical quirks that were workarounds for old limitations. Moving this data forward without cleanup brings the problems into the new system. Cleanup should happen in the legacy system before migration, not after.
- Extract and review the customer master: merge duplicates, deactivate stale accounts, standardize addresses and contact information
- Extract and review the item master: remove obsolete SKUs, standardize naming conventions, verify unit of measure and pricing
- Extract and review the vendor master: merge duplicates, verify terms, and confirm remit-to addresses
- Clean up the chart of accounts and standardize account naming before import
- Decide what historical transaction data needs to move: typically open orders, open AR, open AP, and inventory balances as of cutover
- Document which historical data will remain in the legacy system for reference only
- Build a mapping document that connects every legacy field to its destination in the new system
- Define data validation rules that will be applied during import to catch errors before they land
Phase 3: Configuration and testing
Once data is cleaned and mapped, the new ERP needs to be configured to match your operational requirements and tested against real scenarios. Testing should use actual historical data, not artificial test cases, because artificial data hides the edge cases that cause real problems. Plan for multiple testing cycles and expect to find issues that require configuration changes or data cleanup.
- Configure the chart of accounts, customer terms, tax codes, and default settings
- Configure pricing logic, promotional pricing, and customer-specific price lists
- Configure inventory locations, replenishment rules, and reorder points
- Configure route definitions, driver assignments, and delivery workflows
- Configure AR and AP aging rules, payment processing, and bank reconciliation
- Configure user roles, permissions, and audit requirements
- Run a full transaction cycle in the test environment using real historical data
- Run parallel testing where the legacy and new systems both process the same transactions for one to two weeks
- Validate outputs: invoices, statements, route sheets, inventory reports, financial statements
- Document any gaps and either configure around them or accept them as post-go-live enhancements
Phase 4: Training
Training is where many migrations underperform. Teams spend months configuring the software and then try to train users in a few days before go-live. This never works. Training should be role-based, hands-on, and started several weeks before cutover so users have time to ask questions and build confidence.
- Identify training needs by role: order entry, warehouse staff, drivers, AR, AP, purchasing, management
- Build training materials that use real company data, not generic examples
- Run hands-on training sessions where users complete actual tasks in a test environment
- Identify power users in each department who can support peers during and after go-live
- Schedule refresher training for complex workflows just before go-live
- Create quick reference guides for the most common tasks and print them for key stations
- Plan for additional support during the first two weeks after go-live when questions peak
Phase 5: Cutover
Cutover is the moment when operations stop using the legacy system and start using the new one. Plan the cutover weekend in detail, with a clear sequence, owner for each step, and rollback plan if something goes wrong. Communicate the cutover plan to customers, vendors, and employees in advance so expectations are set.
- Freeze the legacy system at a specific moment and document the final state
- Run the final data extract and import the opening balances into the new system
- Reconcile opening balances against the legacy final state and investigate any differences before going live
- Verify AR aging, inventory balances, and open purchase orders match between systems
- Test printing on real printers, barcode scanners, and mobile devices
- Notify customers of any short-term delays or changes in invoice appearance
- Have support staff physically present on go-live day to handle immediate issues
- Document every issue that comes up with priority and owner
Phase 6: Post-go-live stabilization
The first two to four weeks after go-live are the most intense. Users are still learning, edge cases appear that were not caught in testing, and minor issues can snowball if not addressed quickly. Plan for elevated support during this window and resist the temptation to declare victory too early.
- Run daily reconciliation for the first two weeks: AR, cash, inventory, and open orders
- Hold daily standup meetings with key users to surface issues early
- Track issues in a prioritized list and resolve high-impact items within 24 hours
- Monitor month-end close carefully and validate financial reports against expectations
- Collect feedback from each role on workflow pain points and address them in a backlog
- After 30 days, conduct a retrospective with the project team to document lessons learned
- After 60 days, measure the business outcomes defined in phase 1 and report progress to leadership
Where this fits in your migration planning
Use this checklist as a starting point and adapt it to your specific business. Review ERP Implementation Guide for more detail on scope and methodology, ERP Implementation Checklist for Distributors for a complementary view, and How to Choose ERP for Distributors for evaluation guidance before the migration begins.
Related articles
Home | Blog Index