How to Plan an ERP Migration Step by Step

A successful ERP migration is not a single brave leap. It is a sequence of controlled steps, each with a clear output and a gate before the next begins. The teams that treat it that way go live with far less drama than the ones that treat the whole thing as one optimistic sprint. What follows is the plan I use, the order that works, and the mistakes to avoid at each gate. The Project Management Institute frames work like this as a sequence of controlled phases, each with a defined gate, which is the structure you will recognise below.

Assess what you actually have

Every plan starts with an honest baseline, not a vendor meeting. Inventory what you run, the modules, the customisations, the integrations, the users, the data, and the business processes each one supports. This is where you discover the three part-numbering schemes and the ten-year-old report nobody knows how to maintain. A good assessment is the cheapest insurance you will buy, and it is the foundation for the cost model you build next. If you are not sure the move makes sense at all, pause here and read whether your business is ready to migrate.

Build the honest business case

With the baseline in hand, build the case in real numbers. What does the current system cost to run and maintain? What is waiting it cost you, the subject of the cost of waiting another year? What would the new platform genuinely improve? Be honest that the case may not stand on savings alone, because it rarely does. It stands on risk removed, agility gained and cost avoided. Present the whole picture to the board, not just the tidy headline.

Select and contract

Vendor and product selection is where the plan can go wrong before it begins, usually by choosing on the demo rather than the fit. Score candidates against your assessed requirements, not against how the sales cycle felt. When you contract, protect yourself in the small print: realistic timelines, a change process that does not punish you, exit terms and data portability, and a definition of done you and the vendor both sign. The same care goes into choosing your implementation approach, because it shapes how the whole delivery is governed.

Data, in parallel, from day one

The single most valuable planning decision is to start data work on day one and run it in parallel with selection and build. Profile, clean and validate master data while the vendor demo is still running, because data is the line that most often breaks the schedule and the budget. This is not a step to defer until "build time", it is a full pillar of the plan from the start. The method is in our guide to cleaning master data before you migrate.

Build, then test, then test again

During the build phase, hold scope with a change board and keep the integration work honest. Then resist the universal temptation to compress testing to protect the date. Plan a full test cycle: unit, integration, end-to-end and user acceptance, each with business sign-off. Compressing testing does not save time, it moves the problems past go-live, where they are dearer to fix. This is the phase where realism is installed and optimism is retired, and it is the discipline explored in how to avoid costly mistakes.

The best-planned migration I was part of was also the most boring, which is the highest compliment a programme can earn. Every gate had its sign-off, every test cycle ran to its full length, and go-live was a quiet weekend. The plan worked because the team treated each step as a contract to be fulfilled, not a suggestion to be optimised at the last minute.

Plan cutover and stabilisation

Cutover is a plan of its own, and it deserves a rehearsal. Freeze data, run parallel processes, agree the rollback criteria, and be explicit about who decides to abort. Then, critically, plan what happens after go-live. The first 30 to 90 days of stabilisation are when the real issues surface, and they need a dedicated support team and a fix cycle rather than a generic "post-implementation review" in a month. A realistic timeline for all of this is covered in how long a replacement takes.

Follow these steps in order, keep each gate honest, and the migration becomes a heavy lift executed well rather than a gamble. The teams that skip steps to save time usually spend more clearing up the consequences, which is the quiet story behind most of the failure statistics in why ERP projects fail.

Frequently asked questions

Sources and further reading