Hypercare and the warranty period after go-live

Published 26 October 2026

Hypercare is a short period right after go-live when the people who built a system stay on hand to watch it and fix what goes wrong, faster than normal support would. The warranty period is the longer stretch, set in the contract, in which the supplier fixes defects — whatever does not do what the agreed requirements say — within the price already paid. When both end, what is left is ordinary, paid support. Below: how the three fit together, how long each lasts, how to tell a defect from a change request, hypercare exit criteria, and a hypercare plan with an example.

When the cut-off date comes, the receiving site finally receives the responsibility and their capabilities will be tested in real-life circumstances. The case studies indicate that there will be confusion and maybe even panic. This is natural.

— Šmite and Wohlin, on transferring software products at Ericsson (Journal of Software Maintenance and Evolution, 2011)

What hypercare means

Microsoft’s guide to implementing its business software: “Hypercare is a short period after go-live when you provide extra resources and attention to support your users and business processes” (Microsoft). SAP’s implementation method places it at the end of deployment — “The team also performs sustainment and hypercare activities in the Deploy phase once the system goes live” — and says the team stays “for a predetermined period of time, which is usually defined in the contract or agreed as part of the plan to transition to operations” (SAP).

The word is most used in large implementations — ERP, government systems — but the period exists in every project that goes live: the first days when real users, real data and real money meet the system. Some teams call the wider period early life support. New Zealand’s tax department, after the first release of its new tax system: “Early life support ran for 3 months with a 3-week period of enhanced support, called hyper care” (Inland Revenue).

Hypercare vs warranty vs support

“Post go-live support” is used for all of it. In a contract, it is three different things:

They overlap. Hypercare sits at the start of the warranty, and a defect found in hypercare is fixed under the warranty. What hypercare adds is speed and presence: the builders are watching, not waiting for a ticket.

How long hypercare and the warranty period last

There is no standard length; each is a number in a plan or a contract.

• Hypercare runs for weeks. New Zealand’s tax department ran three weeks of it inside three months of early life support. SAP leaves it to the contract. Microsoft’s advice is to “Decide on an end date for hypercare and have an action plan to meet the exit criteria.”
• The warranty runs for months, and the number is negotiated. One freelancer: “I usually give 3 months support & warranty period (which is billed)” (Hacker News, 2015). Another offered 60 days on a four-and-a-half-month project and was asked for twelve months (Stack Exchange, 2023). An answer to that question explains the trade: “There isn’t such a thing as free warranty, it’s just an insurance covering the risk of additional repair work, and its premium is included in the project costs” (Stack Exchange, 2023).
• Reporting windows can be shorter than the warranty. Common Paper’s standard professional services agreement has the client report a problem “within 45 days of discovering the issue”, and the supplier fix it “Within 45 days of receiving sufficient details of the warranty issue” (Common Paper).

A longer warranty costs more, because someone pays for the repair work it covers. How much repair work it covers depends on how precisely the requirements say what was promised — the next section.

Defect or change request

The warranty covers defects, so everything depends on what counts as one. Common Paper’s agreement words the promise as: “the Deliverables (if any) will conform to the requirements in the SOW”. A defect is a gap between the system and the agreed requirements. Anything else — something new, something different, something nobody wrote down — is a change request, however soon after go-live it is asked for.

The same answer to the warranty question: “If you have very clearly specified requirements where deviations can be objectively measured, you’re in a far better position than when your customer expects to get all features they didn’t initially think of implemented for free “under warranty”.”

The customer portal used across this site, in the weeks after phase 1 went live, against requirements version 1.3:

The last row is the expensive one. Where the requirements are silent, nobody can say whether it is a defect, and the warranty turns into a negotiation. Writing measurable non-functional requirements before the build is what keeps that row short; the decision log is where the answer goes when it comes up anyway.

Hypercare exit criteria

Hypercare ends on criteria, not on a feeling that things have calmed down. Microsoft’s guidance: “Define a clear exit strategy for the end of hypercare based on meeting specific criteria. For example, you might decide to end hypercare when there are no critical issues, the key processes are running efficiently, the service level agreements (SLAs) are met, or the support team can resolve most issues without extra help.”

In practice:

• No open critical or major defects; each remaining defect has a fix date inside the warranty.
• The key processes have run for real at least once — a month-end, a payroll, a billing cycle.
• The numbers that show the system is healthy are watched every day, by someone on the client’s side.
• The support team has resolved its recent tickets without the people who built the system.
• The documents are updated with what hypercare found.
• The client confirms, in writing, that hypercare is over and what happens next.

Hypercare plan template

HYPERCARE PLAN

System:     [name], [release]
Go-live:    [date]
Hypercare:  [start] to [end]
Warranty:   [start] to [end]

1. ON HAND
   [who], [hours], [how to reach]

