We are often called in after an ERP go-live has slipped once and is about to slip again. By that point the team is exhausted, the executive sponsor is defensive, and the vendor is billing overruns. The striking thing: in nearly every rescue, the causes were visible months earlier.
Reason one: data migration was treated as a technical task
Data migration is a business decision wearing a technical costume. Which of six customer records is the real one? Is that open PO from 2019 still open? Should historical pricing move at all? These questions belong to business owners, and when they're left to the migration team, the answers get made silently, badly, and late.
The fix is to run migration as its own workstream from month one, with named business owners for every data object and mock loads on a schedule. Teams that do their first full mock load three months before go-live hold their dates. Teams that do it three weeks before don't.
Reason two: the core team burned out at UAT
The same fifteen people who know the business best are asked to do their day jobs, define requirements, test every scenario and train their colleagues — for a year. UAT is where this catches up, because testing quality collapses exactly when it matters most. Backfilling the day jobs of core team members is the cheapest insurance an ERP program can buy, and almost nobody budgets for it.
Reason three: scope decisions were deferred to keep the peace
Every "we'll decide that in the next phase" is a small loan against the go-live date. The interest compounds.
Steering committees that avoid conflict early get all of it back at cutover, when deferred decisions resurface as blockers. A program with a strong decision log — every open question owned, dated and forced to a resolution — is a program that holds its date.
Reason four: cutover was planned as an afterthought
Cutover is a project of its own: sequence, freeze windows, fallback criteria, who sleeps when. The runbook needs to exist — and be rehearsed — at least twice before the real weekend. A cutover rehearsal that surfaces forty problems is not a failure; it's the entire point. The failure is discovering those forty problems live.
Reason five: go-live was defined as the end
Programs that aim at go-live fall over in hypercare, because the team mentally finished a week before the finish line and the support model starts cold. Aim at "hypercare exit criteria met" instead: ticket volumes trending down, period-end closed successfully, adoption metrics holding. Go-live is a milestone. Stability is the goal.
The plan that holds
- Migration as a first-class workstream — business-owned, mock-loaded early and often.
- A backfilled core team — budget it at kickoff, not at the crisis.
- A decision log with teeth — no unowned open questions older than two weeks.
- Two full cutover rehearsals — the second one boring.
- Hypercare exit criteria agreed up front — the date everyone actually aims at.
None of this is exotic. All of it is unglamorous, which is exactly why it gets skipped — and why the programs that do it stand out by simply finishing on the day they said they would.
