How long should ERP hypercare last?

Long enough to contain one clean instance of every business cycle that touches money or a customer promise: a payroll run, a period close, a supplier payment run, a customer invoice run and the dunning that follows it, a stock or cycle count, a return or credit note, and any statutory filing that falls inside the window. Length follows the cycles, not a fixed number of weeks. A four-week hypercare on a monthly-close business buys exactly one close, which is not enough, because the second close is the one that reveals whether the first close's manual adjustments became permanent.

When can ERP hypercare end?

When nobody can still do their job the old way. The checkable version of that test is an escape-route register: one row for every remaining route back to the old method, including legacy write access, legacy read access, the shared-drive spreadsheet, approval by email or chat, the legacy report someone still circulates, and the recurring manual journal that corrects what the subledger now produces. Hypercare ends when that register is empty, or when each remaining row carries a named executive's signature and a review date. The second period close must also be complete, executed by the client's own finance staff.

Is falling ticket volume a sign that hypercare is working?

Not on its own, because falling tickets have two opposite causes: people have learned the system, or people have stopped asking and gone around it. Never read ticket volume alone. Pair it with transaction counts per process per user inside the ERP. Tickets down and process volume at or above the pre-go-live baseline means the system is stabilising. Tickets down and process volume below baseline, or concentrated in two or three power users, means the work is happening somewhere else, and that is abandonment rather than adoption.

erpification.com · the definition, and the service

Erpification / Guides / Hypercare

What hypercare should actually cover

Hypercare ends when nobody can still do their job the old way. That test is behavioural, not technical, and it is the only one a quiet retreat to the spreadsheet cannot pass.

Guide · updated 2026-10-17

On this page

Falling tickets, two opposite causes
The escape-route register
Three buckets, not two
Cycle coverage, not weeks
The second close is the gate
Reverse shadowing, and side channels
Who posted in week three
The deferred-scope reckoning
Four ways to leave the old system
The commercials nobody writes down

Almost every published hypercare plan has the same furniture: a daily triage call, severity levels, one issue tracker, incidents split from enhancements, and an exit list topped by “ticket volume at or below baseline”. None of it is wrong. The headline criterion is simply ambiguous.

Falling tickets have two opposite causes

Tickets fall when people learn the system. They also fall when people stop asking and go around it. The number looks the same either way, and on a status report the second case looks better, because it falls faster.

So never read ticket volume alone. Pair it with transaction counts per process per user, taken from inside the ERP, against the volume those processes ran before go-live.

Tickets are down in week three. Which of the two is it?

Stabilising

Process volume at or above baseline

Transactions are posted in the new system, by roughly the people who used to post them. Fewer questions means the work has been learned.

Abandonment

Process volume below baseline, or concentrated

The orders, receipts and journals are produced somewhere else, or by two or three power users keying for everybody. Fewer questions means people stopped asking.

The two-reading ruleSame metric, opposite conclusions. Ticket volume only means something next to process volume per user, and a fall in both is a warning, not a result.

The escape-route register

A behavioural test has to be written as a list of things still possible: one row per remaining way a process can be done the old way, with an owner, a replacement and a close date inside the window.

Escape route	What replaces it	Owner, close date
Legacy write access	Order entry in the ERP	IT, go-live weekend
Legacy read access	Migrated history, or the archive	IT, week two
Shared-drive spreadsheet	A named replacement report	Process owner, week three
Approval by email or chat	Workflow approval, with a delegate	Process owner, week two
Circulated legacy report	A subscribed report in the ERP	Report owner, week three
Recurring manual journal	The subledger, fixed at source	Finance lead, before close two

The gate: the register is empty, or every remaining row carries a named executive’s signature and a review date. A signature is a decision; an unowned row is a project that has not finished.

Two things separate this from a decommissioning plan. Legacy write access goes at the go-live weekend; retention law and read-only archives are a later programme, decided per record class in should you keep the old system readable?, and letting that programme be the gate is how the old way survives. Hypercare is also the cheapest moment to close a workaround: a two-week-old spreadsheet has no defenders, a six-month-old one is how the department works.

Three buckets, not two

Incident or enhancement is the standard split. It misses the bucket most of the queue falls into: works as configured, the user does not know it or does not believe it.

It needs a routing rule. If two or more users at different sites report the same thing as broken and the configuration is correct, it is a design or communication defect, and it goes to the process owner, not the trainer. One person, once: coaching. Two sites, same complaint: design.

Cycle coverage, not weeks

Hypercare is sold as a fixed block of weeks, with a line underneath saying you should exit on criteria rather than on the calendar. Both halves get written into the proposal, and the block decides anyway, because the block is the part that was priced. Size it by cycles instead: hypercare lasts one clean instance of everything that touches money or a customer promise.

