Hypercare needs an end date: closing a go-live without drifting into unpaid support
A go-live is a technical event for a few hours and a management outcome after that. Hypercare, the period of heightened support after launch, is where many good programmes lose their margin, because nobody agreed when it ends. The fix is to decide three things before cutover: who accepts the system, how long hypercare lasts, and what must be true for it to close.
First question: who signs?
Before the plan and before the estimate, I ask the client which person will accept the system and what they will need to see to say yes. When that person is named in week one, scope questions have an owner, UAT has a purpose and the business-as-usual team knows the platform will be theirs. When nobody is named, you get the familiar ending: the site is live, nobody is unhappy, and nobody will confirm it is done.
Agree the hypercare terms before cutover
Write these into the statement of work or the go-live approval, not into an email after launch.
- Duration: a fixed window, typically two to four weeks for a commerce upgrade or re-platform.
- Coverage: which hours, which time zones and which channels the team monitors.
- Severity levels and response times, so a colour change and a checkout failure are not treated the same.
- What counts as a defect versus a new request. New requests go to a change request or the backlog, not into hypercare.
- The named client owner for daily triage.
Exit criteria: what must be true to close
Hypercare ends on a date only if it also ends on conditions. These are the criteria I use; the client agrees them in advance and signs against them at the end.
Swipe the table sideways to see every column →
| Criterion | Typical threshold |
|---|---|
| Open severity 1 or 2 defects | Zero |
| Key journeys (search, cart, checkout, payment) | Stable for five consecutive business days |
| Monitoring and alerting | Handed to the client or their support partner, with access tested |
| Runbooks and release notes | Delivered and walked through with the BAU team |
| Open low-severity items | Logged in the client's backlog with owners |
| Formal acceptance | Signed by the named acceptor |
The handover document is part of the product
On the Adobe Commerce 2.4.8 upgrades for three Southeast Asian sports-retail storefronts, each brand closed with a signed BAST, the Indonesian formal handover and acceptance record. It listed what was delivered, the test evidence, known open items and who owned them from that day. It turned a vague "we are live" into a clear transfer of responsibility.
If the client cannot run the platform without you, the programme is not finished. A good handover includes access and credentials transfer, environment diagrams, deployment steps, a list of third-party extensions with their versions, and the first month of business-as-usual tickets already in the client's queue.
Why this is a commercial topic, not only a quality one
Open-ended hypercare is unpaid support. It ties up the team's best people, delays the next engagement and usually ends with a difficult conversation about who pays for the extra weeks. A fixed window with clear exit criteria protects the client too: they get focused attention when it matters, then a clean move to a support retainer priced for what they actually need.
Frequently asked questions
- What is hypercare after a go-live?
- Hypercare is a defined period of heightened support immediately after a system goes live, with closer monitoring, faster response times and daily triage. It should have a fixed duration and written exit criteria.
- How long should hypercare last?
- For most commerce upgrades and re-platforms, two to four weeks is enough. It should end when agreed criteria are met, such as zero open high-severity defects and stable key journeys for five business days.
- What should a go-live handover include?
- Formal acceptance by a named client owner, test evidence, known open items with owners, runbooks and release notes, monitoring access, environment and deployment documentation, and a walkthrough with the business-as-usual team.
If you are building or fixing a delivery organisation and want someone who has run one as a business, book 20 minutes.
Book a 20-minute intro call