Cutover planning for RISE conversion.

The cutover from a legacy SAP estate to RISE with SAP is the single highest risk event in the conversion programme. The cutover compresses years of design, build, and test work into a window of seventy two to one hundred twenty hours during which the legacy system is frozen, the new system absorbs the production data set, the integrations are repointed, the business validates, and the operating model transfers from the project team to the support team. Every assumption that has gone untested through the build phase surfaces during the cutover, and the cost of fixing a problem during cutover is an order of magnitude greater than the cost of fixing the same problem during the build. A buyer side cutover plan, built deliberately and rehearsed under realistic conditions, is the difference between a clean go live and a recovery that consumes the first six months of the operating period.

The cutover window and its sub phases

The RISE cutover window is structured into discrete sub phases that run sequentially through the freeze period. The first sub phase is the integration freeze, during which all upstream and downstream systems are placed in a hold state and the legacy SAP system stops accepting new transactions. The integration freeze is the moment the business stops trading against the legacy system, and the duration of the freeze is the duration of the cutover window itself. The integration freeze should be planned to coincide with the lowest business activity window available, which for most enterprises is a long weekend or a planned shutdown period.

The second sub phase is the final data extraction from the legacy system. The extraction produces the full production data set in a known consistent state. The extraction must be coordinated with the integration freeze such that no transactions are accepted between the freeze and the extraction, which would produce data inconsistency between the legacy snapshot and the new system load.

The third sub phase is the data load into the RISE target environment. The load is executed using the migration toolset that has been rehearsed multiple times during the build phase, and the load time is the largest single component of the cutover window. The load includes master data, configuration data, open transactional data, and historical data within the agreed retention window.

The fourth sub phase is the integration repointing, during which the upstream and downstream interfaces are reconfigured to point at the new RISE endpoints. The repointing requires coordination with the owners of each integrated system, and a buyer that has not engaged those owners in advance will find the repointing extending well beyond the planned window.

The fifth sub phase is the business validation, during which named business users execute defined validation scripts against the new system. The validation scripts cover the highest volume and the highest value transaction paths, and the validation outcome is the binary input to the go decision.

The sixth sub phase is the go or no go decision, conducted at a defined point in the window by a defined approval body. The decision body has a clear set of criteria and a clear fallback plan, both of which are documented in advance of the cutover.

The role of the dress rehearsal

The dress rehearsal is the controlled simulation of the cutover window using a full production data set in a target environment that mirrors the live RISE landscape. The dress rehearsal is the single most informative diagnostic in the cutover preparation, and a buyer that compresses the rehearsal schedule to save time in the build phase accepts a meaningfully higher risk of cutover failure.

The dress rehearsal should be run at least twice. The first rehearsal establishes the procedure, identifies the gaps in the runbook, validates the data load timings, and surfaces the integration coordination issues. The second rehearsal demonstrates the closure of the issues from the first rehearsal and validates the cutover window timing under controlled conditions. A third rehearsal is appropriate when the first two surface significant issues or when the data volume is large enough that the load timing is the binding constraint on the window.

The dress rehearsal should be timed to match the planned cutover window precisely, with the rehearsal team operating under the same time pressure and the same handover discipline that the live cutover will require. Rehearsals that are run during business hours, with the project team and the business team available for ad hoc support, do not surface the issues that arise during a weekend cutover with a reduced support footprint. The realism of the rehearsal is the realism of the cutover.

Fallback planning and the no go decision

The fallback plan describes the actions that the cutover team takes if the go decision is no go. The fallback plan should be specific, time bound, and pre approved by the business sponsors. A fallback plan that is documented as a generic intention to roll back is not a fallback plan. The fallback plan must specify which systems are reverted, which data is preserved, which integrations are repointed back to the legacy environment, and how the business is informed of the postponement.

The fallback decision must be made before the point of no return in the cutover sequence. The point of no return is typically the moment the legacy system data is archived and the legacy operating capability is decommissioned. After the point of no return, the fallback is no longer available, and the cutover team must complete the go live regardless of the open issues. The point of no return should be identified and documented in the runbook, and the go or no go decision must be made before that point with margin for the actual fallback execution.

A no go decision is not a failure. A no go decision is the disciplined response to a set of validation outcomes that do not meet the entry criteria for go live. A buyer that treats no go as a project failure creates an incentive to override the validation criteria under cutover pressure, which produces worse outcomes than the original no go decision. The cutover team must have explicit permission, in advance, to invoke the no go decision without organisational consequence.

Hyper care and the first ninety days

The hyper care period covers the first ninety days after go live, during which the project team remains engaged to resolve issues as they surface and the business operates with elevated support coverage. The hyper care structure should include daily standups during the first two weeks, weekly standups through weeks three to six, and biweekly checkpoints through the remainder of the period. The standups review the issue log, prioritise the response, and escalate the issues that cross defined thresholds.

The hyper care also includes the operational handover from the project team to the steady state support team. The handover should be staged across the ninety day window rather than executed at a single point, because the support team needs the live operating experience to build the skills that the project team has accumulated through the build phase. The staged handover creates a learning curve for the support team while the project team is still available, which is materially safer than a clean break that requires the support team to absorb the operating model in a single transition.

The hyper care issue log is the buyer reference for the warranty period and for the contractual remediation obligations of the implementation partner and SAP. The log should be maintained with discipline, including the issue description, the root cause, the resolution, and the date closed. The log is the evidence that informs the buyer position in any post go live commercial discussion with either vendor.

Conclusion: cutover discipline is the proof of conversion readiness

The cutover is the moment at which all the assumptions made during the conversion programme are validated against the operating reality. A buyer that has invested in disciplined cutover planning, with two or more full dress rehearsals, with explicit fallback planning, with a clear go or no go decision rights structure, and with a staged hyper care handover, captures the difference between a clean go live and a recovery period that consumes the first half of the operating year. The cutover plan deserves the same rigor that the SAP commercial negotiation receives, because the cutover is the moment the negotiated outcome converts into the operating outcome. A buyer that treats cutover planning as a project administration task accepts the risk that the operating outcome will not match the negotiated promise.