Payrollone full run, paid correctly
Invoice runplus the dunning that follows
Payment runsuppliers paid from the new ledger
Stock countcounted and adjusted in the system
Credit notea return reversed end to end
Second closesubledgers tie to the GL

The duration is arithmeticA four-week hypercare on a monthly-close business buys exactly one close, and one close proves nothing. A quarterly filing either comes inside the window or becomes a named carve-out.

Write the end date as the later of two things: every cycle has run once cleanly, and the second close is done. Unnamed carve-outs become emergencies three months later.

The second close is the gate

The first close in a new ERP always gets forced to tie out. Someone stays late and writes the journals that make it reconcile. That is willpower, not evidence.

So apply two rules. Every manual journal written during close one purely to make something reconcile is logged as an open defect, tagged with the subledger it came from, not filed as part of a completed close. And close one is executed by the client’s own finance staff with the consultant watching, not the other way round. Hypercare exits after close two, which shows whether those journals became permanent. If the same plug reappears, the subledger is still wrong and the close has learned to hide it.

A close that needed a manual plug is a close with an open defect, whatever the balance sheet says.

Reverse shadowing, and the date side channels close

Support changes hands inside the window, in a stated sequence, and the sequence is only real if the consultant gets slower on purpose.

Weeks one and two. The consultant resolves. The client’s support person observes and writes the runbook entry as it happens. A runbook written afterwards is a different document.
Weeks three and four. The client’s support person resolves. The consultant observes and corrects, and does not take the keyboard. Average resolution time should get worse in these two weeks. If it does not, the keyboard went back, and nothing transferred.
The final week. The consultant answers only what arrives through the client’s queue, at the queue’s speed, including the waiting.

The skipped step matters most: a published date on which direct access to named consultants closes, by chat, phone and personal email. Side channels, not ticket volume, keep a project team attached for months. The checkable version is the share of questions that arrive through the queue rather than to a person, counted weekly. It should rise from week one, and a week where it falls is the week a side channel reopened.

Who posted the transactions in week three

One query, run weekly: postings by user for each core process. If the super users posted them, capability has not transferred. The super user has become the department’s only doer, posting instead of coaching, which looks like success on every dashboard and collapses the day they take leave. The rule belongs in the plan: no super user is the only person who can complete their process.

The deferred-scope reckoning

In real projects, user acceptance testing closes with a list marked “we will fix it in hypercare”. Count that list on the day of go-live, one decision per item: fix in hypercare, hold for release one, or never.

Then apply the capacity rule. Hypercare capacity exists for unknown production problems. If the carried-over list already consumes a meaningful share of the team’s time, hypercare is finishing the build and the published end date is fiction. Reset it before go-live, while it is still a planning conversation. Check too whether the list is a data migration problem wearing a configuration label.

Four ways to leave the old system

The exit option is chosen before go-live, on the cutover weekend rather than during hypercare, and it sets how hard the behavioural test will be.

Option	What it costs	What it protects	What it hides
Hard cutover	Risk concentrated in one weekend	Forces the change at once; one version of the truth	Nothing, which is why it frightens people and why it works
Parallel run	Double data entry, for weeks, by the busiest people	A comparison for every number	Teaches everyone the old system is still real, the behaviour hypercare exists to end
Legacy read-only, write revoked	Licence or hosting for the retention period	History and audit access with no escape route	Little, if the end date is dated and owned
Dual-entry window	Reconciling two moving ledgers	A soft landing for one or two processes	Which system the staff believe, until the window shuts

The defensible middle for most mid-sized businesses is read-only legacy, write revoked, with a dated end. The parallel run sounds safest and most often prolongs the problem.

The commercials nobody writes down

Editorial pages skip this and contracts do not, which is why hypercare disputes are so predictable. Five things, in writing, first.

Who classifies a defect versus an enhancement, and who adjudicates. A named person, not “by mutual agreement”.
How many hours of configuration change the fee includes, and what happens at the limit.
The extension mechanism and its price. Extension is decided under pressure, and a rate agreed then is not a negotiation.
The hypercare rate against the project rate, as a number.
The gap between hypercare ending and a managed service or help desk starting. It is usually unowned, and it is where the first bad month happens.

A bias worth namingMuch of the best-written hypercare material comes from software vendors, so it frames “deflect tickets” and “reduce cost” as goals. For the business bringing in the ERP, early deflection is a risk: questions in week two are the cheapest information you will get about your own design.

Hypercare is the last stage of an erpification and the one most often declared finished for calendar reasons. The stage-by-stage view sets out what the earlier stages owe it, and why ERP implementations fail reads the same thing backwards, from the symptom to the gate that was skipped. If you are still deciding whether the system is the problem, read outgrown QuickBooks, or outgrown your process and run the readiness check.