Migration timing comparison. Brownfield versus RISE.

Timing is one of the most underestimated variables in the RISE versus brownfield decision. Buyers tend to treat the two paths as if they differ in destination but not in duration. In practice the duration is materially different, the sequencing is different, and the cost of compressing either path beyond what the engineering will tolerate is different. The buyers who plan the timing well finish the programme inside a defensible window and arrive with a stable production system. The buyers who plan the timing poorly find themselves running parallel infrastructure for longer than budgeted, paying for two SAP environments at the same time, and explaining a slipped go live to the board. The comparison below walks through the timing profile of each path, the dependencies that drive duration, the gates that cannot be safely skipped, and the operational consequences of getting the sequence wrong.

01.The headline duration. What twelve to thirty months actually covers

A brownfield migration to S/4HANA typically takes between eighteen and thirty months end to end for an enterprise estate. The duration covers system conversion design, custom code remediation, data archive and cleanse, integration refactor, business process validation, regression testing, cutover rehearsal, and the cutover itself. The duration scales with the size of the custom code footprint, the number of integrations, and the complexity of the legacy data.

A RISE conversion typically takes between twelve and twenty four months end to end. The duration covers the same workstreams plus the additional work required to fit the estate inside the RISE managed services boundary. The RISE conversion adds workstreams that brownfield does not require, including the integration refactor onto supported patterns, the operational handover to SAP, and the custom code remediation against the Private Edition extensibility model.

The headline numbers conceal the fact that the two paths have different shapes. Brownfield concentrates the duration in the technical conversion. RISE distributes the duration across technical conversion, commercial negotiation, and operational handover. The total duration is broadly comparable but the demands on different functions inside the buyer organisation are not.

02.The sequencing differences. What happens first on each path

Brownfield sequencing starts with the technical assessment. The buyer team profiles the existing ECC estate, identifies the custom code that requires remediation, scopes the data cleanse, and defines the cutover approach. Commercial negotiations with SAP focus on the maintenance contract and on the brownfield migration license entitlements, but the commercial workstream is comparatively narrow.

RISE sequencing starts with the commercial negotiation and runs the technical work in parallel. The commercial workstream is wide. It covers FUE conversion, hyperscaler selection, integration boundary definition, SLA design, custom code extensibility scope, exit clauses, and pricing across the seven year contract life. The technical workstream cannot move beyond initial design until the commercial parameters are settled because the commercial parameters define what the technical solution can actually do.

The sequencing difference has organisational consequences. A brownfield programme can be led by the SAP technical team with light involvement from procurement and legal. A RISE programme cannot. The commercial complexity requires deep involvement from procurement, legal, finance, and executive sponsorship from the moment the programme begins.

03.The dependencies that drive duration on each path

Brownfield duration is driven primarily by the custom code footprint, the integration count, and the data volume. A buyer with light customisation, clean integrations, and a manageable data estate can complete a brownfield conversion in twelve to fifteen months. A buyer with heavy customisation, legacy integrations, and a large data estate requires twenty four to thirty months.

RISE duration is driven by the same technical factors plus the commercial complexity and the operational handover. The commercial complexity is the largest single duration driver. Buyers who underestimate the commercial complexity often find that the technical team is ready to cut over but the commercial parameters are not yet settled, and the cutover slips by a quarter or two while the contract finalises. The operational handover is the second largest driver. SAP needs time to ingest the estate into its managed services operation. That ingestion includes monitoring agent deployment, runbook handover, SLA baseline measurement, and the establishment of the contractual escalation paths.

The dependencies on each path are not parallel. They are sequential at the gates that matter. The cutover cannot happen until both the technical workstream and the commercial workstream are ready. Either workstream can block the other.

04.The gates that cannot be safely skipped on either path

The gates that cannot be skipped on a brownfield path are the custom code remediation, the data archive, the regression test cycle, the cutover rehearsal, and the cutover itself. Each of these has a minimum duration set by engineering reality. Custom code remediation cannot be compressed below the time required to test the remediated code. Data archive cannot be compressed below the time required to validate the archive. Regression testing cannot be compressed below the time required to execute the full test pack.

The gates that cannot be skipped on a RISE path are the same technical gates plus the commercial gates and the operational handover gate. The commercial gates include the FUE conversion baseline, the hyperscaler selection, the integration boundary definition, the SLA design, and the final order form review. The operational handover gate is the period in which SAP takes operational control of the estate and runs it under the SLA before the contract goes live.

Buyers who attempt to compress these gates frequently regret it. A compressed commercial gate produces a contract with parameters that the buyer later discovers do not match operational reality. A compressed operational handover produces an SLA that activates before the SAP team is ready to deliver it. The cost of either of these is significantly higher than the cost of running the gate to its proper duration.

05.The cost of running parallel infrastructure during the migration

Both paths require the buyer to run parallel infrastructure during the migration. The legacy ECC environment continues to operate while the new S/4HANA environment is being built. The duration of the parallel run drives a meaningful cost across both paths.

Brownfield parallel run is typically shorter because the cutover is a single event and the legacy environment is decommissioned shortly afterwards. The cost of the parallel run is bounded to the duration of the test and rehearsal phases plus the cutover weekend.

RISE parallel run is typically longer because the operational handover extends across multiple weeks or months after the technical cutover. The legacy environment often continues to operate at reduced capacity during the handover, in part because the SAP managed services team requires a known baseline to compare against. The cost of the parallel run is correspondingly higher and needs to be reflected in the TCO model.

06.The implications for go live timing and business calendar fit

Both paths impose constraints on go live timing. The cutover cannot happen during peak business periods. The cutover cannot happen during financial close. The cutover cannot happen during regulatory reporting windows. The available windows for cutover in any given year are limited.

Brownfield buyers typically have more flexibility in selecting the cutover window because the cutover is a single event that the buyer team controls directly. RISE buyers have less flexibility because the cutover depends on the SAP managed services team's capacity to ingest the estate, and SAP's capacity is competing with the capacity required to ingest other RISE customers.

The flexibility difference is rarely large but it is real. Buyers planning a RISE conversion should reserve the cutover window with SAP early in the programme, ideally twelve months in advance. Buyers planning a brownfield conversion can hold the cutover window inside the buyer organisation and lock it in closer to the cutover date.

The buyers who compress the timing of either a brownfield or a RISE programme below the engineering minimum almost always pay for the compression twice. Once during the programme and once after go live.

07.Conclusion

The timing comparison between brownfield and RISE is rarely the deciding factor in the path selection, but it is consistently the variable that most often disrupts the programme execution. The headline durations are broadly comparable. The sequencing is different. The dependencies are different. The gates are different. The parallel infrastructure cost is different. The flexibility of the cutover window is different. The buyers who plan the timing carefully arrive at go live with a stable system and a manageable cost profile. The buyers who plan poorly arrive late, over budget, and with a contract that activates before the operational handover is complete. The timing analysis belongs in the programme plan from the first day, not added as a verification step at the end.