Miguel Santos

By Miguel Santos · SAP & Management

An SAP S/4HANA system can be technically available while the business remains unable to operate.

Orders may fail to reach the warehouse. Users may have access but lack the authorisations needed to complete their work. Opening balances may be loaded, yet still await reconciliation.

For programme leaders, the real cutover question is therefore straightforward: can the business resume operations with an acceptable level of risk?

The technical approach will differ between a new implementation, a system conversion and a selective data transition. However, five leadership priorities deserve attention across these scenarios.

1. Establish one integrated plan with clear ownership

A cutover brings together technical teams, data migration specialists, business process owners, security teams, external providers and support organisations.

Each team may have a detailed plan. The challenge is making those plans work together.

The integrated cutover plan should make five things clear for every critical activity:

• Who owns execution.
• Which prerequisites must be completed.
• How long the activity is expected to take.
• What evidence confirms completion.
• Who authorises the next step.

Dependencies deserve particular attention. A warehouse interface, for example, may depend on migrated master data, validated connectivity, correct authorisations and the availability of a logistics partner.

An activity marked “complete” is useful only if the next team can safely proceed.

Leadership question: does every critical handover have a named owner and an agreed acceptance condition?

2. Rehearse the full transition under realistic conditions

A successful migration test provides valuable evidence, but it does not prove that the complete cutover can fit within the agreed business interruption window.

A meaningful rehearsal should exercise the sequence of technical and business activities, including reconciliation, interface activation, business validation and decision checkpoints.

It should also expose practical weaknesses:

• Tasks that take longer than estimated.
• Dependencies missing from the plan.
• Specialists assigned to overlapping activities.
• Business validation that cannot start when expected.
• Escalations that take too long to reach a decision.

Record actual timings and use the findings to revise the plan. Where rehearsal conditions differ from production, make those differences explicit and assess their effect.

A rehearsal that reveals a serious weakness has delivered value—provided the programme resolves it before go-live.

Leadership question: what evidence shows that the entire transition is executable within the available window?

3. Make business readiness measurable

Technical completion and business readiness need separate acceptance criteria.

Before releasing the system, business owners should have evidence that critical processes can operate. Depending on scope, this may include creating an order, processing a delivery, posting a goods movement, issuing an invoice or executing a payment.

Data acceptance also needs business ownership. A successful load does not, by itself, confirm that stock quantities, financial balances or open transactions are correct.

Agree in advance:

• Which data and processes require validation.
• What reconciliation tolerances are acceptable.
• Who signs off the results.
• Which exceptions can be accepted, with what controls.

Readiness should also cover users, operational procedures and third parties. If a business process depends on a bank, a 3PL or another external service, that dependency belongs in the readiness assessment.

Leadership question: can process owners demonstrate readiness with evidence they understand and accept?

4. Agree go/no-go criteria and contingency options early

The pressure to proceed increases as the go-live date approaches. That makes early agreement on decision criteria essential.

Define the conditions for starting cutover, passing critical checkpoints and releasing the system to the business. Specify who makes each decision and how unresolved risks are escalated.

Those decisions should consider business impact as well as technical status. A defect affecting a critical payment process may matter more than several defects affecting low-volume activities.

Contingency planning requires equal care. Depending on the transition approach and the stage reached, returning to the previous environment may be complex or impractical—particularly once business transactions have started in the new system.

Document feasible recovery options, their time limits, their operational consequences and any point beyond which the available options change.

Leadership question: if a critical checkpoint fails, do decision-makers know which options remain feasible and how long they have to act?

5. Prepare hypercare before cutover begins

Go-live introduces a new operating reality. The people and processes needed to stabilise it should already be in place.

Hypercare preparation should establish:

• A clear route for users to report issues.
• Triage based on business impact.
• Named owners across business, IT and delivery partners.
• Coverage for critical locations and operating hours.
• Monitoring of important interfaces, jobs and business transactions.
• Agreed criteria for handover to ongoing support.

Track operational outcomes alongside incident counts. The ability to ship orders, process invoices and complete financial activities provides a more useful picture of stability than the number of open tickets alone.

Hypercare exit should depend on demonstrated stability and support readiness, including relevant business cycles.

Leadership question: who owns business continuity after go-live, and what evidence will show that operations have stabilised?

The leadership responsibility

A credible cutover decision rests on a chain of evidence: an integrated plan, realistic rehearsal results, business acceptance, explicit decision criteria and a prepared support organisation.

Programme leaders need to ensure that this evidence is visible—and that teams can raise concerns while there is still time to act.

Before your next go-live, ask: what evidence would justify delaying the launch, and does everyone involved know it?