ECC to S/4HANA migration: paths, steps and SAP ECC deadlines

An ECC to S/4HANA migration moves your SAP ERP system from SAP ECC 6.0 to SAP S/4HANA, with a new database, finance data model and user interface. The decision you face is which path to take, and whether you can go live before ECC mainstream maintenance ends on 31 December 2027.

Short answer: greenfield if you come from other systems or need new processes, brownfield if your processes are defined and working, selective data transition if only some areas need redesign. In my experience brownfield takes 12 to 18 months, greenfield 18 to 24 months and selective data transition 12 to 18 months. Run the SAP Readiness Check before you commit to any of them.

ECC to S/4HANA is not a straight upgrade. It changes how data is stored, how transactions post and how users work.

In one project I worked on, a team had dozens of custom reports rebuilt exactly as they were in ECC. Nobody asked whether they were still needed. Later, half of them were never used.

The migration was technically clean. The value was not.

SAP ECC stands for SAP ERP Central Component. It is the core of SAP ERP 6.0, one of the core applications of SAP Business Suite 7, and when people say "SAP ECC" they almost always mean ECC 6.0. It runs finance, controlling, purchasing, sales and production on any database SAP supports, from Oracle to SQL Server and Db2.

The first reason to move is maintenance. For SAP ERP 6.0 on enhancement packages 6 to 8, mainstream maintenance ends on 31 December 2027. Systems on enhancement package 5 or lower left mainstream maintenance at the end of 2025 (SAP).

SAP S/4HANA is the successor, and SAP has committed to maintain it until the end of 2040.

The second reason is time. Start a brownfield conversion today, in October 2026, and go-live lands between late 2027 and spring 2028. Start greenfield today and you go live in 2028.

So for most ECC customers the question is no longer whether to move. It is which path, and how much extended maintenance to budget for while you do it.

I explain why a lift and shift is the wrong way to approach this move in a video on my YouTube channel.

These are the differences that drive most of the migration effort:

Area	SAP ECC	SAP S/4HANA
Database	Any supported database (Oracle, Db2, SQL Server, others)	SAP HANA only
Finance data model	Separate FI, CO and profitability tables with totals tables	Universal Journal (table ACDOCA) as the single line-item source
Customer and vendor master	Separate customer and vendor records	Business partner is mandatory
Material number	18 characters	Up to 40 characters, if you switch on the extended length
Credit management	SD credit management	SAP Credit Management (FIN-FSCM)
User interface	SAP GUI	SAP Fiori apps, with SAP GUI still available on-premise and in Private Edition
Deployment	On-premise	On-premise, Private Edition (RISE with SAP) or Public Edition (GROW with SAP)
Extensions	Z-programs and modifications	Clean core: released APIs, ABAP Cloud on-stack or side-by-side on SAP BTP
Maintenance	EHP 6 to 8 mainstream to end 2027, extended to end 2030	Committed until the end of 2040

SAP records each of these differences as a simplification item and publishes them in the Simplification List for every S/4HANA release. Some are mandatory for every customer, such as the business partner. Others only matter if you use the function, and the SAP Readiness Check tells you which apply to your system.

A European manufacturing client I worked with in 2023 kept asking why their custom batch jobs were no longer working after the conversion. The logic relied on ECC table structures that S/4HANA had changed. Nobody had asked whether those jobs still made sense in the new model.

The migration moves the data. The real question is what you do with the design decisions you inherit.

My rule for choosing is short. Greenfield when you are moving from other systems or when new processes need to be defined. Brownfield when your processes are defined and working, and selective data transition when the processes of some areas need to be redefined.

Decide

Which ECC to S/4HANA path fits your situation?

Moving from other systems, or new processes need to be defined

→Greenfield

Processes are defined and working

→Brownfield

Only some areas need their processes redefined

→Selective data transition

Greenfield: a new implementation

A new implementation of S/4HANA. No legacy configuration is carried forward, processes are designed against SAP's standard and only the data you need is loaded.

It is the natural choice if part of your business runs on non-SAP systems today. I have seen companies regret not preparing their users for how different things feel in a greenfield system. If adoption planning starts at training, it is already late.

Brownfield: system conversion

Brownfield is a system conversion. Your existing ECC system is converted in place, and configuration, custom code and history come with you. The technical conversion runs through the Software Update Manager (SUM) with its database migration option.

SAP publishes a Conversion Guide for SAP S/4HANA for every release, with the prerequisites and the order of the technical steps. Read the one for your target release before you plan dates. The risk is the technical debt you carry over, because legacy complexity moves with you unless you clean it up deliberately.

Selective data transition

Selective data transition moves chosen company codes, business units or time slices of data, not everything. It needs specialist tooling and a partner experienced in it. Some vendors sell it as "bluefield".

It suits groups where finance works well but procurement needs a redesign, or where mergers and carve-outs have left very different processes side by side. You redesign the areas that need it and keep history where it counts.

This is how the three compare on the questions boards usually ask:

