Hypercare
Hypercare is the period of heightened support immediately after go-live, during which the delivery team stays available alongside normal support. It has a defined scope, a staffing rota, a triage and escalation route, daily reporting and written exit criteria. It ends when those criteria are met and responsibility passes wholly to the permanent support organisation.
Hypercare exists because the first weeks after a go-live produce a different kind of demand from steady-state operation: questions rather than incidents, edge cases that testing did not reach, and data conditions that only appear at real volume. The people who can answer those quickly are the ones who built the thing, and hypercare is the arrangement that keeps them available for a bounded period.
What it contains
| Element | What it defines |
|---|---|
| Scope | Which systems, processes, sites and user groups are covered, and what is explicitly out |
| Duration | A start and a planned end date, set in advance rather than open-ended |
| Staffing and rota | Named people per day, per shift, with cover for the first business day and the first period close |
| Hours of cover | The window each day, and what happens outside it |
| Triage and priority definitions | What counts as P1 to P4 in this context, which is often stricter than business as usual |
| Escalation path | Who is called, in what order, with response expectations at each level |
| Defect and query log | Every item raised, with severity, owner, workaround, fix route and status |
| Daily reporting | Volumes, open items by severity, trend, and anything needing a decision |
| Exit criteria | The measurable conditions that end the period, agreed before it starts |
| Handover | Knowledge transfer, documentation updates and the formal transfer of open items to support |
The Cutover Runbook & Hypercare Pack carries the rota, the log and the exit criteria in the same workbook as the cutover itself, which keeps the handover point visible from the start.
How it is used
The period runs on a daily rhythm: a short stand-up on the open items, triage of anything new, and a report that goes to the same audience that took the go-live decision. The reporting is what allows the exit conversation to be evidence-based — a falling trend in P1 and P2 items, no open severity-one defects, and support handling the volume without escalation.
Exit criteria are the part that requires most discipline, because they are the only mechanism that ends the arrangement. The hypercare guide covers scope, duration and the criteria that stop it running indefinitely.
Where it goes wrong
Hypercare without an end date is the standard failure. It becomes the operating model, the project cannot be closed, the costs stay open and the support organisation never takes ownership because it does not have to.
The second is a rota that exists on paper. If the named people are already on the next project, response depends on goodwill. The third is scope creep into enhancements: requests that are genuinely new requirements get fixed quietly during hypercare because it is faster than raising a change, and the baseline drifts. The fourth is no handover content — when the period ends, the support team receives a list of open tickets and no explanation of the system behind them.
The fifth is reporting that stops after the first week. Volumes are highest at the start and the daily report feels useful; by week three the numbers are smaller, the report lapses, and the exit conversation then has no trend data behind it. The exit criteria are written in terms of trend, so the reporting has to run for the whole period if it is going to answer them.
Related terms
See also early life support, service transition and go-live.
Questions
How long should hypercare last?
It is set in advance and varies with the size of the change and the business cycle. A common consideration is covering at least one full period close, so that month-end processes are exercised before the period ends.
Is hypercare the same as early life support?
The terms are frequently used interchangeably. Where organisations distinguish them, hypercare is run by the delivery team and early life support by the service organisation as it takes the system on.
Who staffs hypercare?
A named rota drawn from the delivery team, alongside the permanent support function, with the escalation path and hours of cover written down before go-live.
What ends hypercare?
The written exit criteria being met — typically no open critical defects, item volumes and severity trending down, and support handling demand without escalation to the project team.