What hypercare is, and how to run one that ends on time
What a hypercare period is, how long it should last, which metrics decide when it ends, and how to staff it as volumes change.
Hypercare is the elevated support period immediately after a system goes live: extra people, faster response, and daily monitoring, for a defined window. It exists because the days after a cutover behave nothing like normal operations, and treating them as though they do is how a good go-live turns into a bad quarter.
What makes it different from normal support
- Volumes are far higher, as every edge case in the business meets the new system at once.
- The people who built the system are still available, which will not be true in a month.
- Users are learning, so a large share of tickets are questions rather than defects.
- Triage is faster and less formal, because a queue designed for steady state will not cope.
The last point is the one most often missed. Hypercare needs its own triage path. Routing a go-live spike through the standard service desk process is how a two-day problem becomes a two-week one.
How long it should last
Thirty days is the common default, and it is a reasonable starting assumption for a significant system change. Smaller releases might need a week; a core platform migration across multiple regions might need longer.
The more important point is that the length should be decided by exit criteria, not by the calendar. A period that ends on day 30 because it was scheduled to end on day 30, with sixty open tickets and two severity-one defects outstanding, has not ended. It has been renamed.
The metrics that make the decision for you
Track a single record per day, split by severity: tickets raised, tickets resolved, open count, and resolution rate.
Then set the status thresholds before go-live, while nobody is under pressure. A workable set: stable at 90% resolution or above, monitoring between 70% and 89%, critical below 70%.
The value of deciding thresholds in advance is that it removes the argument. On day nine, when the number reads 71%, it is far better to have agreed in advance what 71% means than to negotiate it in a room full of tired people.
Keep the record honest
A reopened ticket is a ticket raised. Resolution rates that improve because tickets were closed optimistically are worse than no metric at all, because they produce confident decisions based on a fiction.
Exit criteria worth using
Define what "done" means before you start. A defensible set looks like this:
- A run of consecutive stable days (five is a common choice) rather than a single good day.
- Zero open severity-one defects.
- The daily ticket rate down to a level normal support can absorb.
- Any workaround still in place has a documented owner and a permanent fix scheduled.
That last one prevents the most common quiet failure: exiting hypercare with three manual workarounds nobody wrote down, which become permanent by default.
Staffing as the shape changes
The instinct is to taper everyone together at a fixed point, usually the start of week three. The data rarely supports doing it that way.
What typically happens is that severity-one defects vanish quickly while low-severity tickets and user questions keep arriving at a steady rate. Those need different people. Tapering senior engineers while holding analyst capacity flat matches the actual shape of the work, and it is usually cheaper than a uniform taper that leaves the queue growing.
Let the daily record tell you which. That is what it is for.
How this works in Depentra
The Hypercare template arrives with a day-by-day incident log, severity tracking, a tickets-per-day chart and the exit criteria that end the period, so the daily record exists from day one rather than being built in the middle of a cutover.