S/4HANA migration timeline and project plan by path

In my experience, an S/4HANA migration timeline from SAP ECC runs 12 to 18 months for a brownfield conversion and 18 to 24 months for a greenfield implementation. A selective data transition takes 12 to 18 months. The project plan follows the six SAP Activate phases, and the phase that overruns most often is custom code.

Short answer: start the plan with the SAP Readiness Check and give data 30 to 40 percent of the effort. On a brownfield, plan three mock conversions and expect cutover downtime of anything from a weekend to a week.

This article is the timeline and planning detail behind my ECC to S/4HANA migration guide, which covers the paths and the ECC deadlines. If you are implementing SAP fresh rather than moving off ECC, my SAP implementation timeline guide covers that case, with phase durations.

The path sets the length. My rule: greenfield when you are moving from other systems or new processes must be defined. Brownfield when processes are defined and working, and selective when the processes of some areas need to be redefined.

This is how long each path takes in the programmes I have seen, and what usually stretches it:

Path	Typical timeline	What the plan is built around	What usually stretches it
Brownfield (system conversion)	12 to 18 months	Converting the existing ECC system with the Software Update Manager, then repeated test conversions	Custom code adaptation and the business partner conversion
Greenfield (new implementation)	18 to 24 months	Fit-to-standard design, build and repeated data load cycles	Explore workshops that turn into long requirement lists, and data cleansing
Selective data transition	12 to 18 months	Agreeing which company codes, units and history move, then specialist tooling	Data scoping and dependence on specialist partners

The calendar matters as much as the path. For ECC on enhancement packages 6 to 8, mainstream maintenance ends on 31 December 2027 (SAP News). A brownfield started this month goes live between October 2027 and April 2028, and a greenfield started now lands in 2028.

So most plans written today need some extended maintenance in the budget. Put it in at the start, not as a surprise in year two.

RISE with SAP is a commercial package, not a path. A brownfield or selective move under RISE lands on SAP Cloud ERP Private, the current name SAP uses for what many still search as S/4HANA Cloud Private Edition. The 6 to 9 months I quote for GROW with SAP and 9 to 18 months for RISE are for new implementations, not ECC moves.

SAP Activate is SAP's delivery method for S/4HANA. It has six phases: Discover, Prepare, Explore, Realize, Deploy and Run (SAP Activate).

A migration uses the same phases. What changes is the work inside each one.

The migration project plan

1. 01

   Discover

   Readiness Check, path decision and business case.

2. 02

   Prepare

   Plan, governance, team and first sandbox.

3. 03

   Explore

   Fit-to-standard or delta design, WRICEF list agreed.

4. 04

   Realize

   Build, custom code, data loads, test conversions.

5. 05

   Deploy

   Dress rehearsal, cutover and go-live.

6. 06

   Run

   Hypercare, stabilise and decommission ECC.

This is what each phase holds on a migration, and where the paths differ:

Phase	What happens on a migration	How the paths differ
Discover	SAP Readiness Check, path decision, business case, first view of custom code and data	Selective needs a first data scope here
Prepare	Plan, governance, team, data ownership, sandbox	Brownfield runs a first sandbox conversion; greenfield sets up the system and the workshop schedule
Explore	Fit-to-standard workshops or delta design, WRICEF list agreed, data mapping	Greenfield spends longest here; brownfield works through the simplification items that apply
Realize	Build, custom code adaptation, data load cycles, test rounds	Brownfield runs mock conversions; greenfield runs load cycles, usually with the Migration Cockpit
Deploy	Dress rehearsal, cutover, go-live	The downtime window depends on path, data volume and approach
Run	Hypercare, stabilisation	Decommission ECC and archive what you kept

WRICEF stands for workflows, reports, interfaces, conversions, enhancements and forms. It is the list of everything you build beyond SAP's standard, and it is the number to watch.

Across the 21 SAP programmes I have led or rescued, the biggest mistake is not planning properly at the start of the implementation. In Prepare, agree who owns data cleansing, which custom code gets retired and when each test conversion and rehearsal happens. Those dates become the spine of the plan.

Brownfield: plan around test conversions

A brownfield plan is built around the conversion cycle. The Software Update Manager converts the system, and each test run tells you how long the real one will take and what breaks.

I plan three mock conversions before cutover on a brownfield. Each should run on a recent copy of production, so the timings mean something. The last one should behave like go-live: same sequence, same people, same checks.

SAP's own plan for its downtime-optimized approach is similar. It sets out a sandbox run, a quality assurance run, a load verification on a clone and a dress rehearsal (SAP Learning). SAP notes that fewer runs are technically possible but increase the risk.

Greenfield: plan around design and data loads

Greenfield time goes into Explore. Fit-to-standard workshops decide how much of SAP's standard you adopt, and every gap becomes a WRICEF object to build, test and maintain.

