The decision is easier when you stop treating RISE with SAP as a fourth migration method.
Most ECC-to-S/4HANA discussions mix two decisions that should be made separately. The first is how you will transform the system: system conversion, new implementation, or selective data transition. The second is how the target environment will be licensed, hosted, and operated. RISE with SAP belongs mainly to that second decision.
Get the first decision wrong and you carry process debt, lose history you still need, or create a transformation program the business cannot absorb. Get the second wrong and the commercial or operating model can erase the value of an otherwise sound technical plan.
In brief
- SAP provides three primary transition paths from SAP ERP 6.0 to SAP S/4HANA: system conversion, new implementation, and selective data transition.
- RISE with SAP is a cloud transformation and commercial offering. It does not, by itself, decide whether the underlying move is brownfield, greenfield, or selective.
- SAP Business Suite 7 core applications covered by SAP’s current maintenance commitment remain in mainstream maintenance through the end of 2027, followed by optional extended maintenance through the end of 2030.
- A limited SAP ERP, private edition, transition option is planned for eligible large and complex customers from 2031 through 2033. SAP explicitly says this is not an extension of on-premise ERP maintenance.
- The right path is determined by four facts: the value of your existing processes, the condition of your data and custom code, the history you must retain, and the amount of organizational change the business can absorb.
First, separate the two decisions
Decision 1: How should the system change?
SAP’s transition documentation distinguishes three technical approaches:
- System conversion, commonly called brownfield.
- New implementation, commonly called greenfield.
- Selective data transition, sometimes marketed in the partner ecosystem as bluefield.
These approaches determine what is reused, what is redesigned, what history moves, and how cutover can be sequenced.
Decision 2: How should the target be consumed and operated?
This decision covers the target deployment, subscription and operating model. RISE with SAP can be part of that answer, particularly when an organization is moving toward SAP Cloud ERP Private. It still requires a separate transition-path decision.
That distinction matters because “brownfield versus greenfield versus RISE” is not a like-for-like comparison. A company can pursue a system conversion into a RISE-managed private cloud environment. Another can choose a new implementation under a cloud subscription. The commercial wrapper does not remove the implementation choice.
The maintenance runway, accurately stated
The 2027 milestone is serious, but “ECC support ends in 2027” is too broad.
SAP states that mainstream maintenance for SAP Business Suite 7 core applications covered by its current commitment runs through December 31, 2027. Optional extended maintenance follows through December 31, 2030. The commitment covers the latest three enhancement packages of SAP ERP 6.0, which means every organization should verify its exact enhancement package and product combination in SAP’s Product Availability Matrix rather than relying on a generic deadline slide.
For a limited group of large and complex customers, SAP has also announced SAP ERP, private edition, transition option for 2031 through 2033. Eligibility includes significant prerequisites, such as moving the relevant system to SAP ERP, private edition on SAP HANA before the end of 2030. SAP describes it as a time-bound continuity offering, not an extension of on-premise ERP maintenance.
The practical conclusion is simple: later options may buy time, but they do not remove the transformation decision. They add conditions, cost, and another transition step.
The three transition paths
1. System conversion: preserve what works, adapt what must change
A system conversion transforms an existing SAP ERP system into SAP S/4HANA. It preserves much of the existing configuration, custom development, and historical data, but it is not an “as-is” database swap. SAP’s process includes database migration where required, conversion to the S/4HANA data model, replacement of ERP application code, and adoption of mandatory simplification items.
Best fit when:
- Core processes remain fit for purpose.
- Organizational structures do not require major redesign.
- Historical transactions must remain readily available in the target.
- Custom code is understood, actively used, and capable of remediation.
- The business needs the lowest-disruption route to a supported platform.
The hidden risk: system conversion can preserve obsolete configuration and custom code as efficiently as it preserves valuable process knowledge. If the program measures success only by technical go-live, it can reach S/4HANA while carrying the clean-core problem forward intact.
2. New implementation: redesign deliberately, not cosmetically
A new implementation creates a clean SAP S/4HANA environment and migrates the master data, open items, balances, and history required by the target design. It is the strongest option when the existing system no longer represents how the company should operate.
Best fit when:
- Mergers, regional variation, or years of customization have fragmented the process model.
- Leadership wants harmonization and fit-to-standard adoption.
- Data quality problems are too structural to clean inside the current design.
- The target is SAP S/4HANA Cloud Public Edition, where new implementation is the standard path.
- The organization is prepared to rebuild controls, integrations, reporting, and user capability around a new operating model.
The hidden risk: greenfield removes technical baggage only when the business accepts process change. Recreating old exceptions in the new system produces an expensive new platform with the same old complexity.
3. Selective data transition: keep evidence, redesign selectively
Selective data transition allows an organization to migrate and transform chosen configuration, master data, and transactional history. SAP positions it as an alternative to both system conversion and new implementation, typically delivered with specialist tools and services.
Best fit when:
- Some business units or processes should be redesigned while others remain stable.
- System consolidation or organizational restructuring is part of the program.
- Selected history must move, but carrying the entire database is unnecessary.
- A phased rollout by company code, geography, or business unit reduces risk.
- The program needs more transformation freedom than brownfield without a full greenfield reset.
The hidden risk: selective transition is not a shortcut. Data selection, transformation rules, reconciliation, and phased cutover create their own design and testing burden. Its value comes from choosing the right scope, not from making the work disappear.
A decision matrix that holds up under scrutiny
| Decision factor |
System conversion |
New implementation |
Selective data transition |
| Existing processes |
Mostly worth retaining |
Require major redesign |
Mixed by process or entity |
| Historical data |
Broad history retained |
Limited history loaded |
Selected history retained and transformed |
| Custom code |
Reuse after analysis and remediation |
Rebuild only what remains necessary |
Retain or redesign selectively |
| Consolidation |
Limited |
Strong option |
Strong option with phased flexibility |
| Cutover |
Usually system-wide |
Big bang or phased rollout |
Can support phased scenarios |
| Primary risk |
Carrying debt forward |
Recreating legacy behavior and underestimating change |
Underestimating data design and reconciliation |
The table is a starting point, not a scoring engine. A defensible decision requires evidence from the actual landscape.
Five tests that reveal the right path
1. Measure custom code usage before debating architecture
Inventory Z-programs, modifications, enhancements, forms, interfaces, and background jobs. Then separate what exists from what is actually used. An object that has not run across a representative business cycle should not receive the same migration budget as a revenue-critical process.
2. Distinguish process value from process familiarity
Users often defend a process because it is familiar, not because it creates value. For each major workflow, ask whether it differentiates the business, satisfies a control requirement, or merely compensates for an old system limitation.
3. Decide how much history must remain operational
The answer may differ by country, entity, process, and regulator. Choose deliberately among migration into S/4HANA, a governed archive, or a read-only legacy pattern. Historical-data strategy should shape the transition path before an implementation estimate is accepted.
4. Count interfaces before modules
Interfaces are often a better predictor of migration effort than module count. Inventory owners, protocols, data volumes, batch windows, error handling, security dependencies, and downstream reporting. The interface nobody owns is usually the one that appears during cutover rehearsal.
5. Model five-year cost, not project price
Compare implementation, licensing or subscription, infrastructure, operations, support, data retention, testing, change management, and future upgrade cost. A lower migration price can create a higher operating cost if it preserves unnecessary complexity.
RISE can be the right operating model when the organization wants a subscription-based route to SAP cloud ERP, contracted technical operations, and a structured cloud-transformation program. It should still be tested against the same questions as any other target model:
- Which transition paths are supported for the proposed target edition?
- Which operational responsibilities remain with the customer or implementation partner?
- Which custom code, add-ons, integrations, and security controls are included in scope?
- What service levels, maintenance windows, capacity assumptions, and commercial metrics drive the contract?
- What does the five-year cost look like under realistic growth and usage?
Do not let the contract decision substitute for the architecture decision. Decide what should change, what should remain, and what evidence must survive before choosing who operates the target.
A practical 90-day decision sequence
- Establish the source-system facts. Confirm enhancement package, maintenance eligibility, database, add-ons, interfaces, custom code, data volume, archiving, and business-critical batch windows.
- Quantify reuse versus redesign. Complete fit-to-standard workshops for the processes with the most customization, manual work, control exceptions, and business dissatisfaction.
- Set the data and evidence strategy. Decide what history migrates, what is archived, and how transactions remain traceable across cutover.
- Shortlist feasible transition and operating models. Eliminate options that fail regulatory, timeline, deployment, or organizational constraints.
- Price the complete decision. Compare five-year cost and risk using common assumptions, then document why the selected path wins.
1. Is 2027 a hard cutoff for SAP ECC?
It is the end of mainstream maintenance for the SAP Business Suite 7 core applications and enhancement packages covered by SAP’s commitment. Optional extended maintenance runs through 2030. Customer-specific maintenance and a conditional private-edition transition option may exist afterward, but neither should be treated as a reason to delay planning.
2. Is RISE with SAP a brownfield or greenfield approach?
Neither. RISE is primarily a commercial, cloud-transformation, and operating-model offering. The underlying implementation can still require system conversion, new implementation, or selective data transition, depending on the source and target landscape.
3. Can we combine migration approaches?
Across a landscape, yes. Different systems, entities, or waves can follow different paths. Within one system, however, a technical system conversion is system-wide. If the goal is to redesign selected processes or migrate selected history while phasing organizational units, evaluate selective data transition rather than describing the plan as a simple module-by-module brownfield conversion.
4. Which approach is fastest?
System conversion is generally the most direct technical path when the current system is healthy and largely worth retaining. The fastest credible option still depends on custom code, data volume, interfaces, add-ons, testing, and business readiness. A readiness assessment should size those facts before a timeline is committed.
