How long should hypercare last?
Hypercare lasts until its exit criteria are met. The length is driven by the business cycles the system has to complete at least once — month-end, payroll, billing, a reporting run — and by whether incident volume has settled and support can handle tickets without the project. A date without criteria gets extended; criteria without a date run on.
Why a fixed number is the wrong starting point
Hypercare is the period after go-live when the delivery team stays close to the system: elevated support, direct access to the people who built it, faster triage, and a daily rhythm of reviewing what broke. It ends when the system can be run by the team that will run it permanently.
That condition is not reached on a calendar. It is reached when the things that were going to go wrong have gone wrong at least once, been diagnosed and been documented. Choosing a duration first and hoping the system cooperates produces one of two outcomes: an extension nobody planned or budgeted, or an exit on the agreed date with the same problems still open.
The practical approach is to set both. An initial period that reflects the business cycle, and a set of exit criteria that actually govern the end. The period is what you staff and fund; the criteria are what you exit against.
What drives the length
- Business cycles. The system has to survive its first month-end, its first payroll run, its first invoice cycle, its first regulatory submission. Whatever the longest of those is, hypercare covers at least one complete instance of it.
- Defect trend. Not the count on any one day, but the direction over several days, and specifically whether new severity 1 and 2 defects have stopped appearing.
- Support capability. How many tickets support resolves without escalating to the project team. This is the measurement that tells you whether knowledge has actually transferred.
- User adoption. Whether the whole user population has used the system, or only the confident third who were in the pilot. Volume matters here: quiet weeks prove nothing.
- Seasonality. A go-live before a peak trading period, a year-end or a known demand spike carries more exposure than the same change in a quiet month.
- Scope of the change. A single application replacement behaves differently from a change that touched twenty interfaces and three business units.
The hypercare guide covers the scope and staffing side of the same question.
Tapering rather than stopping
Hypercare rarely needs the same shape throughout. A common structure is a period of intensive cover immediately after go-live, then a reduced level, then exit — each step gated by criteria rather than by the calendar.
| Stage | Typical shape | What moves it on |
|---|---|---|
| Immediate | Project team on site or on call, daily triage, direct routing to developers | No new severity 1 defects, critical processes completed once |
| Reduced | Named contacts, normal ticket routing with a fast escalation, review two or three times a week | Support resolving most tickets unaided, backlog trending down |
| Exit | Standard support model, project available only through change control | Exit criteria met and service accepted by its owner |
Tapering has a second benefit: it forces the knowledge transfer to be tested while the project team is still reachable, rather than discovered as a gap on the day they leave.
The daily rhythm that makes the length visible
Hypercare needs a short standing meeting with the same agenda: new incidents since yesterday, anything that breached its response expectation, workarounds issued, fixes released, and the current position against the exit criteria. Ten minutes of that every morning gives you a trend, and the trend is what the extension conversation should be based on.
Without it, the decision to extend gets made on impression. Someone remembers a bad Tuesday and the period runs another fortnight. The Cutover Runbook & Hypercare Pack holds the hypercare log and the exit criteria in the same workbook as the cutover itself, so the record runs continuously from the window into the weeks after it.
Budget and people
Hypercare is staffed by people who are also wanted elsewhere. If the length is open-ended, so is the cost, and the pressure to release the team arrives before the criteria are met. Two things help: funding an initial period explicitly in the business case, and agreeing in advance who approves an extension and against what evidence. The Business Case Template carries hypercare as a cost line rather than leaving it to be absorbed.
Named individuals matter more than a headcount. "Two developers" becomes nobody in particular; a rota with names, hours and a deputy is a commitment that survives someone's holiday.
Recording the end
Hypercare should stop with a decision, not by attrition. The service owner accepts the service, the outstanding defects transfer to normal support with owners and dates, the documentation and known errors are handed over, and the period is closed in writing. That record feeds directly into project closure, where the remaining items become someone else's backlog rather than a loose end.
Questions
Is hypercare the same as warranty?
No. Warranty is a contractual obligation on a supplier to fix defects for a period. Hypercare is an operating model with elevated support and direct access to the delivery team. They often overlap and are frequently confused.
Can hypercare be extended?
Yes, and it often is. What matters is that the extension is a decision with named approval and evidence behind it, rather than the team quietly staying on.
Who pays for hypercare?
Usually the project, until the exit point. Setting that boundary in advance prevents the argument that arrives when support asks why they are absorbing project defects.
What if the exit criteria are never met?
That is a finding, not a scheduling problem. It usually means defects are not being closed or the support model was never resourced to take the service on, and it needs escalating rather than extending.