The ERP project looked close to finished.
Development was done. Integrations were connected. Most users had completed training. The production environment was ready.
Then we ran the final readiness review.
The go-live moved by six weeks.
Not because of one catastrophic bug.
Because several small risks we had accepted for months finally became impossible to ignore.
Note: This is a representative ERP implementation post-mortem. The timeline and examples are illustrative, not customer production data.
The Original Plan
The final weeks looked simple:
Finish UAT
↓
Final data migration
↓
Cutover rehearsal
↓
Business sign-off
↓
Go live
But each step depended on the one before it actually being complete.
That was our first mistake.
We planned around dates.
We should have planned around exit criteria.
Problem #1: UAT Was “Almost Done”
The dashboard showed:
UAT: 92% complete
That sounded good.
It was not.
The missing 8% included:
- month-end finance scenarios,
- partial order cancellations,
- inventory adjustments,
- credit processing,
- exception workflows.
These were not edge cases we could safely ignore.
They were business processes.
The lesson was simple:
A test cycle is not complete because most test cases passed.
It is complete when critical business processes are tested, defects are resolved or formally accepted, and the business signs off.
Current ERP implementation guidance similarly treats UAT completion and stakeholder approval as explicit go-live readiness conditions.
Problem #2: The Data Migration Did Not Fit the Cutover Window
Our migration scripts worked.
That was not the problem.
The problem was time.
The cutover window allowed roughly:
10 hours
Our latest migration rehearsal took:
14 hours 40 minutes
Technically successful.
Operationally unusable.
We found several causes:
- slow transformation jobs,
- unnecessary historical records,
- sequential loads that could be reorganized,
- reconciliation happening too late,
- failed records requiring manual investigation.
The next dry runs became timed rehearsals:
Extract
↓
Transform
↓
Load
↓
Reconcile
↓
Business validation
A migration is not ready because it works.
It must also work inside the real cutover window.
A strong ERP data migration strategy should include repeated trial loads, reconciliation, realistic-volume testing, cutover timing, and clear rollback criteria.
Repeated migration rehearsals and validation are specifically recommended before production cutover.
Problem #3: Integrations Passed Functional Tests but Failed at Volume
One integration worked perfectly when we sent ten transactions.
Then we tested production-like traffic.
Queues started growing.
Retries increased.
One downstream service slowed the entire chain.
ERP
↓
Integration Layer
↓
Warehouse
↓
Carrier
↓
ERP confirmation
The happy path worked.
The production workload did not.
This is why ERP system integration testing needs to cover realistic transaction volumes, queue behavior, retries, external dependencies, and failure recovery—not just basic connectivity.
We had tested:
Does the integration work?
We had not tested enough:
Does it still work when hundreds or thousands of transactions arrive together?
That difference contributed directly to the ERP go live delay.
Integration testing should include realistic peak volumes and external-system failure scenarios, not only basic connectivity.
Problem #4: Data Reconciliation Was Still Manual
Our migration technically loaded the expected number of records.
But record count was not enough.
For inventory, finance, and open transactions, we needed to prove:
Source
=
Target
at the correct business level.
That meant comparing things like:
- inventory quantity by SKU and location,
- open purchase order value,
- customer balances,
- vendor balances,
- journal totals,
- open sales orders.
A migration could contain the correct number of records and still contain incorrect values.
We automated more of the reconciliation and turned unexplained differences into blockers.
Problem #5: The Cutover Plan Had Tasks but Not Enough Decisions
Our first cutover plan looked detailed.
It had timestamps.
Owners.
Tasks.
Dependencies.
But it was missing something critical:
decision points.
For example:
02:00 — Final migration complete
02:30 — Reconciliation
03:00 — Integration validation
03:30 — Business verification
But what happened if reconciliation failed?
Who decided whether to continue?
How much variance was acceptable?
When did rollback become mandatory?
The improved runbook included explicit gates:
Migration complete?
↓
Data reconciled?
↓
Critical integrations healthy?
↓
Business processes validated?
↓
GO / NO-GO
A cutover runbook needs verification, sign-off, roles, dependencies, and rollback criteria—not just a task list.
Why It Became Six Weeks
No single issue required six weeks.
The combination did.
The additional time went into roughly four areas:
| Area | Work Required |
|---|---|
| UAT | Finish critical scenarios and resolve blockers |
| Data | Optimize migration and repeat reconciliation |
| Integrations | Test at production-like volume |
| Cutover | Rehearse the complete runbook again |
We also used the time to finish:
- production support procedures,
- user access validation,
- monitoring,
- rollback planning,
- business communication.
The delay was painful.
But going live with unresolved issues would have been worse.
The Second Cutover Rehearsal Changed Everything
We treated the next mock cutover like production.
Same sequence.
Similar data volume.
Same teams.
Same dependencies.
Same validation steps.
The result looked very different:
Migration within window PASS
Reconciliation PASS
Critical integrations PASS
UAT blockers 0
Production access PASS
Support team ready PASS
Rollback procedure VERIFIED
Only then did the date become credible.
Mock cutovers are valuable precisely because they test the whole transition rather than individual technical components in isolation.
What We Got Wrong
The biggest mistakes were not deeply technical.
We Treated the Go-Live Date as Fixed
The date became more important than readiness.
We Counted Progress Instead of Risk
“92% UAT complete” sounded reassuring while critical scenarios were still untested.
We Tested Components Individually
Migration worked.
Integrations worked.
ERP worked.
But we had not rehearsed the complete operating system enough.
We Accepted “Almost Ready”
Almost ready multiplied across five workstreams becomes very far from ready.
What Changed
For the second attempt, go-live required explicit evidence.
UAT signed off
✓
Migration fits window
✓
Data reconciled
✓
Integrations tested at volume
✓
Critical defects closed
✓
Users and security validated
✓
Support team ready
✓
Cutover rehearsed
✓
Rollback tested
✓
No green check meant no go-live.
That made discussions much easier.
Instead of asking:
Do we feel ready?
we asked:
Which exit criterion is still open?
The Biggest Lesson
The six-week delay was not created during the final readiness review.
It was created gradually.
Every time we said:
We'll finish that later.
we borrowed time from cutover.
Every incomplete test.
Every unresolved data issue.
Every integration assumption.
Every undocumented rollback decision.
Eventually, all of that debt became visible at once.
Final Takeaway
An ERP go live delay is rarely caused by a single dramatic failure.
More often, it is the result of several workstreams reaching the finish line at 90–95% readiness.
And in an ERP implementation, 95% ready can still mean:
Finance cannot close.
Inventory does not reconcile.
Orders cannot ship.
Users cannot access the right functions.
Integrations fail under load.
The most important lesson from the six-week slip was simple:
Go-live is not a calendar date. It is a readiness state.
Set measurable exit criteria.
Rehearse the full cutover.
Test with realistic data and volume.
Make unresolved critical risks visible.
And let readiness determine the date—not the other way around.
Top comments (0)