The ERP Go-Live That Landed On Time and Still Failed

There is a version of an ERP program that looks like a win and is not. The go-live date holds. The dashboards are green. The steering committee gets its photo. And within two months, a good part of the business is running on the spreadsheets it used before, with the new system open in a background tab that nobody touches unless finance chases them.

This happens more than anyone admits, because the failure does not show up in any of the artifacts the project is measured by.

Two definitions of "live" that never get reconciled

Ask a technical lead what go-live means and you get a clear answer. Data migrated and reconciled. Integrations passing. Users provisioned with the right roles. Cutover complete, sign-off collected, hypercare staffed. All of that can be true and verifiable.

Ask the person who runs a warehouse, a billing team, or a sales desk what go-live means, and the answer is different. It means they can do their job at the same speed or faster than they did last week, without guessing, without workarounds, without a call to the help desk for every third transaction.

Those are two different finish lines. The program plans to the first one. The business lives in the second. Nobody reconciles them, so the gap between them becomes the place the transformation quietly dies.

Why the team declares victory anyway

The incentives point at the wrong target. A program is funded, staffed, and governed around delivery milestones. Go-live is the biggest milestone there is. Hitting it releases the budget pressure, ends the late nights, and lets consultants roll off. Everyone involved has a reason to call it done.

So the status turns green on the day the system is technically stable, and the definition of success narrows to match what was actually delivered. Adoption was never on the critical path. It was a training line item near the end, a week of sessions and a set of quick reference guides. That is not adoption. That is orientation.

The people who have to live with the outcome had no say in any of this. They were consulted for requirements, maybe, months ago. They were not designed for.

What the spreadsheet actually tells you

When a team reverts to spreadsheets after go-live, the instinct is to treat it as a discipline problem. Mandate the system. Turn off the old reports. Escalate the holdouts.

That reads the situation backwards. People do not revert to spreadsheets out of nostalgia. They revert because the spreadsheet lets them hit their number and the new process does not, or not yet. The spreadsheet is honest feedback. It is telling you exactly where the new way of working is slower, more error-prone, or missing a step that mattered.

Every one of those reversions is a design gap you can name:

• A workflow that took three clicks and now takes eleven.
• A report the business ran daily that nobody rebuilt.
• An edge case that made up a fifth of real volume and got scoped out as "rare."
• A handoff between two teams that the new roles quietly broke.

None of these show up in a technical readiness check. All of them show up in whether people use the thing.

Designing for the second finish line

Adoption is not a phase you bolt on at the end. It is a set of decisions you make from the first week, and it changes how the whole program is run.

Name who has to change and what they give up

Before a single configuration decision, get specific about which roles will work differently and what the new way costs them. If a change makes one team's day harder so another team's month closes faster, that is a real trade with a loser in it. Pretend it is not, and the loser will route around you.

Measure use, not uptime

Hypercare should not be counting tickets closed. It should be counting whether the actual transactions the business depends on are flowing through the system, by team, every day. If forty percent of orders are still landing in a spreadsheet, the system is not live no matter what the infrastructure says.

Keep an owner after the project team leaves

The project team's departure is the most dangerous moment in the whole effort. Someone inside the business has to own the adoption number after the badges are handed back, with the authority to fix process gaps as they surface. Without that, hypercare ends and the reversion begins.

The date was never the point

Hitting the go-live date proves the technology is ready. It proves nothing about whether the business has moved. Those are separate claims, and confusing them is how programs get declared successful while the value they were funded to deliver leaks away one spreadsheet at a time.

The finish line worth planning to is the day the old workarounds are gone and nobody reaches for them. That day usually arrives well after go-live, and only if someone designed for it from the start. It rarely arrives by accident.