Path	When to choose	Typical timeline	Main risk
Greenfield	Moving from other systems, or new processes need to be defined	18 to 24 months	Change load on users, and history left behind
Brownfield	Processes are defined and working	12 to 18 months	Technical debt and unused custom code carried forward
Selective data transition	The processes of some areas need to be redefined	12 to 18 months	Dependence on specialist tools and partners, and complex data scoping

The path changes the detail, but the sequence stays the same. These are the five steps I would plan, in order.

The migration sequence

1. 01

   Readiness check

   Run the SAP Readiness Check and confirm the technical prerequisites.

2. 02

   Choose and plan

   Pick the path, set scope and plan the whole programme before build starts.

3. 03

   Custom code

   Find what is used, retire the rest, adapt what remains.

4. 04

   Data

   Classify, cleanse and archive before you move anything.

5. 05

   Test and cut over

   Several test rounds plus at least one full cutover rehearsal.

1. Run the readiness check

Start here. Always. The SAP Readiness Check analyses your ECC system and reports on simplification items, add-on compatibility, custom code, data volumes and sizing.

The surprises are usually the add-ons and the custom code. Some clients I have worked with had hundreds of custom objects in scope. Better to find that in week two than in month twelve.

For a brownfield conversion, check these prerequisites at the same time:

1. Release: conversion works from SAP ERP 6.0 on any enhancement package.
2. Unicode: the system must be Unicode, or you plan a two-step conversion.
3. Dual-stack: dual-stack systems need a split first.
4. Business partner: customer and vendor masters must be converted to business partners before the conversion. This one catches more teams than any other.

2. Choose the path and plan the programme

Use the readiness results and my rule above to choose the path. Then plan the whole programme, including data, testing and cutover, before anyone starts building.

Across the 21 SAP programmes I have led or rescued, the biggest migration mistake I see is not planning it properly at the start of the implementation. Decide in the first weeks who owns data cleansing, which custom code gets retired and when the cutover rehearsals happen. Those decisions are expensive to make late.

3. Adapt the custom code

Run the S/4HANA checks in the ABAP Test Cockpit, which compare your code against SAP's simplification items. The Custom Code Migration app shows the same results with usage data, so you can see what is used before you fix anything.

The goal is less Z-code, not just working Z-code. On one programme, analysis with smartShift took us from 18,000 custom objects to 3,200.

Every custom object you carry over adds cost to every future upgrade. I have seen firms cut upgrade timelines by 40% with clean core principles, and my SAP clean core guide covers how to classify what remains.

4. Prepare and move the data

Classify, cleanse and archive before you move anything. This step takes longer than every plan allows, so it gets its own section below.

5. Test, train and cut over

Run testing in rounds: unit, integration and user acceptance testing (UAT), then at least one full cutover rehearsal. Put both power users and occasional users in UAT, because they find different problems.

The rehearsal is not optional. It exposes timing gaps, missing validations and interface failures that only appear when the whole sequence runs. Teams that skip it meet those problems on go-live weekend.

In my experience data migration takes 30 to 40% of the implementation effort. It is also the most common reason schedules slip.

How the data moves depends on the path. In brownfield, SUM converts the data in place. In greenfield, you load master data and open items with the SAP S/4HANA Migration Cockpit, and in selective data transition specialist tools move the scope you chose.

Whatever the path, sort the data before you move it:

1. Hot: used often, needed for live processing.
2. Warm: occasional access, relevant but not daily.
3. Cold: historical or unused, kept for audit only.

Cold data does not need to go into S/4HANA. Archive it. Duplicate vendor records, inconsistent units of measure and half-filled customer masters exist in every ECC system, and they move into S/4HANA intact if nobody fixes them first.

One client I worked with spent five months just on data cleansing and archiving. My article on why SAP data migration fails goes deeper on this step.

These are the five tools I have used on ECC to S/4HANA programmes. Two are SAP's own and three come from specialist vendors:

Tool	Who makes it	What it does	Where it fits
SAP Readiness Check for SAP S/4HANA	SAP	Reports on simplification items, add-on compatibility, custom code impact, data volumes and sizing	Before choosing the path
Custom Code Migration app	SAP	SAP Fiori app that runs the S/4HANA ABAP Test Cockpit checks and uses usage data to find unused code; runs in S/4HANA or the SAP BTP ABAP environment	Custom code scoping and adaptation
smartShift	smartShift Technologies	Automated analysis and transformation of ABAP custom code for S/4HANA	Custom code analysis and remediation
SNP (Kyano platform)	SNP Group	Data transformation software for selective data transition, sold under SNP's "Bluefield" approach	Selective data transition, mergers and carve-outs
Natuvion	Natuvion Group	Data conversion software and cutover tooling for S/4HANA transitions	Selective data transition and cutover

SNP and Natuvion are both founding members of SAP's Selective Data Transition Engagement community. The other SAP tools you will meet are SUM for the brownfield conversion and the Migration Cockpit for greenfield data loads.

