Sequencing an ERP Migration So It Doesn't Become a Horror Story

I've been in the room for enough ERP go-lives to have a physical reaction when a client says they want to move everything at once to hit a fiscal-year deadline. Big-bang across every module, every region, every process, on a date chosen for accounting convenience rather than readiness. It occasionally works. More often it's how a two-year program becomes a three-year program with a bruised finance team and a CFO who no longer trusts the numbers.

The order you do things in is the single biggest lever you have. Get the sequence right and problems stay small and contained. Get it wrong and they cascade.

Phase by risk, not by convenience

My default is to phase the rollout so that each stage proves something before the next one depends on it. Start with the foundational data and the core financials — general ledger, the chart of accounts, the master data everything else references. If that foundation is solid, the modules built on top of it have a chance. If it's shaky, nothing above it will hold, no matter how well configured.

Then layer functionally. Procure-to-pay, order-to-cash, and the rest come online in a sequence where each new module leans on already-stabilized ground rather than on another module that's also mid-launch. Two unstable things depending on each other is how you get a go-live weekend that stretches into a go-live fortnight.

For multi-entity or multi-country businesses, I almost always favor a pilot entity first. Pick one that's representative but not so critical that a stumble is catastrophic. Prove the template there, absorb the lessons — and there are always lessons — then roll to the rest. Yes, it takes longer on paper. In practice it's faster, because you're not debugging fundamental design flaws simultaneously across fifteen countries.

Scope discipline is the quiet hero

Here's the failure mode nobody puts in the plan: scope creep. Every stakeholder has a "small" customization they need, and each one sounds reasonable in isolation. Six months later you've built a Frankensystem that's expensive to maintain and impossible to upgrade. The discipline is to keep asking whether a request is a genuine business requirement or just how someone happens to do it today. Most "requirements" are actually habits, and habits can change more easily than software.

Adopt the standard process wherever you possibly can, and reserve customization for the places where you truly differentiate. I tell clients that every customization is a loan — you get something now and you pay interest on it at every future upgrade. Some loans are worth taking. Most aren't.

A word on the deadline. Fiscal-year cutovers are genuinely convenient for accounting, so people anchor everything to them, then compress testing when the build runs late — because testing is the one phase that feels squeezable. It isn't. Cutting test time to protect a date is how you move the problems from before go-live, where they're cheap, to after go-live, where they're expensive and public.

The through-line is simple even if the execution isn't. Solid data foundation first. Functional modules in a dependency-respecting order. A pilot before the fleet. Ruthless scope discipline throughout. Do those four things and an ERP migration becomes what it should be — a hard but manageable program, rather than the cautionary tale everyone dreads.