Data moves in load cycles, usually with the SAP S/4HANA Migration Cockpit. Plan several full load cycles, each followed by a reconciliation that the business signs. My Migration Cockpit step-by-step guide covers staging tables, migration objects and the load process.

Selective: plan around the data scope

A selective plan starts with a data scope. Which company codes, business units and years of history move, and which processes get redesigned.

That scope drives the tools, the specialist partner and the test cycles. Change it late and the timeline moves with it.

In my experience custom code is the phase that overruns most often. It is also the most forgotten hidden cost on a migration, which my S/4HANA migration cost guide covers.

These are the places I would watch, in order:

1. Custom code. Teams scope it from a report, then find the real size when remediation starts. On one programme, analysis with smartShift cut custom objects from 18,000 to 3,200. Retire first, adapt second.
2. Custom objects the assessment missed. In my experience the custom objects the SAP Readiness Check misses are the ones that hurt later. Read my SAP Readiness Check guide before you treat its output as your scope.
3. Data. Data migration takes 30 to 40 percent of the effort. When cleansing has no owner it starts late, then squeezes the test cycles. My article on why SAP data migration fails goes deeper.
4. Explore. Budgets get hit in Explore, as the WRICEF list grows. When the vendor controls the scope, nobody on the vendor side has a reason to stop it growing.
5. Rehearsals cut to save time. A rehearsal dropped to protect the date tends to cost more time on go-live weekend than it saved.

My view: lock the go-live date at the end of Explore, when the WRICEF list and the custom code scope are known. A date set at kickoff is a guess with a board presentation attached.

The cutover downtime I have seen ranges from a weekend to a week. Data volume, the conversion approach, the number of entities and interfaces going live together and how quickly the business can validate all move it.

For a brownfield, SAP offers a downtime-optimized conversion approach in the Software Update Manager. It moves part of the data conversion and migration into uptime, while production keeps running.

It is not free time. SAP lists extra test runs, more complex planning, freezes on customizing and development before downtime, and an expert trained in the approach.

So agree the downtime the business can accept before you choose the technical approach. Then prove it in the mock conversions, not on go-live weekend. Keep the cutover clear of month-end close and peak season.

A plan is only as good as the assumptions behind it. These are the questions I would ask before anyone signs:

1. Which path does the plan assume, and what in our Readiness Check results supports it?
2. How many custom objects are in scope after usage analysis, and how many will be retired?
3. Who owns data cleansing, and in which phase does it start?
4. How many mock conversions or load cycles are planned, and on what data?
5. What downtime does the plan assume, and which test run proves it?
6. When is the date locked, and what happens to it if the WRICEF list grows in Explore?

Ask the partner for references from programmes like yours and for their high-level design. If the answers are generic and not specific to your business, treat that as a red flag.

Run the SAP Readiness Check this quarter. Put the custom code and data findings in front of the CFO and the programme director before anyone commits to a go-live date.

Then build the plan backwards from the cutover window you can accept, with three mock conversions on a brownfield or the load cycles your path needs. To test the path itself first, try my greenfield vs brownfield migration assessment.

I help organisations build and pressure-test migration plans like this one. If you want an independent view, get in touch.

How long does an S/4HANA migration take?

In my experience a brownfield conversion from ECC takes 12 to 18 months, a greenfield implementation 18 to 24 months and a selective data transition 12 to 18 months. Custom code is the phase that overruns most often, and data migration takes 30 to 40 percent of the effort.

What are the phases of an S/4HANA migration project plan?

The plan follows SAP Activate: Discover, Prepare, Explore, Realize, Deploy and Run. On a migration, Discover holds the Readiness Check and path decision, Realize holds custom code, data loads and test conversions, and Deploy holds the dress rehearsal and cutover.

How many mock conversions do you need for an S/4HANA brownfield migration?

I plan three mock conversions before cutover on a brownfield. For its downtime-optimized approach, SAP sets out a sandbox run, a quality assurance run, a load verification and a dress rehearsal, and says fewer runs increase the risk.

How long is S/4HANA cutover downtime?

The cutover downtime I have seen ranges from a weekend to a week. It depends on data volume, the conversion approach and how many entities and interfaces go live together. SAP's downtime-optimized conversion moves part of the work into uptime but needs more test runs and planning.

Can we finish an S/4HANA migration before ECC support ends in 2027?

Mainstream maintenance for ECC on enhancement packages 6 to 8 ends on 31 December 2027. A brownfield started in October 2026 goes live between October 2027 and April 2028, and a greenfield in 2028. Most programmes starting now should budget for some extended maintenance.

What delays S/4HANA migration projects the most?

In my experience custom code overruns most often, followed by data cleansing that starts late and a WRICEF list that keeps growing in Explore. Not planning properly at the start of the programme is the root of most of these.