Go-live is the moment everyone celebrates. It is also the moment most transformations quietly start to fail. In 20+ years of ERP work, I have never seen adoption won on go-live day. It is won — or lost — in the six weeks that follow. That phase has a name: hypercare. Treat it as an afterthought and you will pay for it in workarounds, shadow spreadsheets, and a system people tolerate instead of trust.
Why hypercare decides everything
On go-live day, your users are running a process they have never done for real, under time pressure, with muscle memory built on the old system. Errors spike. Confidence drops. The first time someone can't post an invoice or ship an order, they make a decision — not about that transaction, but about the whole system.
That decision is sticky. If the first two weeks feel like chaos, people build private workarounds to survive. Those workarounds outlive the chaos. Six months later you have a system of record that nobody fully believes, and a data quality problem you will spend a year cleaning up.
Adoption is not a training outcome. It is a trust outcome. Hypercare is where trust is either earned back or permanently lost.
How to resource it — properly
The most common mistake: the project team disbands the day after go-live. The consultants roll off, the experts return to their day jobs, and users are left with a ticket queue and a help desk that has never seen the new process.
Here is how I resource hypercare instead:
- Keep the core team on for a fixed window. I plan a minimum of four weeks, six for a global rollout. Not on standby — allocated, in the room, with cleared calendars.
- Floor-walkers, not a ticket portal. In the first days, put experts physically (or virtually) next to users. A 30-second tap on the shoulder beats a two-day ticket. I have measured the difference: floor-walking cut our first-week ticket volume by roughly 40%.
- A daily war room. One stand-up, every morning, same people: functional leads, technical, and a business decision-maker who can say yes on the spot. Most hypercare issues are not bugs — they are decisions nobody is empowered to make.
- Ring-fence your best people. The instinct is to send experts back to revenue work fast. Resist it. Two extra weeks of your strongest functional lead is cheaper than three months of degraded data.
How to run it — the daily rhythm
Hypercare is a cadence, not a hotline. What has worked for me:
Triage everything, every day
Every issue gets a severity and an owner within hours, not days. I split them into three buckets: blockers (a process cannot complete), friction (it works but users struggle), and noise (misunderstanding, not defect). Blockers get fixed same-day. Friction gets a workaround plus a scheduled fix. Noise gets a coaching moment — because noise is often your loudest signal about training gaps.
Watch behaviour, not just tickets
Tickets tell you what broke. They do not tell you what people quietly abandoned. I track a handful of adoption signals directly: transaction volumes versus forecast, how many users log in daily, where processes stall, and how much data is still landing in Excel. A quiet queue can mean everything is fine — or that people have stopped using the system. Look at the numbers to know which.
Communicate wins loudly
Every day, publish what got fixed. Users who reported a problem yesterday and see it resolved today become your advocates. Silence, on the other hand, confirms their fear that nobody is listening.
How to exit — with real criteria
Hypercare should not end because the calendar says so. It ends when the data says the system is stable and adopted. I define exit criteria before go-live, in writing, so the decision is objective rather than political.
My typical exit gates:
- Zero open blockers for five consecutive business days.
- Ticket volume down to a defined steady state — usually below 20% of week-one peak, and trending flat, not just dipping.
- Core process throughput at or above forecast — orders, invoices, postings actually flowing at business volume.
- Adoption breadth — the large majority of named users are active in the system, not just a resilient few.
- Support handover signed off — the run team can resolve typical issues without the project team. If they can't, you are not done, whatever the date.
When those gates are green, transition deliberately: a defined handover, a documented known-issues list, and a named owner for the residual backlog. Announce the exit — people need to know the safety net is being replaced by a permanent one, not simply removed.
The one thing I would tell any transformation leader
Budget hypercare like it matters, because it does. I plan for it as a distinct phase with its own team, its own cadence, and its own exit criteria — never as a rounding error at the end of the plan. The projects I have seen deliver lasting ROI are not the ones with the smoothest go-live. They are the ones that took the messy weeks afterward seriously, and refused to walk away until adoption was real.
Go-live gets the applause. Hypercare gets the result.
Cédric Bignet is an AI & ERP Change Management expert at Novartis and founder of AInspire. He writes about change management, AI adoption and enterprise transformation.