Every ERP programme has a plan for go-live. Fewer have a plan for the Tuesday after, and almost none have one for the second year — which is where the platforms that fail actually fail.
Hypercare, and when it should end
The weeks immediately after go-live are when the system meets the cases the specification did not contain. That period needs the architects who designed it, not a support tier reading a script — because most of what arrives is not a defect but a question about intent.
The common mistake is ending hypercare on a date. It should end on evidence: at least one full month-end closed on the new system where it touches the ledger, and a full quarter where statutory reporting is involved. Ending it at four weeks because the plan said four weeks means the first close after handover becomes an incident.
The three operating models
| Model | Works when | Fails when |
|---|---|---|
| Vendor operates | No internal capability, and you want the team that built it accountable at 2 a.m. | No documentation or transfer path, so the arrangement becomes irreversible |
| You operate | The team exists and was trained during the build | The team is recruited after go-live, into a system nobody there has seen |
| Shared | Boundaries are written down — who owns what, and who is called first | Boundaries are assumed, so incidents start with a conversation about ownership |
All three work. What does not work is leaving it undecided until go-live approaches, because the answer changes how much operational tooling gets built — monitoring, admin screens, data-fix procedures. A platform designed for vendor operation and then handed to an internal team is missing the tools that team needs.
Change requests are not exceptions
They start immediately and they do not stop. A system in real use reveals what no specification could: the case that occurs twice a year, the report someone actually needed, the approval step that turned out to matter.
Treating each as an exception to a closed project produces the worst outcome — a backlog that is nobody's job, then a parallel spreadsheet, then the workaround culture the ERP was bought to remove.
Budget a change stream from the start: a known capacity, a triage cadence, and someone on the business side who prioritises it. The number matters less than the fact that it exists.
The year-two problem
Adoption rarely collapses. It erodes, and the mechanism is knowledge rather than software.
The people who knew why a module behaves as it does — the delivery lead, the internal champion, the two operators who shaped the workflow — move on. What replaces them is people who inherited a system with no explanation. The first time something is inconvenient, a spreadsheet appears beside it.
Three defences, all cheap during the build and expensive afterwards:
- Decisions recorded with their reasoning, not just the outcome. The next engineer needs the why.
- Two people internally who can explain any given module. One is a single point of failure wearing a job title.
- Runbooks for the things that recur — period close, master data changes, the annual price revision — written so someone who was not there can execute them.
What to agree before the build starts
- Who operates it, and from when.
- What hypercare covers, and the evidence that ends it.
- The support arrangement afterwards, including what is and is not in scope.
- The change-request capacity and who prioritises it.
- What handover looks like if you later want it in-house — and confirmation that the source, documentation and infrastructure definitions are already yours.
That last point is worth testing early. Ask any supplier what leaving looks like, in the first meeting, and see whether the answer is specific. A firm that makes leaving difficult has stopped competing on the work.