Five steps. Assess the current system. Choose an approach. Plan the programme and prepare the data. Run the conversion. Then stabilize and optimize. Brownfield takes twelve to eighteen months. Greenfield runs eighteen or more. Mainstream ECC maintenance stops on 31 December 2027. Start after late 2026 and you should budget for extended maintenance at the 2% premium.

Count the months. It is October 2026. Mainstream ECC maintenance stops on 31 December 2027. Fourteen left.

A brownfield conversion takes twelve to eighteen of those. That is if nothing goes wrong. Something generally does. Around month four, in custom code nobody has opened since 2014.

Most guides on this were written while the arithmetic still worked. They tell you to start planning. Nobody tells you what to do when the numbers no longer reach.

How long does an SAP S/4HANA migration actually take from here?

Put the same ECC system in front of three partners and you get three timelines back. All three are optimistic. The bands below run kickoff to stable go-live. Partners quote you kickoff to the first sandbox, which is a different number entirely.

Miss the date and nothing breaks on 1 January 2028. SAP sells extended maintenance. A 2% premium on your existing support fee, running through the end of 2030. The catch is that you sign up to S/4HANA to get it. Certain RISE accounts get longer again. Which bucket you fall into is something your account executive can answer in ten minutes. Worth doing that before anybody builds a plan around a date you cannot reach.

You would be in crowded company. Of the ECC owners Gartner looked at in mid-2024, 63% had not licensed S/4HANA at all. SAPinsider put half its respondents still in evaluation. Every one of them is queuing for the same partner capacity in 2027.

Nothing moves the timeline like the deployment decision. On-premise, private cloud, public cloud. Our breakdown of cloud or on-premise runs through what each one costs.

Which migration approach fits: greenfield, brownfield, or selective?

Three routes exist. Partners tend to recommend whichever one they staff best. Choose the state of your processes today.

Vendors call the third one bluefield. SAP calls it selective data transition. Same thing, and SAP’s name is the one printed in the documentation you will be reading. Whichever route you take, the far end is SAP S/4HANA. What changes is how much of 2009 travels with you.

A quick test before anybody commits. Pull up the last three process changes finance asked for. Check how long each took. Did everyone need a developer and a change request? Greenfield gives you a way out. Do your processes mostly work, with performance the real complaint? Brownfield gets you live in roughly half the months, and your users keep the screens they know.

What are the 5 SAP S/4HANA migration steps?

SAP Activate names its phases Discover, Prepare, Explore, Realize, Deploy and Run. Every partner methodology is a repaint of those. The five SAP S/4HANA migration steps below use the words people actually say in a steering committee.

Step 1: Assess what you have and decide what you want

Six to ten weeks. Skipping it is the most expensive decision on the table. Everything downstream prices off what this step finds.

Run SAP Readiness Check

SAP Readiness Check reads your production system. It reports on simplification items, custom code, add-on compatibility and data volume. It maps Fiori apps to what you run today. Setup takes a few days. A Basis person needs half a day to read it properly. Most teams leave it until month three. By then the scope is written. Findings become change requests instead of planning inputs.

Inventory the custom code

Pull the usage statistics alongside the object list. On a twenty-year-old ECC, a third to half of custom objects have not been executed in a year. Those get retired, not remediated. Every retirement is a line item off the budget.

Profile the data, do not assume it

Somebody will tell you the master data is fine. Check. Count duplicate vendors. Customers with no tax ID. Materials with a status nobody can explain. The 2024 UK and Ireland SAP User Group survey put data management top of the headache list. Three-quarters of respondents said so. Hardly any of them had it in the plan at kickoff.

An independent read before you shortlist partners is money well spent. SAP Discovery and Evaluation exists for that. Still building the business case? Our pre-migration check piece is the place to start.

Step 2: Choose your approach and freeze the scope

Two to four weeks on paper. Longer in practice. This is where the organisation argues.

Step 1 hands you the approach almost mechanically. The argument is about what waits for phase two. Write that list down. Get it signed by somebody whose name carries weight. Scope that never froze does not slip by weeks. It slips by quarters. Every new request sounds reasonable on its own.

Licensing gets settled here too. S/4HANA prices on Full Use Equivalents, not named users. The count rarely maps off your ECC licence. Get a written sizing before you sign anything. That gap has surprised plenty of finance directors.

Step 3: Plan the programme and prepare the data

Three to five months. The longest pole is almost always data.

Staff the team before the plan goes final. You need a Basis lead who has done a conversion. A functional owner per module who can decide without escalating. An ABAP resource for remediation. And somebody who owns master data and is not juggling three other jobs. That last role gets skipped on every programme that later runs late.

Cleansing starts now, alongside everything else. Do the duplicate vendors in ECC, not after the load. Somebody in purchasing can still tell you which of the four records is the live one. Leave it to cutover weekend and that answer comes from whoever is awake at two in the morning.

Change management belongs here. Not two weeks before go-live. Fiori rewrites how people navigate. Somebody who has typed ME21N every morning for fifteen years will not be reskilled by a PDF and a cheerful email.

Step 4: Execute the conversion

Three to six months. This is the part people picture when they say migration. Rarely the part that breaks.

Brownfield runs on Software Update Manager with the Database Migration Option. One run moves you to HANA and converts the data model. Plan on three or four rehearsals. Number one always overruns its window. Number three is the one you can actually plan a cutover around.

