Most SAP ECC to S/4HANA migrations don't fail during the technical conversion. They fail eleven months earlier, in a meeting where somebody says "we'll sort the master data out later."
That is the honest version of this story. The SUM run itself is a well-documented, heavily tooled procedure your Basis team will execute more or less as SAP wrote it. What breaks projects is everything around it. Customer and vendor records nobody has cleaned since 2011, a Z-program reading a table S/4HANA deleted, three interfaces nobody could name, and a cutover weekend planned as if the finance conversion takes two hours.
So this guide walks the whole SAP ECC to S/4HANA migration: what the 2027 deadline actually means, which transition path fits which situation, the six-phase roadmap, the data objects that genuinely change, and an hour-by-hour cutover sequence with go/no-go gates and a rollback that is more than a sentence in a slide deck.
Key Takeaways
- The date that matters is 31 December 2027 for enhancement packages 6 to 8. Extended maintenance runs to 2030 for roughly two percentage points more on your maintenance base.
- There are three routes, not two. Brownfield takes 9–14 months, greenfield 18–30, and selective data transition sits between them at 12–20.
- CVI is the long pole. Business Partner conversion is mandatory before SUM will run, and it is a data-quality project rather than a configuration task.
- Cutover is decided by dry runs. Three at minimum, and the dress rehearsal produces the timings your plan is actually built from.
- Budget overruns live in four places: data quality, custom code entanglement, unowned interfaces, and test scope that grows after sign-off.
Reading time 14 minutes · written for CIOs, SAP programme leads and Basis teams.
A note on the numbers. Durations, downtime windows and cost splits in this guide are typical ranges for mid-size, single-instance landscapes drawn from SAP's published guidance and delivery experience. They are planning anchors, not commitments. Your own figures should come from a Readiness Check against production and, for cutover, from your dress rehearsal.
SAP ECC End Of Support: Three Dates, And One Is Already Behind You
Every SAP ECC to S/4HANA migration starts from the same three dates, and SAP has not moved them. What changes after each one is support scope, not your ability to run the system. SAP's own product team has published the maintenance timelines for SAP ERP 6.0 if you need the primary source for a steering committee pack.
Which Maintenance Tier Applies To You
Read these three tiers against your enhancement package level first. The tier you are in decides how much runway you actually have, and it is often not the one people assume.
EHP 6–8
SAP ERP 6.0 with EHP 6–8 and Business Suite 7 core. If you were on EHP 0–5, your window closed at the end of 2025 and extended maintenance was never on the table.
Paid Runway
Optional and chargeable, at roughly two percentage points on your maintenance base. Security patches and legal updates continue. New functionality does not.
RISE Only
SAP ERP, private edition, transition option. Narrow eligibility, requires a RISE with SAP subscription, and it extends neither mainstream nor extended maintenance.
What Happens If You Miss The Window
Customer-specific maintenance is not a support tier. It is an accumulating liability with the same invoice attached.
Miss the window without a plan and you drop into customer-specific maintenance: same invoice, far less product. No new security patches, no new legal or regulatory updates, minimal bug fixes. For a company running payroll, tax reporting, or anything a regulator inspects, that matters.
Here is the part executives underestimate. A mid-size brownfield conversion realistically runs 9–14 months. A greenfield build runs 18–30. Count backwards from December 2027 and the comfortable start date was some time last year.
Three Transition Paths, Not Two
Everyone frames this as a binary. Every SAP ECC to S/4HANA migration actually takes one of three routes, and the third is where most complex enterprises land.
Brownfield
Same SID, same history, new data model. You keep configuration that works and buy a supported platform. Fastest route to compliance, and you inherit your own mess.
Greenfield
For when ECC has become archaeology: twelve company codes nobody uses, a chart of accounts that grew by accretion. Rebuilding beats remediating. Change management is brutal.
Selective Data Transition
When the answer is "it depends which entity." Consolidating instances, carving out a division, or running a plant that cannot give you 48 hours. Large estates have crossed in roughly twelve hours of business downtime.
This decision is not primarily technical. It is a question about how much organisational change your business can absorb in the next two years. Answer that first, then let architecture follow. If you want that decision stress-tested against your actual landscape, our SAP implementation and support team runs structured assessments. Still deciding whether SAP is the right platform at all? That is a different question, covered in Odoo vs SAP.
The ECC To S/4HANA Migration Roadmap: Six Phases
SAP Activate structures this as Discover → Prepare → Explore → Realize → Deploy → Run. Here is what each phase means when you are the one doing it.
Discover 4–8 weeks
Run SAP Readiness Check against production. It returns your simplification items, custom code scope, add-on compatibility and sizing. Then build three inventories nobody wants to build: every interface, every custom object, every add-on. Interfaces are the one that hurts, because teams routinely find forty integrations they had no record of. If the target landing zone is a hyperscaler, size it here alongside cloud transformation planning.
OUT → path decision, budget, blocker listPrepare 6–12 weeks
Clear the blockers. Run the Simplification Item Check. Start CVI here, not in month six. Cleanse data in ECC, where it still lives in a system your people understand. Every gigabyte you archive now is downtime you do not spend later.
OUT → clean master data, CVI underwayExplore 8–16 weeks
Fit-to-standard workshops. Process owners decide, function by function, whether to adopt standard or keep the custom variant. Push hard toward standard, because every retained customisation is a future upgrade tax, and SAP's Clean Core direction only widens that gap over time.
OUT → delta design, remediation backlogRealize 16–28 weeks
The build. Code remediation, migration development, integration rebuild, and testing across unit, integration, regression, performance and UAT. Your first dry runs happen here, and the cutover plan stops being a document and starts being a rehearsed procedure.
OUT → tested build, measured cutover timingsDeploy 4–8 weeks
Final dress rehearsal, go/no-go, cutover, go-live. This is where most published guides go vague, so it is mapped hour by hour further down.
OUT → production S/4HANARun ongoing
Hypercare for 30 days, then continuous improvement. Go-live is not the finish line. It is the point at which real users start doing things your test scripts never imagined.
OUT → the value you actually boughtSAP S/4HANA Data Migration: Not ECC On A Faster Database
SAP simplified the data model, and simplification means tables you relied on are gone, merged, or restructured. In finance, four tables you have written reports against for fifteen years become one. SAP's own Conversion Guide for SAP S/4HANA lists every simplification item behind these changes.
Better architecture, and every custom report, extract and interface reading the old tables now needs attention. The finance conversion is also the single longest step inside your downtime window, and volume drives duration directly. Archive aggressively before you convert.
Business Partner And CVI: Start This First
ECC keeps customers and vendors separate. S/4HANA makes the Business Partner the single mandatory object for both, and Customer/Vendor Integration is a hard prerequisite for system conversion. SUM will not proceed without it.
Teams consistently underestimate CVI. The mechanics are straightforward: prepare, cleanse, configure, then synchronise. The pain comes from data quality, and it surfaces in four predictable places:
Start it in month one. Every experienced practitioner will tell you the same thing, usually with feeling.
Logistics And Material Data
Inventory management moves to MATDOC, replacing the MKPF/MSEG structure and the aggregate tables around it. Material numbers extend to 40 characters, pricing conditions restructure, and SD document flow changes.
- MKPF, document headers
- MSEG, document segments
- MARD / MARC, stock aggregates
- Material number: 18 chars
- KONV, pricing conditions
- MATDOC, single document table
- Aggregates calculated on the fly
- Material number: 40 chars
- PRCD_ELEMENTS replaces KONV
- SD document flow restructured
None of this breaks standard SAP. All of it breaks custom code that assumed the old shape.
Custom Code: Most Z-Code Needs Deleting, Not Fixing
The SAP Custom Code Migration app, pointed at an S/4HANA-aware rule set, sorts your estate into three buckets. Usage data from ECC does most of the work for you.
Unused: Decommission
Nobody has run it in two years. ECC usage statistics name these objects precisely, and it is typically 40–60% of the estate. Delete rather than migrate.
Adaptable: Remediate
Mostly mechanical: repoint to new tables, adjust field lengths, replace obsolete function modules. Budget for the hidden one, which is performance. Nested SELECTs inside loops survive on ECC and fall over on HANA under production volume.
Obsolete: Rebuild
Functionality S/4HANA now ships natively, or code so entangled that rewriting beats fixing. Most teams find 30–40% of their custom code duplicates something standard. Where remediation crosses into genuine rebuild, our enterprise software development teams pick up the surrounding applications so the core conversion stays on schedule.
S/4HANA Cutover Planning: The Weekend That Decides Everything
Ask a consultant what went wrong on a failed migration and you will rarely hear "the data model." You will hear about cutover. A cutover plan is not a checklist. It is a script, rehearsed until it is boring. The five numbered circles are go/no-go gates — select one to read what has to be true before you pass it.
The full procedure has run against a production copy, with the real team, at the real hours. Every task duration is measured rather than estimated. Outstanding defects are triaged and accepted.
A cutover without gates is not a plan. It is a hope with timestamps.
Dry Runs: How Many, And What Each Proves
Three at minimum, four if your landscape is complex. Each run has a different job, and the meter shows how much of your window is still guesswork after it.
Prove it completes
End to end. It will be slow and it will fail somewhere. That is the point.
Prove the fixes worked
Your first honest numbers. Time every task and start replacing estimates with measurements.
Dress rehearsal
Production copy, real team, real hours, real script. These numbers become your cutover plan. Reconcile GL balances, AR and AP aging, inventory valuation and open sales orders here. Discrepancies found now cost hours, while the same ones after go-live cost weeks.
Close the gaps, if needed
Only for complex landscapes. Proves you closed everything run 03 exposed.
If 52 Hours Does Not Fit Your Business
Two SAP accelerators are worth knowing. Downtime-optimized DMO migrates a portion of application tables while the system is still up. Downtime-optimized Conversion goes further, shifting FI/CO/ML and MM-IM conversion into uptime processing; SAP describes the mechanics and prerequisites on its downtime-optimized conversion page, and the wider Software Update Manager pages cover which SUM version applies to your source release. Both carry conditions: DoC needs a completed standard conversion cycle first and enforces customising freezes between cycles. Miss a freeze and that cycle restarts from scratch. The downtime saving is real; so is the added complexity. Choosing between them is a programme-level call our digital transformation consulting practice makes before the build phase locks.
Rollback Planning: Why "We'll Roll Back" Is Not A Plan
Write Down Four Things Before Cutover Weekend
Once SUM crosses into the downtime phase and the finance conversion starts, rollback means restoring the pre-conversion backup and replaying whatever the business did in the meantime, which during a freeze should be nothing at all. That is precisely why the freeze gets enforced rather than requested.
- The point of no return. Usually the final verified backup at roughly T+2h. After that, rollback costs the entire window and you go again next month.
- The restore procedure, written, tested, with a measured duration. Not a diagram.
- The trigger conditions, named and specific. Finance conversion exceeds X hours. Validation fails on Y. Decided in daylight, by people who are not exhausted.
- Who calls it. One person. Not a committee at 4am.
What Actually Drives Cost, And Where Projects Overrun
Licence and infrastructure numbers are the easy part of an SAP ECC to S/4HANA migration business case. They are also the smallest part. The variance that wrecks budgets sits in four places, and none of them appear on a vendor quote.
Where The Money Actually Goes
Data Quality You Have Not Measured Yet
Nobody budgets for cleansing they have not scoped. Run a profiling exercise before you commit a number. Look for duplicate business partners, materials with no valid unit of measure, and open items nobody can explain. A landscape with 400,000 clean customer records converts on schedule. The same volume carrying 15% duplicates adds months, because every duplicate becomes a decision somebody in finance has to make.
Custom Code You Have Not Counted
Teams estimate remediation from a rough object count, then discover half those objects call each other. Effort scales with entanglement, not with line count. The Custom Code Migration app gives you the real dependency picture in a week, so run it before the budget goes to the board rather than after.
Interfaces Nobody Owns
Every integration needs a named owner who can answer three questions: what does it move, what breaks if it stops, and who tests it. Interfaces without an owner become cutover-weekend discoveries. Budget review time for each one, and expect to find integrations that predate everyone currently employed.
Testing Scope That Grows After Sign-Off
Test cycles expand when business process owners see the system for the first time in UAT and recognise gaps that fit-to-standard workshops missed. The fix is earlier exposure. Get key users into a sandbox during Explore, not during Realize.
The One Planning Rule That Holds Across Every Project
Build the schedule from measured durations, add a full quarter of contingency, and treat any estimate produced before the first dry run as provisional. Teams that do this land on the weekend they picked. Teams that do not spend that contingency anyway, just without having budgeted for it.
The First 30 Days: What Healthy Hypercare Looks Like
Staff a command centre with functional consultants, Basis and business super-users in the same room or the same call, for at least two weeks. Route every issue through a single queue with a severity model everyone agreed to before go-live.
Three Things To Watch In Week One
Performance
Custom reports that ran fine in testing meet different volumes in production. Expect optimisation work in week one.
Interfaces
Systems reconnect but behave subtly differently. Reconcile daily against known totals instead of waiting for someone to notice.
Adoption
Fiori changes how people work. A dip in week one is normal. Still there in week four is a training problem. See our case studies.
Work Backwards From Go-Live, Then Add A Quarter
The technical path of an SAP ECC to S/4HANA migration is well mapped. SAP has tooled it, documented it, and thousands of companies have already walked it. The risk does not sit in the unknown. It sits in preparation.
The difference between a quiet go-live weekend and a 3am call with the CFO comes down to what got done in the first six months.
Two Kinds Of Go-Live Weekend
Teams that go live quietly
- Cleared CVI in month one, not month six
- Cleansed data inside ECC, before migration started
- Scoped custom code with ATC, not with a guess
- Rehearsed cutover until it was boring
- Built the schedule from measured durations
Teams that discover it at 3am
- Left master data to "sort out later"
- Found forty undocumented interfaces at cutover
- Estimated remediation from an object count
- Ran one dry run and called it enough
- Committed a date before the first measurement
If the arithmetic puts your start date in the past, that is useful information, and extended maintenance may buy the runway to do this properly rather than fast.
Primary Sources And Further Reading
- Maintenance timelines for SAP ERP 6.0SAP Community · the enhancement-package split behind the 2025 / 2027 / 2030 dates
- SAP Readiness CheckSAP Community · the self-service analysis that opens the Discover phase
- Conversion Guide for SAP S/4HANA (PDF)SAP Help Portal · simplification items, SI-Check and the full conversion sequence
- Software Update ManagerSAP Support · which SUM version applies to your source release, plus DMO and ZDO
- Downtime-optimized conversion approachSAP Support · prerequisites and customising-freeze rules for DoC
Planning Your S/4HANA Transition?
Readiness assessments, data migration design, custom code remediation and cutover planning for enterprise SAP landscapes.
SAP ECC To S/4HANA Migration FAQs
A brownfield system conversion typically runs 9–14 months for a mid-size single-instance landscape. Greenfield runs 18–30 months. Selective data transitions land between the two at 12–20 months. Landscape complexity and data quality drive the variance far more than company size does.
You fall into customer-specific maintenance: same cost, no new security patches, no new legal or regulatory updates, minimal bug fixes. Extended maintenance through 2030 is available for EHP 6–8 at roughly two percentage points extra, and a 2031–2033 transition option exists for selected RISE with SAP customers.
Neither is universally better. Brownfield preserves configuration and history and moves faster. Greenfield gives you a clean core at the cost of time and change management. Choose based on how much technical debt your ECC carries and how much organisational change your business can absorb.
A standard brownfield conversion typically needs 40–60 hours of business downtime, or one long weekend. Downtime-optimized DMO and downtime-optimized Conversion cut this substantially by moving work into uptime. Selective data transition can bring large landscapes down to roughly 12 hours.
Customer/Vendor Integration converts separate ECC customer and vendor master records into unified Business Partner records. It is a mandatory prerequisite for system conversion. Start it early, because the data quality issues it surfaces take months rather than weeks to resolve.
ACDOCA, the Universal Journal, consolidates BSEG, BKPF, COEP, FAGLFLEXA and related tables into a single line-item table covering GL, controlling, asset accounting and material ledger. Any custom report reading the old tables needs remediation.
Three at minimum, four for complex landscapes. The first proves the procedure completes, the second validates fixes and produces duration data, and the third is a full dress rehearsal on a production copy with the real team. Cutover timings come from the dress rehearsal, never from estimates.
