The launch demo was impressive. The training was delivered. The cutover happened. Six weeks later, the controller is exporting trial balances to a spreadsheet to reconcile against the dashboard because the numbers don't match. Six months later, three of the custom modules have open bug reports nobody's fixing. The original engineer who built the integration with the legacy warehouse system left the firm in February; nobody else fully understands it. The Phase 2 conversation that was supposed to extend the system into procurement has been "next quarter" for three quarters running.
None of this looks like a failed implementation. The system is up. People log into it. Sales process closes through it. The CRM data is in there. By the metric the implementation contract used to define success — go-live on date, signed acceptance — the project succeeded. By the metric the operation uses three years later, the system has quietly stopped being trusted.
This pattern repeats often enough across the engagements we've audited, rescued, and replaced that it deserves a name. It is not technical failure. It is governance failure. The system was implemented. It was never operated.
The six failure modes
Implementation engagements that disappoint after launch share a recognisable pattern. Six failure modes show up in some combination on almost every disappointing post-mortem:
1. Stabilisation was out-of-scope
The implementation contract closed at go-live. The 6 to 12 weeks after go-live — when adoption is fragile, when reporting confidence is being earned, when the operating model is being stress-tested by real load — were not funded as part of the original scope. They became a change-order conversation that happened after the engineering team had already moved to the next project.
This is the single most common pattern. Stabilisation is the part of the engagement where the system earns trust. Treating it as out-of-scope is treating trust as out-of-scope.
2. Knowledge transfer was documented, not practiced
Documentation exists. Runbooks were written. There's a Confluence space with screenshots. The internal team has access. But the engineers who built the system never sat next to the operators who would inherit it. The pair sessions weren't scheduled. The runbook drills weren't run. The first time the internal team operated the system in production, the original team had already rotated off.
Knowledge transfer is practiced, not documented. The internal team needs to have operated each subsystem alongside the build team — not been handed a manual.
3. Custom code shipped without test coverage
Every meaningful implementation has bespoke logic — the report that reflects how the business actually works, the integration with the warehouse, the workflow that doesn't quite match the vendor's defaults. These customisations were built, demoed, signed off, and shipped. They were not covered by automated tests.
The first time a customisation needs to be refactored — to absorb a new requirement, to ship a version upgrade, to fix a bug — the engineer doing the refactor cannot prove the change doesn't break adjacent behaviour. The change either ships with risk (and breaks something), or doesn't ship (and the customisation slowly ages out of relevance).
4. Reports were built last
Reporting is the last thing built and the first thing leadership looks at. When reporting lags the rest of the build, the system ships with operational reports complete but leadership reports half-finished. The first board meeting after go-live, leadership sees numbers they don't quite trust. Trust deficit at the leadership level becomes trust deficit at every level by month six.
Reports built last is a sequencing failure. The right sequence is: leadership reports validated in parallel with the build, not after it.
5. Phase 2 was not architected
"We'll address that in Phase 2" was said in three places during Phase 1 scoping. Phase 2 was never architected — the operating model wasn't designed with room for the next wave. When the time comes to extend the system, the team discovers that the Phase 1 configuration assumed Phase 2 would never happen. Now Phase 2 looks more like a partial re-platforming than an extension.
Phase 2 is a Phase 1 deliverable. The architecture review at the close of Phase 1 must include "what does Phase 2 require us to have already built?"
6. The original engineer became a dependency
One engineer on the implementation team knew the whole system. Nobody else fully did. When that engineer left — for the next project, for the next employer, for a different role — the system inherited their absence. Escalations stalled. The bus factor on each subsystem was one.
Knowledge coverage greater than one engineer per subsystem at handoff is not a nice-to-have. It is the difference between a system that can be operated and a system that can be operated by the person who built it.
The shape of the fix
The fix is not technical. ERP implementations are not failing because the underlying software is bad. Odoo, Sage, NetSuite, Dynamics, SAP — pick one, the failure pattern is the same. The fix is the discipline that addresses the six failure modes — built into the engagement contract from day one, not retrofitted after the demo.
Five discipline commitments make the difference, in our experience:
- Stabilisation is part of the build. The 6 to 12 weeks after go-live are funded, scoped, and staffed in the original engagement. Not a change order. Not a phase. Part of the work.
- Knowledge transfer is practiced. Pair sessions, shadowing, runbook drills. The internal team operates the system in production before the build team rotates off. Knowledge coverage is greater than one engineer per subsystem at handoff.
- Customisations ship with tests. Bespoke logic is covered. Refactors are safe. Version upgrades don't terrify the team.
- Leadership reports validated before cutover. Not after. The numbers leadership sees on day one are the numbers they trusted in the dry run.
- Phase 2 architecture room is reserved during Phase 1. The next wave is planned during the current wave. The operating model has room for the additions before they're asked for.
Why this isn't standard
Most implementation contracts don't include these commitments because they cost more upfront. Stabilisation funding is six to twelve weeks of engineering on top of the build budget. Practiced knowledge transfer is engineering hours not spent shipping new features. Test coverage is engineering hours not spent shipping new features. The contract that under-scopes stabilisation looks cheaper at the signing.
It is not cheaper. It is just delayed. The engagement that skipped stabilisation will spend three times the stabilisation budget on emergency fixes in year two. The engagement that skipped knowledge transfer will pay a competing partner to re-learn the system when the original engineer leaves. The engagement that skipped test coverage will burn quarters debating whether the customisations can survive a version upgrade.
The discipline is not optional. It is just optionally visible — either funded explicitly in the engagement contract, or paid invisibly through three years of avoidable rework.
What we changed
Linescripts ships implementation engagements with these five commitments funded from day one. Stabilisation is scoped in the original contract. Knowledge transfer is practiced, not documented. Customisations ship with test coverage. Leadership reports validate before cutover. Phase 2 architecture room is reserved during Phase 1.
Three years in, the engagements that follow this pattern are the ones our clients are still operating the same system on. The engagements that started before we made these commitments are the ones we now occasionally rescue.
We did not invent this discipline. We did rename it on our own site so the contract reflects it. The page that describes it is Implementation. The principles underneath it are at How We Work. The Solution it ships on top of is ERP Systems.
If your operation has lived through one of the six failure modes — or all six — there is a path that does not require starting over. Where the existing system contains real business logic worth preserving, our System Rescue engagement starts with a forensic audit, not a rewrite. Failed implementations rarely need to be rebuilt. They need to be stabilised first.