Reactive to planned: the ERP migration that paid for itself

Most ERP migrations fail. Not spectacularly, usually. They just quietly cost more than expected, deliver less than promised, and leave everyone slightly worse off and unwilling to say so out loud.

Ours did not, and I want to be honest about why, because it was not because we were smarter. It was because we were clear about the one thing the migration was actually for.

The reason we did it was simple. Our maintenance was reactive. A charger went down, someone called, we scrambled. That works at small scale and it is a slow-motion disaster at large scale. Every reactive callout is more expensive than a planned one, harder to schedule, and worse for the client, who now associates the product with breaking. We needed to get ahead of the failures instead of chasing them.

To do that we needed systems that could actually hold the data: assets, service history, contracts, scheduling, the financial view underneath all of it. That meant implementing Salesforce for the customer and service side and NetSuite for the financial and operational backbone.

Here is what it was really like.

Why most of them fail

Most ERP migrations fail because they are sold as a technology project when they are a business change project wearing a technology costume.

The software is not the hard part. Configuring the software is not even the hard part. The hard part is that an ERP encodes how your business actually works, and most businesses do not agree on how they actually work. The migration forces that disagreement into the open, and if leadership treats it as an IT task and delegates it accordingly, nobody with the authority to settle those disagreements is in the room.

The second reason they fail is that people try to migrate the mess. They take every quirk, exception, and workaround from the old way of doing things and faithfully rebuild it in the new system. Now you have paid a lot of money to make your existing chaos more expensive to maintain.

We tried to avoid both. We treated it as a business change with a technology component, and we used the migration as a forcing function to fix the mess instead of preserving it.

The messy middle nobody warns you about

Everybody plans the start and imagines the end. Almost nobody plans for the middle, and the middle is where these things die.

The middle is the period where the old system is being retired and the new one is not fully trusted yet, so people run both. They enter data twice, because they do not believe the new one. They keep their private spreadsheets, because those spreadsheets have never let them down. Data lives in two places, drifts out of sync, and every discrepancy becomes evidence that the new system is broken.

That period is longer than you think and more fragile than you plan for. It is where the goodwill you built at kickoff gets spent. People are doing more work, not less, and the promised benefits are still theoretical. If you have not warned them that this valley is coming and that it is temporary, they will conclude the whole thing was a mistake right at the point of maximum pain.

The thing that got us through was being relentless about killing the old ways of working on a firm date rather than letting them coexist indefinitely. As long as the old spreadsheet is allowed to exist, it will be the thing people fall back to, and the new system never becomes the source of truth. You have to close the exit. That is uncomfortable and it is the only thing that works.

What it cost

More than the licence fees, which is the number everyone anchors on and the least important one.

The real cost was in people's time and attention during the migration. Configuring the system properly, cleaning data that had years of rot in it, running two ways of working through the messy middle, retraining people on processes they thought they already knew. That cost is real and it lands on your best people, because they are the ones who understand the current process well enough to help rebuild it. For a stretch, your most capable people are half-deployed on the migration instead of the work.

If you do not budget for that, you will experience it as a nasty surprise and you will be tempted to cut the corners that matter, which is exactly how you end up migrating the mess.

What it returned

Once we were through the valley, the shift from reactive to planned maintenance changed the economics of the whole service operation.

Planned maintenance is cheaper per intervention because you schedule it efficiently instead of scrambling. It catches failures before they become outages, which protects the client relationship, which protects the revenue. And the data underneath it, once it lived in one trusted place instead of a dozen spreadsheets, meant we could actually see the operation. You cannot manage what you cannot see, and for years we had been managing a service operation half-blind.

The migration paid for itself. Not on day one, and not during the messy middle when it looked like the most expensive mistake I had signed off on. But over the following period, in reduced callout costs, better asset uptime, and the ability to make decisions from real data instead of instinct, it returned more than it took. That is a rare thing to be able to say about an ERP project, and the reason we can say it is that we treated it as a business change, killed the old ways of working on a hard date, and did not flinch in the middle.

If you are about to do one

Own it as a leadership project, not an IT one. Use it to fix the mess, not to lovingly preserve it. Budget honestly for the human cost, not just the licences. Warn everyone that the middle will feel worse before it feels better, and then be the person with the nerve to hold the line when it does. Close the exit on the old way of working, or the new way never becomes real.

Do that and it can pay for itself. Skip it and you will join the majority who quietly wish they had never started.