Go-live is not adoption: what to measure in the six months after cutover

Even the transformations that their own participants rated a success fell well short of what they could have delivered. In McKinsey's 2021 survey of 1,034 people who had taken part in a transformation, respondents at successful programs estimated that their organizations captured on average 67 percent of the potential financial benefit, against 37 percent at the rest. Respondents placed nearly a quarter of the lost value at target setting and about 20 percent after implementation. For an ERP or core-system program, that is the period after cutover, when the program team is being stood down.

The figures are self-reported estimates from an online survey fielded in mid-2021 and weighted by national GDP, and they cover transformations of every kind rather than system programs alone. They do not tell you how much value a given ERP program loses after go-live. They do show that the people closest to these programs saw value slipping away at both ends: when targets were set, and after the work was declared done.

What go-live metrics miss

The dashboards that govern cutover and hypercare, the weeks of intensified support after go-live, track defects, ticket volumes, system availability and transactions posted. Those numbers tell you whether the system is stable. They cannot tell you whether buyers raise purchase orders before invoices arrive, whether planners use the system forecast or keep their own spreadsheet, or whether anyone still owns the business case.

Leaders' own assessments suggest the gap is wide. Gartner reported in 2025 that only 32 percent of mid-to-senior business leaders said the last change they led achieved healthy adoption by employees. Gartner defines healthy adoption as employees acting on a change, on time, without undue stress or harm to performance and engagement. The figure is the leaders' own judgment, it covers changes of all kinds, and Gartner's release does not give the size of the leader sample.

For a core system, adoption means people doing their work in the system as designed, and the business seeing the results the case promised. Both need measuring for months after cutover. The scorecard below sets out what to collect. It contains no target percentages. A sensible threshold for a high-volume accounts payable process differs from one for a monthly planning cycle, so thresholds have to come from your own baseline and your own business case.

A site at full use and a site half in spreadsheets can average out to a reassuring number.

The scorecard and its thresholds

Four measures sit at the core: usage, workarounds, process conformance and benefits. Five supporting measures explain why the core numbers move.

Process conformance deserves particular care because many benefits depend on a sequence of steps rather than a single transaction. Automated invoice matching pays off only if the purchase order exists before the invoice arrives. System event logs record when each step of a case happened, and comparing them with the designed process shows where work departs from it and how often.

Workarounds seldom appear in ticket queues, because a person who has found a way around the system has no reason to log a ticket. Look for indirect signals instead: rising manual journal entries, requests to keep legacy access, bulk uploads replacing on-screen entry, and approvals given by email and keyed in afterward.

A scorecard is only as useful as the baselines and thresholds behind it. Seven rules keep them honest.

• Capture the baseline before cutover. For each benefit and operational measure, record the legacy value over a full business cycle, such as a quarter or several month-end closes. Where the legacy system cannot produce a measure, record the gap and take the baseline from the first stable month after cutover, labeled as such.
• Turn the business case into behaviors. Each benefit assumes people will work differently: fewer manual journals, invoices matched automatically, planners using the system forecast. Make each assumption a measure with a threshold. If the case assumes manual matching disappears, manual matching volume is the number to watch.
• Agree on the dip in advance. If the plan expects performance to fall after cutover, the process owner and finance should agree before go-live how deep and how long a fall is acceptable, and what happens if it goes further.
• Set thresholds by role and site. A site at full use and a site half in spreadsheets can average out to a reassuring number. McKinsey's 2021 survey found that goals adapted for employees at all levels were among the actions most predictive of value capture, though that is a correlation in self-reported data.
• Freeze the definitions. Write down the numerator, denominator, data source and owner for each measure at go-live. A definition changed after disappointing results costs the scorecard its credibility.
• Compare like periods. Month-end, quarter-end and seasonal peaks move every measure, so compare a close with a close.
• Attach an action and an owner to every threshold. A breach should trigger something specific: retraining for a role, a design fix, a data cleanup or an escalation to the sponsor.

The six-month sequence

1. Before cutover. Agree on the scorecard, definitions and owners. Capture baselines and have finance sign off the benefits baseline. Decide what legacy access will remain, make it read-only where possible, and log its use.
2. Weeks 1 to 4. Track usage by role and site every week. Classify every ticket as defect, access or how-to. Walk the floor and ask managers where work is leaving the system. Run the first confidence pulse in week 4. Hold back benefits reporting, because backlog clearing and data corrections distort early figures.
3. Month 2. Take the first conformance reading on the main end-to-end processes. Separate deviations caused by design gaps, which need a fix, from those caused by habit or skill, which need coaching.
4. Month 3. Exit hypercare when the criteria are met rather than when the calendar says so: defect and how-to tickets have stabilized, and usage meets the agreed threshold in each role. Hand each measure to a named process owner. Take the first benefits reading against baseline and run the second pulse.
5. Months 4 and 5. Retire the workarounds. Switch off remaining legacy access, close shadow spreadsheets with the teams that built them, and retrain roles where conformance lags. Recheck data quality, which can drift once the project team stops watching it.
6. Month 6. Hold a formal adoption review with the sponsor, process owners and finance, using the third pulse alongside the system data. Review every measure against its baseline and threshold, then decide whether to close, extend support for named roles or sites, or reopen the design. Move the measures that drive the benefits case into business-as-usual reporting, reviewed quarterly until the case is closed.

The first step costs nothing. Open the business case, list the behavior each benefit depends on, and check whether anyone has been asked to measure it once hypercare ends.