The clock is ticking. Mainstream support for SAP ECC ends on 31 December 2027, and according to the DSAG 2025 survey (the German-speaking SAP user association), roughly 50% of companies still have their entire SAP S/4HANA migration ahead of them. For an executive committee, that means the migration decision is no longer a long-term strategic question — it is an operational and urgent one. Organisations that start late will find no available partners, no reasonable project windows, and at worst will be running their critical ERP without vendor support.
This guide is aimed at IT directors, CFOs, and transformation leaders who need to make an informed decision: what the 2027 deadline actually means, which migration approach fits each organisation, what RISE with SAP is, and how to plan a project that — depending on complexity — can take anywhere from six months to well over two years. No hype, and every figure traceable to a real source.
The SAP ECC Deadline: What 2027 and 2030 Really Mean
The date that matters is 31 December 2027. That is when mainstream support for SAP ECC 6.0 and SAP Business Suite 7 ends. After that point, SAP documentation and analyses from Rimini Street and SEIDOR confirm the existence of an extended maintenance option that stretches support to 31 December 2030 — but with terms worth reading carefully.
That extended maintenance is not free. According to Rimini Street, extended maintenance for ECC (enhancement packages 6 through 8) beyond 2027 carries a surcharge of approximately 2 percentage points on the maintenance base — roughly 9% on top of what is already being paid — through the end of 2030. In other words, the "more time" option has a recurring cost and buys only a three-year extension, not a solution.
There is a third path for the most complex cases. In Q1 2025, according to Rimini Street, SAP announced the SAP ERP, private edition, transition option: a package within RISE that extends ECC support beyond 2030, but only for selected, complex customers who sign a RISE agreement. It is not a general escape route; it is a contractual bridge for large landscapes that will not be ready in time.
Is the Industry Ready for 2027?
No. Data from the DSAG 2025 survey, reported by IT-Onlinemagazin, paint a clear picture:
- Only 16% of companies run S/4HANA exclusively.
- 21% have migrated parts of their landscape.
- 14% have begun the migration process.
- Approximately 50% still have the entire migration ahead of them.
Particularly telling: 37% of respondents indicated they will likely use SAP extended maintenance, which in practice means they are already accepting that their S/4HANA migration will not be finished by the end of 2027.
If more than a third of the ecosystem is already planning to use the paid extension, the conclusion for any organisation is straightforward: the supply of consultants, architects, and migration windows is going to be saturated. Starting early is not a matter of technical prudence — it is a matter of market availability.
The good news is that cloud adoption is accelerating. According to joint research by ASUG and DSAG, S/4HANA Private Cloud usage rose to 33% of companies, up from 11% the previous year, and S/4HANA Public Cloud grew from 6% to 13%. The trend is unambiguous: migration is heading not only to S/4HANA, but predominantly to managed cloud consumption.
Greenfield, Brownfield, or Selective Data Transition: Choosing Your Approach
There is no single way to migrate to S/4HANA. According to the SAP Community and SNP Group, there are three main transition approaches, and the choice drives cost, duration, and risk across the entire project.
Brownfield: Converting the Existing System
The brownfield approach — or system conversion — transforms the existing SAP ECC into S/4HANA while retaining historical data, configuration, and custom developments. It is the least disruptive path: business processes remain largely unchanged. According to the SAP Community and Basis Admin, it is typically the fastest approach, completing in 6 to 12 months.
The trade-off is that technical debt travels with you: years of accumulated customising, inherited processes that may no longer add value, and a data model that is never rethought. It is the right fit for organisations whose processes work, who have invested heavily in valuable customisation, and who need to meet the deadline with minimal operational disruption.
Greenfield: New Implementation with Best Practices
The greenfield approach is a fresh implementation from scratch. Processes are redesigned around SAP best practices and a clean system is built, leaving behind unnecessary customising. It is the most transformative option and the one that best leverages S/4HANA's native capabilities — but it also demands the most change management and redesign effort, and therefore typically takes longer than a brownfield project.
It suits companies that want to reinvent their processes, that have grown through acquisitions with disparate systems, or whose current ECC is so heavily customised that preserving it would perpetuate the problem.
Selective Data Transition (Bluefield): The Best of Both Worlds
Selective data transition, also known as bluefield, is a hybrid approach that selectively reuses data and processes. It allows, for example, redesigning the areas that need it while retaining master data and historical records that still add value. It gives granular control over what is migrated, but requires specialised tooling and expertise — and like greenfield, it typically takes longer than a straight brownfield conversion.
Approach Comparison Table
| Criterion | Brownfield (conversion) | Greenfield (new implementation) | Selective data transition (bluefield) |
|---|---|---|---|
| Starting point | Existing ECC system | Clean slate | Hybrid |
| Business processes | Retained | Redesigned with best practices | Selectively redesigned |
| Data | Fully migrated | Loaded selectively | Selective reuse |
| Typical duration | 6–12 months (fastest) | Longer than brownfield | Longer than brownfield |
| Technical debt | Carried forward | Eliminated | Controlled reduction |
| Ideal profile | Working processes, minimal disruption | Deep transformation, M&A | Granular control, critical data to preserve |
Sources: SAP Community, SNP Group, and Basis Admin.
For many organisations, the choice of approach is closely linked to the infrastructure strategy they want to adopt. If the project is also an opportunity to exit an on-premises data centre, it is worth planning the SAP workload cloud migration in parallel, because the destination — hyperscaler, managed private cloud, or RISE — shapes the technical design from day one.
What Is RISE with SAP and When Does It Make Sense?
RISE with SAP is SAP's offering that bundles migration and cloud operations into a single contract. According to SAP documentation and the SAP-PRESS blog, RISE combines S/4HANA Cloud Private Edition with the SAP Business Technology Platform (BTP), SAP Business Network, and SAP Signavio, all deployed on hyperscaler infrastructure including Microsoft Azure, AWS, and Google Cloud.
The value proposition is consolidation: instead of managing licences, infrastructure, process tools, and business network separately, the organisation contracts a managed service with a single party accountable for the SLA. For companies looking to exit on-premises and reduce the operational burden on their IT team, it is an attractive route.
When Does RISE Make Sense — and When Does It Not?
RISE is a particularly good fit when:
- The goal is to transform both the ERP and the infrastructure model at once, avoiding two consecutive projects.
- The internal Basis and infrastructure team is small and the organisation prefers to outsource operations.
- Integrated access to BTP, Signavio (for process mining and redesign), and Business Network from day one is a priority.
- For very complex landscapes, the aforementioned transition option is needed to extend ECC support beyond 2030.
It deserves more careful scrutiny when the company already has a consolidated cloud strategy with a specific hyperscaler and its own agreements, when a strong internal team prefers to retain operational control, or when data residency and customisation requirements conflict with the standardised managed private cloud model. In those cases, an S/4HANA migration on self-managed cloud infrastructure may offer more flexibility, at the cost of greater operational responsibility.
The practical recommendation: do not treat RISE as an all-or-nothing binary decision. Evaluate it module by module against the alternatives — ideally with a partner who has no incentive to push a single model.
How Long and How Much Does an S/4HANA Migration Project Cost?
It is the first question every leadership team asks, and the honest answer is: it depends on size, complexity, and approach. But there are documented reference ranges.
According to the SAP-PRESS blog and IgniteSAP, an SAP S/4HANA migration typically takes between 6 and 18 months as a general range, with these brackets by company profile:
| Organisation profile | Estimated migration duration |
|---|---|
| General project / limited scope | 6–18 months |
| Mid-size company | 12–24 months |
| Large enterprise / complex landscape | 30+ months |
| Prior planning and alignment (additional) | 4–6 months |
Sources: SAP-PRESS Blog and IgniteSAP.
Two important caveats. First, those 4 to 6 months of prior planning and alignment are not optional: they happen before the technical project clock starts and typically make the difference between a controlled project and one that derails. The rush to "start configuring" tends to be expensive. Second, the chosen approach matters: a well-scoped brownfield can close at the low end (6–12 months, per the SAP Community and Basis Admin), while a transformative greenfield at a large enterprise easily approaches 30 months or more.
On cost, the ranges vary so widely by organisation that any generic figure is misleading. The variables that really drive it are the number of users and modules, the volume of custom developments to be rewritten or retired, the licensing model (RISE versus perpetual licences plus infrastructure), and the degree of process redesign. Cost cannot be estimated reliably without a prior assessment of the current system. What is certain is the cost of not deciding: the ~9% surcharge for extended maintenance and the growing risk of finding no implementation resources as 2027 approaches.
How to Plan the Project: A Step-by-Step Roadmap
An S/4HANA migration cannot be improvised. Here is a six-phase roadmap that structures the work and reduces risk.
Phase 1 — Assessment and Readiness Check
Run the SAP Readiness Check against the current ECC system to inventory customising, add-ons, database size, required simplifications, and compatibility. This is the diagnostic that informs every subsequent decision. Without this baseline, any timeline or cost estimate is guesswork.
Phase 2 — Approach and Destination Decision
With the assessment in hand, decide between brownfield, greenfield, or selective data transition — and in parallel, the infrastructure destination: RISE, hyperscaler with owned licences, or private cloud. These two decisions are coupled and should be made together.
Phase 3 — Business Case and Approval
Translate scope into a business case: investment, avoided extended-maintenance surcharges, process benefits, and a realistic timeline (accounting for the 4–6 months of prior planning). This is the moment to align the CFO and COO before committing resources.
Phase 4 — Design and Data Cleansing
Redesign the target processes (in greenfield and bluefield) and, in all cases, address data quality and cleansing. Migrating dirty data into S/4HANA is one of the most common and costly mistakes. Data cleansing is not a minor technical task — it is a project in its own right. This phase also determines which custom developments are retained, rewritten, or retired.
Phase 5 — Build, Migration, and Testing
Build the system, execute data conversions or loads, and address testing comprehensively: unit, integration, regression, and user acceptance testing, plus performance testing. This is a good moment to automate everything that can be automated — regression cycles, data validations, repeatable deployments — drawing on process automation practices that accelerate testing and reduce human error in data loads.
Phase 6 — Cutover, Go-Live, and Support
Plan the cutover with a realistic window, execute go-live, and establish a hypercare period with reinforced support. Post-launch stabilisation is part of the project, not an afterthought.
Pre-Launch Checklist
- Readiness Check executed and analysed
- Approach (brownfield / greenfield / bluefield) decided and justified
- Infrastructure destination defined (RISE vs. self-managed cloud)
- Custom development inventory with keep / rewrite / retire decision
- Data cleansing and migration strategy
- Testing plan and change management plan
- Executive sponsor and project governance assigned
Common Mistakes and Critical Success Factors
S/4HANA projects that run into trouble rarely fail because of technology — they fail because of planning and people. These are the patterns that recur most often.
Underestimating prior planning. Skipping the 4–6 months of alignment documented by SAP-PRESS and IgniteSAP is the root cause of most schedule overruns. The rush to "start configuring" usually proves expensive.
Migrating data without cleansing it first. Carrying over duplicate master data, obsolete records, or inconsistent structures contaminates the new system from day one. Data cleansing is not a minor technical task — it is a project in itself.
Treating the approach as an isolated technical decision. Choosing brownfield or greenfield without aligning the choice with the process and infrastructure strategy leads to incoherent solutions. Approach, cloud destination, and process redesign are a single conversation.
Confusing the deadline with slack time. With 37% of the ecosystem already planning extended maintenance according to DSAG, consultant availability will tighten. Organisations planning to start "in 2027" will likely not find the team they need.
Neglecting change management. A greenfield project redesigns how hundreds of people work. Without training and proper accompaniment, even the best technical system runs into user resistance.
Critical Success Factors
- Visible executive sponsor and clear project governance.
- Rigorous assessment as the basis for all estimates.
- Data quality addressed from the start, not deferred to the end.
- Automated, comprehensive testing before cutover.
- Partner with real experience in migrations of a similar profile and no bias toward a single infrastructure model.
Conclusion
The 2027 deadline is not a recommendation — it is a date with economic consequences (the ~9% extended maintenance surcharge through 2030) and operational ones (the resource scarcity that DSAG data already foreshadows). With half the ecosystem yet to migrate and a third already planning to pay for an extension, the competitive advantage lies in deciding early and well: choosing the right approach — brownfield, greenfield, or selective data transition — evaluating RISE with SAP against the alternatives on its merits, and planning with the discipline of the six phases.
At Technova Partners we support companies through the full cycle: from the readiness check and approach decision through to cutover and stabilisation, with an honest perspective on cloud infrastructure and test automation. If you would like an assessment of your current system and a tailored roadmap to S/4HANA, let's talk about your migration project. The best time to start planning was yesterday; the second best is today.