A tool does not replace the decisions. Someone on your side still has to agree what to retire.

For SAP ERP 6.0 on enhancement packages 6 to 8, mainstream maintenance ends on 31 December 2027. Optional extended maintenance runs from 2028 to 31 December 2030, at a premium of two percentage points on your existing maintenance base (SAP News).

Beyond 2030 there is one narrow route, the SAP ERP, private edition, transition option. It gives maintenance from 2031 to 2033 for customers who move their ECC system into SAP's private cloud as SAP ERP, private edition, on SAP HANA, under RISE with SAP. The system must move before 31 December 2030, must be at least 2 TB and needs SAP's max success plan.

So 2033 is not a general deadline. It applies to large systems that have already moved ECC into SAP's cloud. For everyone else, ECC on your own infrastructure has 2027 as the mainstream date and 2030 as the end of extended maintenance.

1. 2027ECC mainstream maintenance ends31 December, for SAP ERP 6.0 EHP 6 to 8
2. 2028Likely go-live if you start nowBrownfield 12 to 18 months, greenfield 18 to 24
3. 2030Extended maintenance endsOptional, at a two-point premium
4. 2033Transition option endsSAP ERP, private edition only, systems of 2 TB or more

Source: SAP News, February 2020 and August 2025

The arithmetic is simple. Budget for at least some extended maintenance, and use the time to clean data and retire custom code rather than to wait.

Cost follows the same drivers as the timeline: the path, the volume of custom code, the state of your data and how many entities go live. Data alone takes 30 to 40% of the effort, which is why a clean data plan saves more money than any rate negotiation. My S/4HANA migration cost guide covers what drives a migration budget, and my SAP implementation cost guide breaks the budget down by company size.

To see how one programme played out, read my ECC to S/4HANA migration case study. To test your own options, try the greenfield vs brownfield migration assessment.

This article is the overview. Each guide below answers one question in full.

1. S/4HANA migration timeline and project plan: phase by phase, by path, with mock conversions and cutover.
2. S/4HANA migration cost: what drives the budget for a conversion, a new implementation or a selective transition.
3. SAP Readiness Check and migration assessment: what the check tells you and what it misses.
4. SAP S/4HANA Migration Cockpit, step by step: loading data with staging tables or direct transfer.
5. RISE with SAP: public vs private cloud: which edition fits your processes.
6. RISE with SAP contract and pricing: what the subscription covers and what to negotiate.
7. How to choose an S/4HANA migration partner: the questions to ask and the warning signs.
8. SAP project recovery: how to rescue a migration that is off track.

Two tools help with the numbers: the SAP implementation cost calculator and the data migration estimator.

What is SAP ECC?

SAP ECC (SAP ERP Central Component) is the core of SAP ERP 6.0, part of SAP Business Suite 7. It covers finance, controlling, logistics and other core processes and runs on several databases. SAP S/4HANA is its successor and runs only on SAP HANA.

How long does an ECC to S/4HANA migration take?

In my experience a brownfield conversion takes 12 to 18 months, a greenfield implementation 18 to 24 months and a selective data transition 12 to 18 months. Data cleansing is the most common reason schedules slip, because data migration takes 30 to 40% of the implementation effort.

What happens after 2027 for SAP ECC?

For SAP ERP 6.0 on enhancement packages 6 to 8, mainstream maintenance ends on 31 December 2027. You can buy optional extended maintenance to 31 December 2030 at two extra percentage points. From 2031 to 2033 maintenance is only available through the SAP ERP, private edition, transition option, for large systems moved to SAP's private cloud before the end of 2030.

Brownfield vs greenfield: which is better?

Neither is better in general. Choose greenfield when you are moving from other systems or new processes need to be defined, and brownfield when your processes are defined and working. If only some areas need redesign, consider selective data transition.

What is selective data transition in SAP?

Selective data transition moves chosen company codes, business units or time slices of data into S/4HANA instead of converting everything or starting empty. It lets you redesign some areas while keeping history in others. It needs specialist tools, such as those from SNP or Natuvion, and an experienced partner.

What are the prerequisites for converting ECC 6.0 to S/4HANA?

Conversion works from SAP ERP 6.0 on any enhancement package. The system must be Unicode, or you use a two-step approach, and dual-stack systems must be split first. Customer and vendor masters must be converted to business partners before the conversion.

What does the SAP Readiness Check tell you?

It analyses your ECC system and reports on the simplification items that affect you, add-on compatibility, custom code impact, data volumes and HANA sizing. Run it early, because teams regularly find add-ons and custom code they did not know they depended on.

Should I choose RISE with SAP or GROW with SAP for an ECC migration?

Most ECC customers with significant custom code and complex processes go to S/4HANA Cloud Private Edition under RISE with SAP, which supports conversion of the existing system. GROW with SAP uses Public Edition, which is a new implementation with standard processes and released-API extensions only. It suits companies willing to adopt SAP's standard.