Hypercare that stabilizes the business

Go-live

I've watched a lot of go-live mornings. Someone rings a bell, there's cake, and a leadership team that's been holding its breath for two years finally exhales. I keep my own celebration short, because go-live is the first day the system runs against the real business.

Up to that point everything has been tested against assumptions: your data, your configuration, your idea of how the business runs. Hypercare is how you get through finding out which assumptions were wrong without it costing you the year.

What real hypercare looks like

What usually gets called hypercare. The project team answers email when they get a chance while everyone rolls off to the next assignment. There's a shared mailbox and a hope that volume stays manageable. Nobody owns the queue, and nobody is measured on it.

What real hypercare is. It's a staffed, funded period of elevated support and fast fixes, with people assigned full time and a route that takes an issue from a confused user on the floor to a diagnosed, fixed and communicated resolution in hours. It's planned on the assumption that things will break.

Where it hurts first Most early breakages are small and easy to miss: a tax calculation off for one population, an approval routing to someone who left, a report the controller relies on that no longer ties out. Left alone for a week, any one of them turns into a bigger problem and a harder conversation.

The first weeks

Triage on consequence

In the first weeks the queue fills faster than anyone can think. Without triage discipline the loudest issue gets worked first, and the most damaging one often sits behind it. Sort by what the issue does to the business. Ticket count and who's asking shouldn't set the order.

ClassWhat belongs hereResponse

Stops the businessPayroll can't run, orders can't ship, the close can't proceed, a regulatory filing is blockedNamed owner within the hour, worked continuously, communicated on a fixed clock whether or not there's news

Corrupts data quietlyA calculation wrong for one population, a routing rule sending approvals nowhere, an interface dropping records without erroringHighest priority after a stoppage, because every day it runs the cleanup gets bigger

Blocks one teamA role missing a permission, a report that won't render, a workflow nobody can completeSame-day workaround published, permanent fix scheduled into the next release

Friction and confusion"I can't find it," "it used to be two clicks," training gaps arriving as defectsSend to enablement instead of engineering. Heavy volume here usually points to training

The number to watch Track how many tickets turn out to be training gaps rather than defects. If that share is high and stays high, you have a training problem, and more engineering capacity won't fix it.

Week 2Demobilization

Don't demobilize too early

Letting the people who built the system leave too soon is the most expensive mistake I see in hypercare. On most programs it's the one decision I'd change.

The contracts are ending, the budget is under pressure, and the integrator wants its consultants on the next deal. Demobilizing looks like financial discipline. It usually ends up costing more.

Context: The people who designed your configuration know why a rule was written that way, which edge cases were deliberately deferred, and where the data was always going to be soft. None of that is written down anywhere.
Premium: Send them home in week two, hit a severity one in week five, and you pay a premium to bring them back. They come back slowly, and the business carries the problem until they do.
Cycles: Keep them through the first real cycles, assigned to the work and accountable for the queue. A token few on call doesn't count.

Week 2Sent home

Week 5Severity one, and a premium to bring them back

After go-live the business starts finding what the project missed. The people who can explain it are usually the ones you were about to send home.

First payroll

Stabilization is measured in cycles

A month on the calendar tells you very little. What matters is whether the business has run its real processes end to end and come out clean: payroll twice, the close twice, then the quarter.

2: payrolls, clean
2: closes, clean
1: quarter

The most exposed event on the calendar and usually the first real test.

Clean means no manual corrections outside tolerance.

Second payroll

Proves the first wasn't luck, and that retroactive handling works.

Clean means the same result without heroics.

First close

Reconciliation, allocations, and the reports the controller relies on.

Clean means it ties, on time, without a spreadsheet.

Second close

The workarounds that got you through the first one either disappear here or become permanent.

Clean means nobody is still running the old workaround on the side.

Quarter

Knowing when it's over

Hypercare should end when the evidence says so, whatever date the plan shows. Write the exit criteria before go-live, while nobody is tired or arguing, and hold to them.

Volume

Ticket volume has fallen and stayed down across two consecutive cycles
No new severity-one issues for a defined, agreed period
The backlog is shrinking, not just being reclassified

Business

Payroll has run clean twice without manual correction
A period has closed on time and reconciled
Departments have stopped running the old workaround alongside

Transition

Run support is staffed, trained and answering
Open items have a named owner in the run organization
The receiving team has signed off on the knowledge transfer

Exit, on evidence

If the exit date arrives and the criteria haven't been met, say so and extend. The alternative is finding out at the second close that stabilization never happened, after the team has already gone.

The one-page version is the companion poster, The Complete Workday Run Guide: the release year, who owns what after go-live, and what breaks when hypercare ends. Free, no form.