Hypercare Plan Example: A Filled-In Plan for an ERP Go-Live

The example

A services organisation of about 1,400 users goes live with finance and procurement modules on a Monday, four days after period end. Hypercare is planned as three weeks: week one on site with heavy cover, weeks two and three remote and thinner. The table is the version reviewed at the end of week three, with the status column filled in.

Severity definitions sit above the table and are shared with the service desk: severity 1 is a stopped business process with no workaround, severity 2 is a stopped process with a workaround, severity 3 is everything else. The organisation, dates and names are invented.

Reading the example

Area

Rows follow business processes rather than the project workstreams that built them. Accounts payable is a row because a payment run either happens or does not; the interface, the data and the authorisations behind it are separate rows because they have separate owners and fail in separate ways. Fourteen rows is what it takes to cover a two-module go-live without any of them meaning "everything else".

Cover, week by week

Each cell says where, when and how many. The taper is visible: on site becomes remote, two analysts become one, and several areas become "shared", meaning one person covers three rows. Two rows break the pattern deliberately — the bank interface runs 07:00 to 19:00 in week one because payment files leave early, and the payroll interface has cover only on run day, which falls outside the three-week window entirely.

Lead and escalation

Two names per row: the person handling it and the person it goes to when it is not being handled. The escalation column is not the sponsor. It is deliberately one level up, and only the areas with financial or regulatory consequence route to a director.

Exit criterion

The load-bearing column. Each is written as an observable event with a number or a cycle attached: two payment runs, ten accepted files, a trial balance that agrees twice, one payroll run with no manual correction. Criteria written per area allow hypercare to end in pieces rather than all at once, which is what actually happens. The Cutover Runbook and Hypercare Pack carries these on their own tab with the same structure.

Status

The record of what was true at the review, including where it was not. Four rows had not met their criterion at the end of week three, and one — period-end close — could not have, because the first close falls after the planned window. That row is the reason a hypercare plan is worth writing before go-live rather than during it: the date of the first close was known months in advance, and a three-week window was never going to contain it.

What this example leaves out

There is no ticket log here. Volumes, ages, severities and who is fixing what live in the defect tracker; this plan records the shape of the cover and the conditions for ending it. Reporting the two together each week is what the weekly status report is for.

It carries no cost. Three weeks of consultants, on-site presence and vendor cover is a real number, and extending an area — as procurement and supplier data both were — spends money that was usually not in the forecast. The plan shows the extension; the budget tracker shows what it cost.

It does not define the service that follows. Exit criteria say when hypercare stops, not what business as usual looks like on the other side: support tiers, ticket routing, standing costs, who owns the system. That is a handover, and it belongs with closure and handover rather than here.

Nor does it decide anything. When four areas miss their criteria at week three, whether to extend, accept and transfer the remainder, or split the difference is a judgement for the sponsor and the service owner. The plan records the criteria, the status and the extension; the reasoning is written down elsewhere. Hypercare after go-live covers scope, duration and exit criteria in general terms.

Examples · All 36 templates