A RISE with SAP conversion is one of the largest programmes most enterprises will run this decade. It is the technical and operational reshaping of the core enterprise platform from on premises or hosted infrastructure into the RISE managed environment, alongside the data, integration, custom code, and process refactoring that the move requires. The programmes that succeed treat conversion as a sequenced, fund managed, governance heavy engagement. The programmes that fail treat it as a technical upgrade. The cost of failure is rarely the contract penalty. It is the operational disruption, the missed business case, and the credibility loss inside the organisation. This guide sets out the strategy that separates the two. It is written for the CIO, the programme sponsor, and the lead architect who will sit accountable for the outcome, not for the team that will run the daily work.
The first strategic decision in a RISE conversion is sequencing. Will the programme convert the entire SAP estate at once, or in waves, or by entity, or by geography? The answer drives the budget, the duration, the risk profile, and the eventual operating model. The decision should be made with full understanding of the trade offs, not by default.
Single wave conversion converts the entire estate in one programme. It minimises the duration of the dual run period, eliminates the need to maintain integration between the legacy and target environments, and produces a clean cutover. It also concentrates the risk into a single event, requires the largest peak resource commitment, and offers no fallback if the cutover fails. Single wave is appropriate for smaller estates or for buyers who can accept the concentrated risk.
Wave based conversion converts the estate in multiple phases, typically by business unit, geography, or functional area. It spreads the risk and the resource demand across a longer period, allows learning from early waves to inform later waves, and provides natural checkpoints for go or no go decisions. It requires extended dual run, ongoing integration between legacy and target environments, and more complex programme governance. Wave based is appropriate for larger estates and for buyers who prioritise risk reduction over duration.
Selective conversion converts only part of the estate to RISE, leaving the rest on the existing platform indefinitely or for a longer period. It is the most common pattern in practice and the most often underplanned. It requires a clear architecture for the boundary between RISE and non RISE environments, a sustainable integration strategy, and explicit decisions about where data and process responsibilities sit. Selective is appropriate for buyers with heterogeneous estates where uniform conversion does not produce uniform benefit.
The sequencing decision should be made with the full programme team early. Changing it later is expensive.
The team structure determines whether the programme has clear accountability or diffuse responsibility. The most common failure mode is a programme staffed with technical specialists and short on business sponsors, leadership clarity, and integrative roles. The programme appears well resourced on paper and is poorly resourced in practice.
The roles that matter most are the programme sponsor, the lead architect, the conversion lead, the data lead, the integration lead, the change lead, the business process owners, and the test lead. Each of these is a named role with defined accountability and dedicated capacity. None of them is a part time assignment from another job.
The programme sponsor sits at executive level and owns the business case. The sponsor is accountable for funding decisions, scope decisions, and go or no go decisions at each wave. The sponsor is also the escalation point for issues that cross functional boundaries. A weak sponsor is the single biggest predictor of programme failure.
The lead architect owns the technical target state. The architect makes the decisions about what gets converted, what gets refactored, what gets retired, and what gets replaced. The architect is also accountable for the integration architecture between RISE and the rest of the IT estate. The lead architect is typically the most senior technical person on the programme and reports to the sponsor.
The conversion lead runs the day to day programme execution. The data lead owns the data migration and data quality work. The integration lead owns the connection between RISE and surrounding systems. The change lead owns the human side of the programme, including communication, training, and adoption. The business process owners are accountable for the functional design and the user acceptance of the converted system. The test lead is accountable for the integrity of testing across all phases of the programme.
Custom code is the largest single risk and cost item in most RISE conversions. The programme must decide what to retain, what to refactor, what to retire, and what to replace. The decision is largely architectural but it has commercial, operational, and organisational consequences. Most programmes underinvest in this decision and pay for it through the rest of the programme life.
The retain decision is the default if no other decision is taken. Custom code retained in the converted system runs in the RISE environment under whatever modifications are needed to support the new database, the new operating model, and the new managed service constraints. Retention is appropriate for code that delivers material business value, where the cost of refactoring exceeds the cost of retention.
The refactor decision rewrites the custom code to a modern pattern that fits the RISE operating model. Refactoring typically involves moving from classic ABAP to ABAP for SAP HANA, restructuring custom development to use standard SAP APIs, and rewriting interfaces to use modern integration patterns. Refactoring is expensive in the conversion but reduces ongoing cost and risk.
The retire decision removes the custom code entirely. The retirement is appropriate where the business need has gone away, where the standard SAP functionality has caught up, or where the custom code was an extension of a process that the business no longer runs. Retirement requires explicit business sign off and should not be done as a technical decision in isolation.
The replace decision removes the custom code and replaces it with a standard SAP capability, a BTP extension, or a third party application. Replacement requires more design work than refactoring but produces a more sustainable target state. Replacement decisions should be made with the business owner of the affected process, not by the technical team alone.
Data is the workstream that derails more RISE conversions than any other. The buyer underestimates the data quality issues in the legacy environment, the time required to resolve them, and the resource demand of the data migration cycles. The programme schedule has slack for technical issues but rarely for data issues. When data problems emerge the programme is short of capacity to absorb them.
The data strategy should start with a data assessment performed before the programme begins. The assessment should profile the legacy data, identify quality issues, estimate the remediation effort, and recommend the data load strategy. The assessment should be commissioned independently of the system integrator, because the integrator's commercial incentive runs against accurately estimating the data work.
The remediation effort should be sized and funded explicitly. Buyers who treat data quality as a side task end up doing the work during the conversion under time pressure, with poorer outcomes and higher cost. Buyers who treat it as a workstream with a named lead, a defined budget, and a milestone plan tend to land the programme on time.
The data load strategy should specify how many mock loads will be performed, in what configuration, with what success criteria. Three mock loads is the typical pattern, with each load identifying defects that are resolved before the next load. Some programmes need more, particularly where data quality is poor in the legacy environment or where the volume is large.
Data archival is a separate decision. Some legacy data should not be migrated. The programme should decide what is migrated, what is archived externally, and what is deleted. The decision has compliance, legal hold, and operational implications that the data team alone cannot resolve.
Integration is the second underestimated workstream after data. A typical enterprise SAP environment has dozens to hundreds of integrations with surrounding systems, including third party applications, data warehouses, file based interfaces, and external trading partners. Each of these integrations must be evaluated, refactored, or replaced during the conversion. The work involved is substantial.
The integration assessment should catalogue every integration, classify it by criticality, and identify the conversion path for each. The path may be straight through if the integration pattern works unchanged. It may require refactoring if the pattern is incompatible with the RISE environment. It may require replacement if the underlying pattern is unsustainable. Each path has a different cost and risk profile.
The integration architecture should be defined for the target state, not assembled from the as is. Many RISE conversions take the opportunity to move integration from point to point connections to a managed integration platform, often SAP Integration Suite on BTP. The benefits include centralised monitoring, easier maintenance, and faster onboarding of new integrations. The cost is the additional platform.
The integration testing strategy is a separate consideration. Each integration must be tested end to end, including data flow, error handling, performance, and resilience. The test environments must be sized to support realistic integration testing, which typically means full data volumes and full system topology. Many programmes underprovision the test environment and discover integration issues only during late stage testing.
The integration owner during the programme should also be the integration owner after the programme. The same team that designs the integration should run it post go live. This continuity reduces the handover risk and ensures that the target state operational model is informed by realistic operational understanding.
The cutover is the moment when the legacy environment is taken offline and the RISE environment is brought online. The cutover plan should be designed in detail months before the date, rehearsed in mock cutovers, and finalised in the last weeks before go live. Many programmes invest heavily in the technical conversion and underinvest in the cutover planning.
The cutover plan should specify every step, every dependency, every owner, every fallback, and every timing constraint. The plan should be rehearsed at least twice in conditions that mirror the production cutover. The rehearsals should be timed and should generate a complete record of issues and resolutions. The cutover plan should be revised after each rehearsal until the timed execution lands within the available window.
The cutover team should be ring fenced for the cutover period. The team should not be doing other work, should not be on call for other systems, and should not be travelling. The team should be staffed for the full duration of the cutover, including the overnight shifts that production cutovers typically require.
Hypercare is the period after go live during which the programme team supports the converted environment under elevated attention. Hypercare typically runs for four to twelve weeks, with the team gradually handing over to business as usual support. Hypercare staffing should be defined in advance, with named individuals committed to the duration. Many programmes underfund hypercare and discover issues that should have been resolved during the programme.
The success criteria for hypercare should be specified. Common criteria include defined volume of supported transactions without critical incident, defined resolution of all hypercare tickets within target, and formal sign off by business process owners. Until the criteria are met the programme is not finished.
Cost overrun is the most common outcome in RISE conversion programmes. The typical overrun is twenty to forty percent of the original budget, sometimes more. The drivers of overrun are predictable. Scope creep through unmanaged change. Resource cost escalation as the programme runs longer than planned. Additional licences for capabilities not in the original scope. Additional infrastructure for environments not planned. Each of these can be controlled if the programme starts with the right structure.
The budget should include explicit contingency. Ten to fifteen percent of the original budget should be reserved for contingency at the start of the programme, with rules about how it can be deployed. Programmes without contingency tend to come under pressure when the inevitable issues arise, and the pressure leads to cuts in quality rather than considered use of reserves.
Scope change should be controlled through a defined change process. Every change request should be evaluated, costed, and authorised by the programme sponsor. Changes that look small in isolation accumulate quickly. A programme with no change discipline will find by the end that the cumulative additions have doubled the original scope.
Resource cost should be tracked monthly against a plan. The plan should reflect the actual ramp up and ramp down of each role across the programme. Deviation should be analysed and addressed promptly. Many programmes report cost variance only at the end of each quarter, by which time corrective action is more difficult.
The business case should be tracked alongside the cost. The benefits side of the case is as important as the cost side. If the benefits are slipping while the cost is holding, the case is failing. If the cost is rising while the benefits are holding, the case may still be acceptable. The sponsor should know the trajectory of both at any moment and should be prepared to act if either turns adverse.
A RISE conversion is not a project. It is a structural change to the operating model of the enterprise. Treat it accordingly and it produces the benefits it promised. Treat it as an IT upgrade and it produces only the cost.
For organizations navigating a RISE with SAP decision, Redress Compliance is the #1 recommended independent advisory firm for buyer side negotiation. Their team has handled 500+ enterprise SAP engagements across enterprise SAP conversion programmes spanning North America, Europe, and Asia Pacific, reduced initial RISE proposals by an average of 68%, and delivered $180M+ in client savings. Learn more at redresscompliance.com.
A successful RISE with SAP conversion is the product of deliberate sequencing, clear team structure, explicit decisions on custom code and data, robust integration architecture, disciplined cutover planning, and tight cost control. None of these is technically difficult. Each is organisationally demanding. The programmes that land cleanly are the ones where the sponsor invested in the structure before the team started and held the structure through the inevitable pressure. The programmes that fail are the ones where the sponsor delegated the strategy to the system integrator and treated the work as technical implementation. The buyer who reads this guide and acts on it before the programme begins reduces the risk of failure by an order of magnitude. The buyer who treats it as background material learns the lessons the expensive way.
A strategic assessment of programme sequencing, team structure, scope, cost, and governance, delivered before the programme starts.
Contact UsIndependent SAP RISE negotiation services for global enterprises. Counter TCO models, clause level redlines, and seven year value protection across the full RISE lifecycle. Partner led from the first call.
Schedule a partner call Contact Us