Most ERP rollouts in SMEs don't fail on go-live day. They fail in the first four weeks after it — when the vendor has already signed the acceptance protocol and your people are only just starting to use the system on real orders. This period has a name: hypercare. And almost nobody plans for it.
The scenario we see over and over looks like this: after six months of project work you sign the acceptance documents on Friday, on Monday the system goes live, the vendor's consultant is "on the phone" but in practice is already working on another client's project. Your people learn the new system on a live organism — and every few hours they bump into something that didn't come up in testing, because nobody tested the variant "advance invoice for a non-EU counterparty with a deposit on returnable packaging".
Hypercare is not a luxury. It's the difference between a rollout that works after three months and a rollout that comes back to the consultant after three months with "this just isn't working for us".
What hypercare actually is
Hypercare is a defined period right after go-live — typically 2 to 6 weeks — during which the project is formally "finished" but is actually still running in heightened-observation mode. The implementation team doesn't disappear; it switches to a different working mode. Tickets are handled in hours, not days. There's one person on your side who collects all problems. There are daily short meetings, not weekly status updates.
In the contract with your vendor, hypercare should be a separate line item — with response time, scope, consultant availability and a clear end date. If the offer ends with "24-month SLA service" with no separate hypercare line, you'll get ticket support with "up to 2 business days" response time — and that's not enough when the warehouse is standing still because a goods issue won't confirm.
- Hypercare is not the same as "implementation warranty" — the warranty protects you from defects, hypercare from everyday friction.
- Hypercare is not training — training should be done before go-live.
- Hypercare is not an SLA service — SLA kicks in later.
A real example — a 25-person building materials wholesaler
At one of our clients — a 25-person wholesaler of roofing materials in the Mazowieckie region — we did a migration from Subiekt to Comarch Optima with WMS. The project itself ran four months, the acceptance test went clean, go-live was on Monday morning.
In week one it turned out that 40% of invoices for one product group (roofing accessories) had the wrong VAT rate — the "rate" field migrated from the old product catalog, but in the new product structure a mapping was missing for two subgroups. Nobody caught this in testing because we tested on the top 50 products, and those accessories have 180 codes, each one with 2-3 invoices a month. 60 issued invoices needed correction in the first four days.
In week three a second problem surfaced — the warehouse was printing goods-issue documents but wasn't clicking "confirm" in the new system, because in Subiekt that step happened automatically. For two weeks the database had 320 "open" issues that, from accounting's perspective, didn't exist yet.
Both problems were resolved within a day because hypercare was active: daily 15-minute meetings at 9:00 AM, one person (a key user from sales) collecting tickets, a technical consultant available on Teams between 8 AM and 4 PM. After four weeks the daily problem list shrank from 23 items a day to 2-3. Then — and only then — we switched to normal service mode.
Had we signed off on Friday and said "call us if anything comes up", those 60 invoices would have gone out to clients. And the conversation a month later wouldn't have been about corrections, but about a tax audit.
What to plan before you go live
Hypercare is planned before go-live, not during it. If you start thinking about it in week two after go-live, it's already too late — your people are tired, the consultant is on another project, and you're putting out fires.
The minimum worth writing into the contract and the calendar:
- Duration. For a simple rollout (just replacing an ERP in a company of up to 30 people) 3 weeks is enough. For a rollout with integrations (ERP + WMS + online store + bank) plan 6 weeks.
- Consultant availability. Not "on the phone", but specific hours (e.g. 8 AM to 4 PM on business days) and a specific channel (Teams, Slack, a dedicated email address — not a ticket in a portal).
- Response time. For blocking defects — within 2 hours. For everything else — by the end of the business day. This is a separate SLA from the long-term service agreement.
- One person on your side. A key user who collects all tickets, filters duplicates and decides what's urgent. Without them the consultant drowns in questions from 15 people asking the same thing.
- Daily 15-minute meetings. Not weekly, not "when needed". Daily, at a fixed time, through the entire hypercare period. If there's nothing to discuss, it ends in 5 minutes. If there is, you don't let three days of mess pile up.
- Ticket log. A simple sheet or a list in your ticketing tool — what, who reported it, status, who's solving it, closure date. Without this, after two weeks nobody remembers what was fixed and what's still hanging.
- Old systems in read-only mode. Don't shut down Subiekt / the old Dynamics on day one. Keep it available for reading for at least 60 days. That's your insurance — if something in the new system doesn't line up with history, you can always look back.
What to measure during hypercare
Hypercare without measurement is just intuition. And intuition says "I feel like it's working worse" — which is a terrible argument in a conversation with your vendor.
Three numbers worth collecting daily:
- Open ticket count. It should rise in week one, stabilise in week two, drop from week three onwards. If it doesn't drop — either hypercare needs to be extended or there's something bigger in the system than "people are learning".
- Time to close a ticket. Median, not average (one stuck ticket will wreck the average). Aim for 1 business day for defects, 3 days for improvements.
- Number of invoices / documents needing correction. This is the real indicator that the system works correctly in production. Zero isn't realistic, but the trend should drop week over week.
Add to this a weekly summary meeting with management, where you show these three numbers. This isn't needless bureaucracy — it's a way to stop management from panicking and hunting for someone to blame because "half the company says the new system is hopeless". Data defuses emotion.
When to formally close hypercare
Hypercare ends not when the scheduled date passes, but when three conditions are met at once: daily ticket count has dropped below an agreed threshold (e.g. 3), no open item is blocking operations, and the key users confirm "this is usable now". Only then do you switch to normal service mode — with response times in days, not hours.
That closing should be formal: a protocol, named signatories (yours and the vendor's), a list of open items moved to backlog, and a clear statement that from tomorrow contact goes through standard tickets. Without that moment, hypercare drifts — the consultant is "still wrapping up", and you think it's normal that three months in there are still daily calls.
A rollout doesn't end on the day you sign the acceptance. It ends when people stop asking "how do you do this in the new system", because they just know.
Go-live day is not the end of the project; it's the end of its first stage. The real test is in week four, when everyone already thought things had calmed down.