The Go-Live Failure: How a Three-Month Delay Happens

ERP go-live failures are almost never caused by the software. The ERP works. The modules are configured. The integrations run. The failure comes from a UAT process that validates happy-path scenarios written by the implementation team, a data migration that was never properly stress-tested on full data, and a go/no-go decision made by people who did not understand the risk they were signing off on.

The pattern can be caught at three points: before build starts, by redesigning UAT; a few weeks in, by delaying go-live yourself; or not at all. This is the version where nobody catches it.

UAT that was designed to pass

Most ERP UAT processes test the scenarios the implementation team designed the system around. Business users click through flows that work correctly on clean data and controlled conditions. The scripts cover standard purchase orders, clean invoices, straightforward delivery receipts. They were written by the team that built the system, not by the people who will use it under operational pressure.

Nobody tests what happens when a purchase order has a delivery split across three partial shipments, one of which arrived before the PO was approved due to a verbal authorization that was formalized later. That scenario does not exist in the UAT script. It exists every week in production at a busy warehouse.

We now require that at least 30% of UAT test cases come directly from the operational team's list of "the weird things that happen," not from the implementation team's scope document. A logistics warehouse manager who has been processing deliveries for seven years can name fifteen edge cases in an afternoon. None of them were in the original UAT script.

The data migration that was never stress-tested

The company had 11 years of data. The migration was tested on a 5% sample. Testing on a sample when the cutover will run on the full dataset is one of the most common migration mistakes there is.

The full migration, run for the first time on go-live weekend, took 31 hours instead of the estimated 6. It also produced 4,200 records with referential integrity errors that had never appeared in the sample. The cutover window was 48 hours. By hour 36 we were triaging which errors could be fixed post-go-live and which would block operations. The AP workflow was in the second category.

The fix is not complicated: run the full migration, on full data, at least twice before go-live. The first run is a diagnostic: you find the edge cases, the timing issues, the records that break the migration scripts. The second run is a rehearsal: you know the problems and you confirm your fixes worked.

The parallel run that did not happen

The plan included a two-week parallel run, with the old and new systems operating side by side to catch differences in what each one calculated. It was cut to five days during scope negotiations because the operations team said they could not sustain double data entry for two weeks. We agreed. This was a mistake.

The parallel run caught three critical calculation differences in the last four days. If it had run for two weeks, we would have found them before go-live. Instead, we found them two weeks after go-live when a supplier payment came out wrong. The payment was for $47,000. The discrepancy was a rounding logic difference in the tax calculation that only appeared on invoices above $40,000.

The supplier got a corrected payment and the relationship survived. The cost was credibility and three painful weeks of remediation after launch. Our rule: never agree to a parallel run shorter than two weeks.

The go/no-go meeting that said go

The go/no-go meeting had 14 open issues on the tracker. Eight were rated Low, four were Medium, two were High. The project manager presented them as "manageable post-go-live items." The stakeholders nodded. We went live.

The two High issues were in the AP workflow. They had been rated High for a reason: they affected the invoice matching logic for a category of vendor invoices that represented about 40% of monthly payment volume. Everyone in the room knew they were High. Nobody wanted to delay the go-live that had already been planned, communicated, and prepped for. The pressure to go was social, not technical.

The AP workflow broke on day three when the first high-volume payment run hit the unresolved issues. The rule we use now: no High issues at go/no-go, no exceptions, no waivers. If a stakeholder wants to waive a High issue, they write it down with their name on it and a statement of what they are accepting. That piece of paper tends to end the conversation.

What a three-month delay actually costs

Extended implementation fees are the visible cost and the one that appears on invoices. The hidden costs are larger and harder to attribute.

Staff doing double data entry: four people averaging 2 extra hours per day for 11 weeks is roughly 880 person-hours. At a loaded cost of ~$40/hour, that is $35,200 in internal time that appears nowhere on a project budget. Supplier relationships strained by delayed payments during the broken AP period, with one supplier putting the account on hold for two weeks. Finance unable to close the month properly, requiring manual journal entries to reconcile the parallel period: another 120 person-hours.

A delayed go-live also delays the ROI timeline. Every month of delay is a month the efficiency gains the project was meant to deliver do not arrive. Say the project was meant to deliver $280K a year in efficiency savings. Three months of delay costs $70K in unrealized benefits on top of everything else. The fees on the invoices understate the real cost by a wide margin.

A UAT process that has never found a show-stopping issue in the first week of testing has never been properly designed. If every UAT script passes cleanly on first run, the scripts were written by people who wanted them to pass, not by people trying to break the system.