Why phased ERP cutovers beat big-bang go-lives

Every ERP failure case study you read starts the same way: a confident project plan, a single go-live date, and a finance team that spent the next quarter answering audit questions instead of closing the books. The plan never says "big bang." It says "go-live." But the structure — one date, one switch, every module — is the same thing.

We don't do that. The first month-end close on a new ERP is supposed to be boring. The way you make it boring is by not moving everything at once.

What "phased" actually means

A phased cutover migrates one functional domain at a time — usually procurement first, then inventory, then finance, then sales/CRM — while the legacy system continues to operate the modules you haven't migrated yet. Every domain you move runs in parallel with the old system for at least one full close cycle before you decommission the legacy side.

The point isn't speed. The point is that if procurement reconciliation breaks, you find out before warehouse and finance are also dependent on the new system to keep the lights on.

What you give up

You give up the simplicity of a single date in the project plan. The CFO who wanted "everyone on the new system by July" now has a four-month rolling cutover. That's a real cost. We've never had a client say, after the fact, that they'd rather have had the four-month plan compressed back into a single weekend.

You also give up some integration elegance during the parallel-run window. Two systems holding overlapping data means reconciliation scripts, daily snapshot comparisons, and a couple of weeks where someone on the team is paid to spot discrepancies. We typically build the reconciliation tooling in week two of the engagement — it's not glamorous, but it's the thing that lets the next four phases happen without drama.

A real sequence

The canonical version of this was a manufacturing engagement: six legacy systems, twelve weeks, four phases.

1. Weeks 1–4 — Discovery, process mapping, and the build-out of the reconciliation harness. No production cutover yet.
2. Weeks 5–7 — Procurement migrates. New POs originate in the new ERP; legacy stays read-only for historical reference. Reconciliation runs nightly.
3. Weeks 8–9 — Inventory follows. The handshake between procurement (new) and warehouse (new) is the first time both halves of a domain pair live on the new stack.
4. Weeks 10–11 — Finance migrates. This is the one most teams want to do first because it's the most visible. It's the right one to do last, because by the time you get here, the data flowing into it has already been validated for two months.
5. Week 12 — Sales/CRM cuts over. By now the team has done this four times. Nobody panics.

The reason it works is that no single phase carries the whole risk. If procurement reconciliation is off by 0.4%, you find it in week 6, against a working legacy system, with three more phases between you and any external auditor.

When big-bang actually makes sense

It's rare, but it exists. Greenfield deployments where there's no legacy system to run in parallel can be big-bang by necessity — there's nothing to phase against. Very small companies (under ~30 users, single-entity) sometimes do fine with a single-weekend cutover because the surface area is small enough to QA exhaustively in advance. And occasionally there's a regulatory deadline that forces a single date and the trade-off is unavoidable.

For everyone else: the day you compress every module into one cutover is the day you bet the year-end close on a system nobody on your team has used in production yet. We'd rather take the four months.