2. HOW TO REPORT A PROBLEM
   [channel]; include what happened,
   when, for whom, and how to repeat it

3. SEVERITY AND RESPONSE
   Critical  [definition]
             response [time]
   Major     [definition]
             response [time]
   Minor     [definition]
             fixed by [when]

4. WATCHED DAILY
   [number]   where: [dashboard]
              wrong if: [threshold]
              who: [name]

5. EXIT CRITERIA
   - [criterion]

6. AFTER HYPERCARE
   Defects:   warranty, until [date]
   Changes:   change requests
   Support:   [contract]

7. END OF HYPERCARE
   Name, role:  [   ]
   Date:        [   ]

Hypercare plan example

Phase 1 of the customer portal — customers see their invoices and pay them by card — went live on 21 May with requirements version 1.3. The project sign-off set the warranty; this is the plan for the first two weeks:

HYPERCARE PLAN

System:     Customer portal, release 2
Go-live:    21 May
Hypercare:  21 May to 4 June
Warranty:   21 May to 19 July

1. ON HAND
   Supplier tech lead and delivery
   lead, weekdays 8:00-18:00, the
   support channel; tech lead on call
   for payments until 22:00

2. HOW TO REPORT A PROBLEM
   Support channel; what happened,
   when, which customer, how to repeat

3. SEVERITY AND RESPONSE
   Critical  customers cannot pay or
             see invoices
             response 1 hour
   Major     a feature fails, with a
             workaround
             response next working day
   Minor     anything else
             fixed by an agreed date

4. WATCHED DAILY
   Payments taken vs invoices marked
   paid      wrong if: any gap
   Failed payments
             wrong if: over 2%
   Reminders sent (FR-016)
             wrong if: an invoice
             7 days overdue has none
   Payment page time (NFR-007)
             wrong if: over 2 s
   Who: client's accounts lead,
   with the tech lead until 4 June

5. EXIT CRITERIA
   - No open critical or major
     defects
   - Month-end invoice run on 31 May
     done by the accounts team
   - Payments reconciled every day for
     two weeks
   - Last 5 tickets resolved by the
     client's IT lead alone

6. AFTER HYPERCARE
   Defects:   warranty, until 19 July
              (DEF-34 by 6 June)
   Changes:   change requests (CR-9)
   Support:   monthly retainer

7. END OF HYPERCARE
   Name, role:  product owner (client)
   Date:        4 June

Two things in it are easy to leave out. Section 4 has an owner on the client’s side from the first day, so the daily check does not leave when the supplier does. And section 5 names the month-end run, the one process that has not happened before go-live and cannot be tested by clicking.

What goes wrong after go-live

The build team leaves too early. One engineer describes a pattern they have seen at more than one employer: “Queue two weeks after the August launch and some minor bug fixes, Team Awesome moved on to a new project.” The person left supporting the system “rings alarm bells about some weirdness with payment processing, etc. but is told there isn’t time to look into it”. Then: “Accounting starts reconciling things in Oct and realizes we misplaced $125k” (Hacker News, 2017). Microsoft warns of the same: without agreed expectations for the project team in hypercare, “they might be busy with the next phase of the project and resist being involved in support issues.”

Nobody is watching. One commenter on agency handovers: “Day 30 after you leave is where these fall over, and it is not the flows breaking. It is that nobody is watching the numbers any more.” Their fix: “So hand over the watch with the work. 5 numbers, where each one lives, what counts as wrong, and who looks on which day” (r/agency, 2026). That is section 4 of the plan.

Support was never agreed. A developer who built a billing system for a client found that the client would not accept it as live until support was settled: “The question of providing ongoing support was never raised before an agreement to do the work was made” (Stack Exchange, 2011). As another freelancer puts it, “In the world of contracting if it’s not in the contract it doesn’t exist” (Stack Exchange, 2019).

A dip is normal, and it lasts. When responsibility moves to a new team, things slow down before they settle. A study of one Ericsson product found “an initial decline in efficiency and quality after a transfer”: releases that came twice a year took eight months, then a year (Jabangwe and Šmite, 2012). Hypercare covers the first weeks; the warranty and the support contract cover the rest.

Write it into the contract

The statement of work is where each period gets its number:

• Hypercare: how long, who is on hand, the response times, and the exit criteria.
• Warranty: when it starts — go-live or acceptance — and when it ends.
• What counts as a defect: not meeting the requirements of a named version, as accepted in the UAT sign-off.
• How to report: with enough detail to reproduce it — Common Paper’s wording is “with enough detail for Provider to understand or replicate the issue”.
• What is not covered: changes, the client’s own modifications, third-party services.
• After the warranty: the support terms, and what they cost.

Where Specroot fits

This is the problem Specroot works on: the agreed requirements — every version, every approved change, and who accepted it — kept as one record, because that record is what decides whether a report after go-live is a defect or a change. Specroot for agencies and consultancies.