What are hypercare exit criteria?
Hypercare exit criteria are the written conditions that end elevated support and hand the system to normal service. They usually cover open defects by severity, incident volume over a defined period, the business cycles that must have completed at least once, support resolving tickets without project escalation, documentation handed over, and a named owner accepting the service.
What a criterion has to do
An exit criterion is only useful if two people reading it would give the same answer. "The system is stable" is a sentiment. "No open severity 1 or 2 defects, with severity defined in the support model" is a criterion. The test is whether it can be answered from a record rather than from a conversation.
Each one needs four things beside it: how it is measured, where the evidence comes from, who owns the answer, and whether it can be waived. That last column matters as much in hypercare as it does at go/no-go, because the pressure to release the team is real and it arrives before the list is clear.
The criteria that appear on most lists
| Criterion | Measured by | Owner |
|---|---|---|
| No open severity 1 or 2 defects | Defect log, filtered by severity and status | Test or defect manager |
| Incident volume within an agreed threshold for a set period | Ticket counts per day over a rolling window | Service desk manager |
| Critical business processes completed at least once | Named list of processes with a completion date against each | Business lead |
| Key business cycles run successfully | Month-end, payroll, billing or reporting run signed off | Process owner for each cycle |
| Support resolving tickets without project escalation | Proportion of tickets escalated, over a defined period | Support lead |
| Documentation and known errors handed over | Handover checklist signed | Service owner |
| Data reconciliation confirmed in live use | Post-go-live reconciliation reports within tolerance | Data lead |
| Outstanding defects transferred with owners and dates | Agreed list accepted by support | Support lead |
| Interfaces running to schedule | Job monitoring over a defined period, failures logged and resolved | Technical lead |
| Service formally accepted | Signed acceptance from the service owner | Service owner |
Not every programme needs all ten. A change that touched no financial data does not need a reconciliation criterion. What matters is that the list is written once, agreed before go-live, and not edited during hypercare by the people who want it to end.
Thresholds have to be numbers
The criteria that fail in practice are the ones with a threshold nobody agreed. "Incident volume has settled" needs a figure and a period: how many tickets per day, over how many consecutive days, counting which categories. "Support handles tickets unaided" needs a proportion and a window. Setting those numbers is a judgement your organisation makes from its own baseline, and the point of writing them down is that the judgement is made when nobody is under pressure.
The baseline is worth capturing before go-live where it exists. If the old system generated a known volume of tickets, that number gives the new one something to be compared against.
The criteria people forget
- Access and accounts. Support having the permissions to do the job without borrowing a project login.
- Monitoring handed over. Alerts routed to the team that will act on them, not to a project mailbox that stops being read.
- Run documentation. Scheduled jobs, dependencies, restart procedures and what to do when a nightly run fails — written by the people who have been doing it manually.
- Known errors. Every workaround issued during hypercare, recorded somewhere searchable rather than in the memory of one developer.
- Vendor arrangements. Support contracts live, contacts confirmed, and any warranty period distinct from hypercare with its own end date.
- Training gaps. The users who did not attend, and what has been done about them.
Most of these are handover items rather than stability items, and they are the reason hypercare exit and project closure overlap. The Cutover Runbook & Hypercare Pack keeps the criteria and the handover checklist together so neither is signed without the other.
Reviewing against the criteria
The criteria should be visible from the first day of hypercare, not produced in the final week. A short weekly review — each criterion, met or not, evidence, what would close the gap — turns the exit from an argument into an arithmetic exercise. It also surfaces the criteria that will not be met in time early enough to do something about them.
Where a criterion will not be met and the period cannot be extended, the choice is explicit: waive it with a named approver and a mitigation, or hold the exit. Both are decisions. Exiting quietly with the list unfinished is neither. The hypercare guide covers how the period is structured around that review.
What happens at exit
Exit is a handover, and it produces a record: the criteria and their final status, any waivers with approvers and mitigations, the list of open defects transferring to support with owners and target dates, and the service owner's acceptance. That record is an input to the Project Closure Report, where the remaining items become part of someone's normal backlog rather than a loose thread the project leaves behind.
Questions
When should exit criteria be written?
Before go-live, alongside the go/no-go criteria. Written during hypercare, they tend to describe the position the system happens to be in.
Who signs off the exit?
The service owner who is taking the system on. Delivery can recommend exit; the person inheriting the running of it accepts.
Can hypercare exit with open defects?
Usually yes, provided they are below the agreed severity threshold and have been formally transferred with owners and dates. Open severity 1 defects are normally a blocker.
Are exit criteria the same as go-live criteria?
No. Go-live criteria test readiness to start; exit criteria test whether the service can be run without the project team. Some items appear in both lists with different evidence.