Hypercare After Go-Live: Scope, Duration and Exit Criteria

What hypercare covers, how long it should run, who staffs it, and the exit criteria that decide when it ends.

Hypercare is the defined period immediately after go-live during which the project team stays engaged to provide elevated support, at a higher service level than business as usual, until agreed exit criteria are met. It sits between the cutover window and the permanent support model, and it exists because a system that has just gone live behaves differently from one that has been running for six months.

It is the phase most often planned as a duration and never defined as an outcome, which is why so many hypercare periods either drift on for months or stop abruptly the day the project budget runs out.

What hypercare actually covers

Three things, and they are not the same:

• Elevated response. Shorter target response and resolution times than the standing SLA, because a defect in week one blocks people who have no workaround yet.
• Project-team availability. The people who built it are reachable. This is the part that disappears first and matters most — support cannot diagnose a new system as fast as the team that wrote it.
• Deliberate observation. Someone is watching the things that only show up in production: the first month-end, the first batch run at full volume, the first genuinely large transaction.

Hypercare is not an extension of testing, and it is not a licence to release unfinished functionality on the assumption it will be fixed later. If a defect was known before go-live and accepted, it belongs on the accepted defects list, not in hypercare.

How long should hypercare last?

There is no universal number, and any guide that gives one is guessing. The duration should be derived from the business cycle, not the calendar:

• Long enough to cover at least one full month-end or equivalent periodic process, because that is when the accounting and reporting paths get exercised for the first time.
• Long enough to cover the peak in whatever cycle the business runs — payroll, invoicing, period close, seasonal volume.
• Long enough for the support team to have handled a representative sample of incidents themselves, with the project team observing rather than resolving.

In practice this lands most IT go-lives somewhere between two and six weeks. What matters more than the number is that it is stated in advance and that everyone knows what would extend it.

Hypercare exit criteria

This is the section that gets left out. Without it, hypercare ends when someone notices the project has stopped having meetings.

Good exit criteria are measurable and agreed before go-live, when nobody has an interest in the answer:

• No open severity-1 incidents, and severity-2 incidents below an agreed count.
• Incident volume trending down for a defined number of consecutive days, rather than a single quiet day.
• The periodic process has completed successfully — month-end, batch cycle, whatever applies.
• Support has resolved a defined proportion of incidents without escalation to the project team. This is the criterion that actually tests readiness.
• Knowledge transfer complete — runbooks, known error list and configuration documentation accepted by the support team, not merely sent to them.
• Named owner accepted for the system, the documentation and the remaining open defects.

Write these down as a checklist with owners and a status column, review them weekly during hypercare, and hold a formal exit meeting. Hypercare that ends without a decision was never a phase; it was a habit.

Staffing it honestly

The common failure is planning hypercare with the same people who ran the cutover, immediately after a weekend in which they did not sleep. Assume reduced capacity in week one, and plan a rota rather than an expectation of availability.

The second failure is staffing hypercare with the project team instead of support rather than alongside it. If support does not handle incidents during hypercare, they will be handling their first one on the day the project team leaves.

What to track during hypercare

Keep it small enough that someone will maintain it daily:

• Incidents by severity, opened and closed
• Open severity-1 and severity-2 items with owner and target date
• Which incidents were resolved by support without escalation
• Progress against each exit criterion
• A short daily log — what happened, what was decided

The daily log matters more than it looks. Hypercare produces the evidence for the closure report and the lessons learned, and reconstructing it four weeks later from memory produces a much kinder account than the truth.

Common mistakes

Treating hypercare as a duration rather than a gate. Two weeks of hypercare with severity-1 defects still open is not two weeks of hypercare; it is a project that has not finished.

Ending it because the budget ended. If the money runs out before the criteria are met, that is a governance conversation, not a quiet decision.

Never telling users it ended. Users notice the change in response times whether or not you announce it. Announcing it, with the new routes to support, converts a degradation into a planned transition.

Skipping the handover to business as usual. Confirm in writing who owns the system, the open defects, the documentation and the next release. Hypercare that ends without that has not handed anything over.