What is an ERP migration?
An ERP migration is the project of moving a company off its existing systems — often a patchwork of legacy software, spreadsheets, and acquired companies' separate platforms — onto a single enterprise resource planning (ERP) system. An ERP is the operational backbone: it runs finance, supply chain, inventory, order management, and often HR from one connected data model, so the business records every transaction once and reports from a single source.
For a portfolio company, an ERP migration is rarely an end in itself. It is the plumbing that makes other value-creation levers possible. Reliable financial reporting, a working KPI dashboard, shared services, procurement consolidation, and clean integration of bolt-ons all depend on the underlying data being consistent — which is exactly what a single ERP provides and a fragmented systems landscape prevents.
It is also one of the highest-risk operational projects a company can undertake. Migrations are expensive, long, and disruptive; a botched cutover can stop a company from invoicing, shipping, or closing its books. The phrase carries an implicit warning in operating circles for that reason.
How an ERP migration runs
A migration moves through a disciplined sequence, and skipping steps is how they fail.
- Design and process mapping. Decide how the business will actually run on the new system. The hard choice here is whether to adopt the software's standard processes or customize the software to existing ones — customization raises cost and risk.
- Data cleansing and mapping. Old data is almost always dirty. It must be cleaned, deduplicated, and mapped to the new structure, because migrating bad data simply reproduces the old mess in a new system.
- Configuration and build. Set up the system to the agreed design, build integrations to other tools, and document the new process.
- Testing. Run the business's real transactions through the system in test cycles — including the month-end close — until it behaves correctly under load.
- Cutover. Switch from old to new, either all at once (big bang) or in phases. This is the moment of maximum risk.
- Stabilization. Support the organization heavily after go-live, fixing issues and retraining until the system runs cleanly.
Most overruns trace to underestimating data cleansing and change management — the human work of getting people to actually use the system as designed.
Why ERP migrations overrun and how to de-risk them
ERP projects have a reputation for blowing past budget and timeline, and the causes are consistent: scope creep from over-customization, underestimated data problems, weak change management, and an aggressive cutover with no fallback. The cost is not only the project budget — a failed go-live can directly disrupt revenue and the ability to close the books.
The levers that de-risk a migration are unglamorous: adopt standard processes wherever the business can tolerate them, invest early and seriously in data quality, test against real transactions including period close, and treat training and adoption as a core workstream rather than an afterthought. A phased cutover with the ability to fall back trades a little speed for a lot of safety. The discipline is the same point every time — the technology rarely fails; the process and the data do.