Hypercare is no longer a project: the transition from go-live to run in practice

An ERP migration went live on a Friday. A week later, on the first real working Monday, the action list held 124 open items. Twelve on retest, eight on returned to business partner. The rest in a mix of open issues, small wishes, and monitoring questions.

To anyone who does not know the project well, this looks like chaos. To anyone who knows how a large migration unfolds, it is a sign that the go-live went well.

The numbers behind a successful go-live

The 124 items are not flashpoints. They are signals. They show that the organization is now actually using the migration, and that the first imperfections are surfacing. That is exactly what hypercare is meant to bring up.

The steering committee had pushed through the migration unanimously, despite a list of known imperfections. That judgment carried through into the hypercare phase. A sponsor who approved a Friday-noon go-live accepts a Monday list of 124 items as operational reality, not as a crisis.

Retest and returned as acceptance stations

The two most important statuses in a hypercare action list are not open and closed. They are retest (to be confirmed by the end user) and returned (waiting on information from the end user). Both stations sit close to the user. The PM does not work them off. The domain owners cycle through their end users to confirm that a fix does what it should.

What that asks of the PM: filter the action list by status weekly, see which items have been on retest too long, and prompt the owner. Not to micromanage, but to prevent items from sitting there for three weeks because nobody is actively pulling them.

The difference between issues and wishes

A handful of the 124 items are real issues: something does not work as agreed. Most are wishes: it works as agreed, but the user would have preferred something else, or a new situation has surfaced that the specs did not anticipate. The two behave differently.

Issues must be solved in hypercare, otherwise they become chronic pain. Wishes must not be solved in hypercare, otherwise hypercare becomes a second project phase. Drawing that line is a daily discipline. Most of the PM’s work in this phase sits there.

The handover moment that has not yet happened

A go-live is not the project handover. The project handover is a formal moment when a closure memo is signed off, an acceptance document is signed, and the sponsor gives their OK. In practice, that moment arrives somewhere four to eight weeks after go-live, once the hypercare peaks have flattened out.

Plan that moment early. On a hypercare roadmap I had it set for week 23 to 26, around seven weeks after go-live. Not sooner, because there are still too many open items. Not later, because then the project feels endless and project mode becomes operational reality.

Three quick wins to close out hypercare

In a handover memo to a successor I wrote:

• A handful of open fields on an item card to put at the supplier as a package.
• An auto-restart on a job queue that still pulls in manual monitoring work.
• Cancel temporary consultant accounts that still consume ten Premium licenses.

None of these three is large. Together they signal that hypercare is coming to its natural end. From there, the organization can make the transition to run mode.

A first Monday after go-live

On the first Monday after go-live, a sponsor sent a message: everything went through. No noise, no extra words. Three words, and the full acceptance of the migration decision was in there. It was about what he did not say.

Hypercare is its own phase, with its own rules. Not an extension of the project, but a gradual transition into run mode. Anyone who does not draw that line never closes the project, even when everything works.