Testing is where the schedule gets eaten. Budget two full regression cycles. Plus a user acceptance pass. Resist every request to compress them. Programs that squeezed testing to protect a date paid for it in the first month of hypercare. With interest.

Cutover runs over a weekend for most mid-sized landscapes. Longer on heavy data volumes you never archived. Write the rollback plan anyway. The people signing off need to see that it exists.

Step 5: Stabilise, then optimise

Four to six weeks of hypercare, then ongoing. The SAP S/4HANA migration process does not end at go-live. Whatever the project plan says.

Watch adoption, not uptime. A green dashboard means nothing if procurement went back to the spreadsheet. Track which Fiori apps get opened. Chase the ones that do not. That is where the training gap surfaces first.

The optimisation half is what companies pay for and forget to collect. Embedded analytics. The AI-enabled features ship with your release. The reporting finance gave up asking for ECC. None of it switches itself on. Put a quarterly review in the calendar. Give somebody the job.

How does data migration work in SAP S/4HANA?

Loading runs through SAP Migration Cockpit. File upload is fine until volumes get serious, at which point most teams move to staging tables. You write in, validate there, then load. Migration Object Modeler handles the object mapping, and you will end up in it, because the standard templates always miss a field your business depends on. SAP S/4HANA Data Migration is the service side of this, for anyone who would rather not learn it on live production data.

What travels matters more than how. Sort it three ways. Hot is what the business touches daily, and that goes across. Warm gets queried at quarter end and can sit in a cheaper tier. Cold is what you keep in case an auditor asks. Archive it.

Bringing fifteen years of history across is the most common way a conversion window doubles. It happened because nobody wanted to make the call. Ask finance how far back they genuinely look. Usually two years. Occasionally five. Almost never fifteen.

Why Clean Core decides how painful your next upgrade is

Clean Core means your extensions live outside the digital core. No modifications to standard objects. No enhancements hanging off SAP code. No Z tables doing work a released API could do. Build on SAP Business Technology Platform instead. Call into S/4HANA through interfaces SAP has committed to keeping stable.

The payoff arrives later. That is why it loses arguments during the build. Custom code runs past 30% of scope on a typical conversion. Every object left in the core is an object somebody re-tests at the next upgrade. Teams who took Clean Core seriously call their upgrades a weekend job. The rest call them projects.

Be pragmatic about it. Not every enhancement moves on day one. Pretending otherwise just delays go-live. Draw up the list. Move what you can. Document what stays, with a reason and a name against it. Six months into hypercare is a fair point to clear the rest.

What AI changes about an S/4HANA migration in 2026

Two things have shifted since the guides on page one were written. The first is on the destination side. S/4HANA ships are AI-enabled now. Joule sits across the user experience. Finance and supply chain get predictive capabilities. Exceptions route to whoever can resolve them. ECC never got any of that. It never will. SAP Business AI is where that functionality lives. It only runs on the newer stack.

Which changes what waiting costs you. Sitting on ECC until 2029 stopped being a support decision. It is three years of watching competitors run things your platform physically cannot host.

The other change is in the delivery work itself. AI-assisted tooling now reads custom code and proposes the remediation, rather than handing you a list of flagged objects. Weeks come off the longest phase of a brownfield conversion. Data profiling used to mean a consultant writing queries for a fortnight. Duplicates now surface on the first pass. Somebody still has to decide what to do about them. Finding them stopped being the slow part.

None of that adds up to an automated migration, and anyone selling you one is selling something else. Judgement calls stay human. So do the scope arguments and the fight over which company code goes first. The dull high-volume analysis in the middle is what moved. Days now, where it used to be weeks.

Where S/4HANA migrations go wrong

Rarely the technology. SUM does what SUM does. HANA behaves. The failures cluster somewhere else.

• Scope that never froze. Requests keep arriving, each one small. By month seven the plan looks nothing like the one that got funded.
• Custom code found late. The inventory ran in month four instead of month one. Remediation lands on the critical path with nothing around it.
• Data quality taken on trust. Nobody profiled anything. Duplicates surface in the second test load with six weeks left.
• Testing compressed to protect a date. The date gets hit. The following month costs more than the time saved.
• No owner for master data. Four people have opinions about the vendor master. None of them can decide.
• Training is treated as a go-live task. Users meet Fiori the week it becomes mandatory. The service desk absorbs it.

Every one is a planning failure wearing a technical delay. Which is why the first two steps deserve more calendar than they get.

How Accely runs an SAP S/4HANA migration

Accely has been doing SAP work for 26+ years. SAP Gold Partner. CMMI Level 5. Delivery out of 20+ offices across 17 countries. More than 1,000 clients will take a reference call. That is the number worth asking any partner for.

We start with an assessment, not a proposal. A proposal written before anybody reads your Readiness Check output is guesswork with a logo on it. The assessment tells you which approach fits. What the custom code will cost. And whether your date survives contact with your own system.

Delivery is AI-assisted throughout. Our consultants run AI tooling for code analysis and data profiling. That compresses the two phases that usually overrun. People still make the decisions. We build to Clean Core by default. We will also argue with you about the exceptions. The alternative is handing you a system that is expensive to upgrade and calling it done.

Think AI-First. Build What’s Next. Powered by Eerly AI Studio™.