Hypercare after go-live: how FDEs staff it and when they can leave

The system goes live on Monday morning. By Wednesday afternoon tickets are piling up, and your manager is already asking whether you can move to a new customer next week.

The right answer is rarely “yes” or “no”. It is “when the exit criteria are met”. The period between go-live and the day you actually leave is called hypercare.

An FDE who handles hypercare well does three things: agrees the exit conditions in advance, puts enough people on call, and hands over so that nothing falls between the two teams.

Duration is not yours to decide

Supportbench defines hypercare as a time-boxed stabilisation period after go-live, typically lasting 2–6 weeks. It ends when a specific set of criteria agreed in advance has been met, not when the calendar says so.

Every source gives a different figure. ERP Research says 2–8 weeks after go-live. Featurebase says most last 1–8 weeks, while complex ERP or platform migration projects can run to 12 weeks or more. A range that wide shows the number of weeks is an outcome, not something you choose up front.

What you do control is the criteria. The end point must also be clear: according to ERP Research, hypercare closes with a formal transition of long-term support to the help desk or a managed service team. Someone has to take over the system. The FDE cannot simply disappear.

Agree exit criteria before go-live

Panorama recommends setting exit criteria before go-live and using measurable indicators such as transaction accuracy, support request volume and backlog reduction. The reason is practical: after go-live everyone is tired, and criteria set then are easily bent to fit the date people want to leave.

Supportbench sets a stricter bar: every condition must hold at the same time for five consecutive business days. One concrete condition is that ticket volume stays at or below 120% of the expected BAU level. Two others concern people: every workaround is documented and has an owner, and the customer’s stakeholders sign the handover summary.

Example: an invoice reconciliation system for a finance team

Imagine you deploy an invoice reconciliation system that goes live on the 10th of the month. Before go-live, you and the head of accounting estimate BAU at about 5 tickets per business day. The 120% threshold is therefore 6 tickets a day.

Criterion	How it is measured	Threshold in the example
Ticket volume	Count per business day	No more than 6/day (120% of 5)
Transaction accuracy	Compare reconciliation results with source documents	The figure the customer agreed before go-live
Backlog	Number of open tickets	Falling week by week
Workarounds	List of workarounds	Every line has a named owner
Period close	Month-end close cycle	Runs to completion without disruption
Sign-off	Handover summary	Signed by the customer’s stakeholders

Suppose that by week three tickets have fallen to 5–6 a day. Then on Thursday they jump to 9 because of a file import bug. The five-day streak is broken and the count restarts on Friday. It is frustrating, but the rule exists precisely to stop early exits on the grounds of “nearly there”.

For systems that serve finance, Panorama’s checklist asks one more question: do close-cycle activities run without disruption?

If go-live is on the 10th, the month-end close is the first real test. Even if the five-day streak is complete before then, do not leave until the first close has finished.

Staff heavily at the start, then taper

Supportbench points to a common mistake: staffing hypercare at exactly the BAU level. It suggests a multiplier of 2.0–3.0 for weeks 1–2 and 1.3–1.5 for weeks 3–4, with daily standups in the first two weeks, then tapering off.

Do the arithmetic. If 2 people normally support this system, weeks 1–2 need 4 to 6 people and weeks 3–4 need 2.6 to 3. In practice, about 2.6 people might mean 2 full-time staff plus an FDE spending more than half the day on the system.

Featurebase stresses that hypercare works best when a specific person owns it, rather than the whole team absorbing it on top of their normal work. If you are the project’s FDE, put your name on the rota with clear hours; do not sign up on a “whoever is free takes a look” basis.

Leave gradually and hand over person to person

Featurebase advises reducing support gradually, with a log of every open risk, rather than cutting it off abruptly. One approach worth trying for FDEs: in the final week, let the help desk take primary on-call while you sit alongside, then step back a little further each day.

OneUptime is explicit: open incidents must be handed over directly from person to person; posting them in a document is not enough. So if a file import bug is still unresolved on handover day, set up a short call with the person taking over, go through the logs together, and have them confirm they own it.

Mistakes that drag hypercare out or make it fail

The most expensive mistake is leaving by the calendar: four weeks are up, so you go, whatever the ticket level. The second is setting criteria only after go-live, when everyone wants it to end. The criteria then get loosened to fit what people want.

Next comes having the whole team share the load with nobody truly owning it, then cutting support in one go without a risk log. For finance systems, there is also leaving before the first period close. Bugs that surface at close will come back to you, sometimes after you have moved to another project.

Turn hypercare into an advantage in interviews

When reading FDE job descriptions, look for phrases such as post-go-live support, hypercare or handover. If you see them, ask directly in the interview: how long will you stay with the customer after go-live, and who takes over the system after you leave?

On your CV, do not just write “post-go-live support”. Describe how you designed the exit criteria, brought ticket volume down to the BAU threshold and completed a handover signed off by the customer. Use real figures from your own project, because recruiters will ask how you measured them.

Customers rarely remember the go-live date. What they remember is the first week the system ran smoothly on its own and nobody had to call you.