An S/4HANA migration for a mid-market company still on ECC runs somewhere between $5 million and $10 million once consulting, licenses, infrastructure, and testing are counted, and not one of the eight pages ranking for the term prints a number with a currency sign on it. That is not an accident. Position two on page one is SAP itself. Positions three through eight are three tool vendors, an SAP-owned software company, a consultant, and an implementation partner. Every one of them sells a piece of the project they are explaining.
The number one result is a Reddit thread. Practitioners asking other practitioners what actually happens, because they have stopped trusting the guides. That tells you what this search is really asking for.
So this guide is written for the other side of the table: the person who signs the checks. What the migration costs, how long it honestly takes, why partners steer you toward the biggest version of the project, why SAP steers you toward RISE, and where your bargaining power sits. The vocabulary gets defined as it appears. The numbers carry their sources. Where a claim comes from a vendor, it says so.
The 2027 Deadline, Priced in Percentages, Not Sirens
Start with the clock, because every sales conversation you will have starts there too. SAP ends mainstream maintenance for ECC (ERP Central Component, the classic SAP Business Suite most installed systems still run) on December 31, 2027. That date is real and SAP has repeated that it will not move.
What the partner decks rarely mention is that the fallback is priced, and the price is knowable. SAP’s official maintenance strategy offers extended maintenance from 2028 through the end of 2030 at a premium of two percentage points on your maintenance base. Standard and Enterprise Support run at 17% to 22% of that base, so two points on top of 22% works out to roughly a 9% cost increase. Annoying. Not a cliff.
Maintenance base, in plain English: the net value of the SAP licenses you have bought over the years. If your base is $4.5 million, you are paying SAP about $1 million a year to keep ECC supported, and extended maintenance would add roughly $90,000 a year to that. Compare that number to a rushed $6 million conversion and the siren quiets down.
Three more facts belong in your file before any negotiation:
- After 2030 there is one SAP-sanctioned road left: a package called SAP ERP, private edition, transition option, announced in early 2025. It extends ECC support past 2030, but only for select large customers, and only inside a RISE contract. The escape hatch is also a funnel.
- Third-party support exists and works. Providers like Rimini Street and Spinnaker Support price at roughly 10% of net license value against SAP’s 22%, which is why enterprises that switch typically report 50-60% maintenance savings. Cubic Corporation publicly disclosed a 50% cut after moving to Rimini Street. You lose new SAP features and official patches; for a stable ECC estate mid-decision, that trade can buy years.
- Waiting is not free either. Documented renewal cases show SAP maintenance escalating around 8% a year, and buyer-side negotiation practices report that SAP’s 22% only moves for customers with a documented alternative on the table.
The adoption numbers explain why SAP keeps the pressure on. The last independent research on the question, published in May 2022, found only 29% of SAP customers had actually transitioned to S/4HANA, with 16% saying they had no migration plans at all; SAP counted around 16,000 migrated customers at the time against 33,000-plus on HANA. The installed base has moved since, but nobody serious claims the majority is across. A deadline this size with this much of the base still on the old side is not a schedule. It is a market.
Here is the sentence no partner will print: the 2027 deadline is SAP’s pricing power, and it is also yours. A buyer who can credibly say “we will run ECC on third-party support until 2029 and convert on our own schedule” negotiates a different deal than one who walks in scared. We laid out the month-by-month version in our 2027 ECC deadline countdown plan.
What S/4HANA Actually Changes (and Why There’s No Simple Upgrade)
S/4HANA is not a new version of ECC. It is a different product with a different data model, which is the single fact that explains most of the cost and most of the risk. Some history helps: ECC 6.0 shipped in 2006, S/4HANA launched in 2015, and the decade between them is why the two systems share vocabulary but not internals. SAP is also winding down support for the other databases under its classic ERP (Oracle, IBM DB2, Microsoft SQL Server, MaxDB), which closes the side doors.
The database is non-negotiable: S/4HANA runs only on SAP HANA, SAP’s in-memory database, which itself runs only on Linux. The finance core changes shape: the classic accounting tables (BKPF and BSEG, familiar to anyone in FI, SAP’s Financial Accounting module) collapse into one Universal Journal table called ACDOCA, and the old aggregates and index tables disappear. The user interface moves from the gray SAP GUI to Fiori, SAP’s browser-based, role-based front end. Analytics run inside the system instead of in a separate warehouse, which is where the practical wins live: faster financial closes, automated invoice matching, predictive material planning. Real, but they arrive after go-live, not before.
Two buyer-relevant consequences follow. First, the simplified data model compresses your database footprint, in SAP’s telling by up to 70%. Useful, with a trap attached: sizing teams see the compression headline and buy too little hardware. Size with SAP’s Quick Sizer against real production usage, not the brochure number.
Second, every custom program your team wrote against the old tables is now suspect. A Z-program that reads a table that no longer exists does not degrade gracefully. It dumps. That is why custom code remediation is a named phase of every serious migration plan, and why “we’ll just upgrade” is not one of the options.
The Three Migration Paths, Plus the One Nobody Puts in the Deck
Every page on this topic lists the three canonical routes. SAP’s own naming is REUSE (system conversion), NEW (new implementation), and REENGINEER (selective data transition). The market calls them brownfield, greenfield, and bluefield. What the ranking pages will not put next to the names is money and time, so here is the comparison with both columns filled in. The cost and timeline figures come from a 2025 peer-reviewed engineering analysis of migrations at companies with $1 billion to $5 billion in revenue; treat them as ranges that scale with your size, not quotes.
| Path | What It Is | Typical Cost ($1-5B revenue) | Typical Timeline | History and Custom Code | Who Should Pick It |
|---|---|---|---|---|---|
| Brownfield (system conversion, SAP “REUSE”) | Convert your existing ECC system in place via SUM-DMO, SAP’s one-step tool that migrates the application and database together | $5-6M | 15-19 months; small, clean, single-instance estates compress to 4-9 months | Keeps full history and configuration; carries 85-90% of customizations forward | Companies whose processes basically work and whose data is in decent shape |
| Greenfield (new implementation, SAP “NEW”) | Build S/4HANA fresh, move only clean master data and open items, re-design processes to standard | $7-9M | 18-24 months | History stays behind; typically sheds around 85% of custom code volume | Companies drowning in customization debt, or moving to public cloud (which only this path reaches) |
| Selective data transition (bluefield, SAP “REENGINEER”) | Carve out selected company codes, modules, or time slices with SAP’s Landscape Transformation tooling; convert those | $8-10M | 20-28 months | Selective: keeps roughly half of customizations, moves chosen data slices | Multi-instance consolidations, divestitures, region-by-region go-lives |
| Carve-out plus greenfield (the fourth pattern) | Stand up a new S/4HANA box for one unit while ECC keeps running, migrate the rest later, decommission | Adds a dual-ERP running cost and duplicated integrations for the interim | Longest overall; staged | Mixed by design | Acquisitions, or firms that need a live proving ground before committing the core |
One constraint cuts across the table: S/4HANA Cloud Public Edition, the true multi-tenant SaaS flavor, can only be reached by new implementation. Conversions and selective transitions land on private cloud or on-premise targets. If a partner is pitching you public cloud and brownfield in the same deck, one of those two words is wrong.
Why Partners Lean Greenfield
Notice which path costs the most, runs the longest, and re-opens every process decision your company has ever made. Now notice which one partners recommend most enthusiastically. A greenfield project bills more hours across more workstreams for more quarters, and “clean core” gives the pitch a virtuous name.
Not every greenfield pitch is padding. If your ECC estate carries twenty years of undocumented Z-programs and your processes exist to serve the customizations rather than the business, a fresh build genuinely can be the cheaper decade even when it is the dearer project. But the market’s own behavior is instructive: in the LeanIX/PwC survey data, 44% of companies choose brownfield, 42% a mixed route, and only 14% go pure greenfield. When the most-recommended path is the least-chosen one, the recommendations are telling you something about the recommenders. Our brownfield vs greenfield breakdown goes deeper on making this call.
What an S/4HANA Migration Costs (the Numbers Page One Won’t Print)
Across roughly 11,000 words of page-one content on S/4HANA migration, the number of dollar figures is zero. The same pages describe cost as a top concern. Both facts are doing their jobs.
Here is what the published research actually says. IDC-derived data published through AWS’s partner network puts the average third-party consulting cost of moving SAP workloads to cloud infrastructure at $1.5 million, with business disruption adding another $1.5 million or so. A full move from ECC to S/4HANA averages in the $4.9 million band. The per-approach study cited above brackets mid-market-to-enterprise projects at $5 million to $10 million depending on path. These are averages across messy reality; your number depends on scope, landscape count, and data quality more than on anything a rate card says.
The structure of the budget is more useful than any single figure:
| Line Item | How to Size It | What Moves It |
|---|---|---|
| Software / subscription | 2026 published benchmarks: public cloud around $130 per FUE per month (FUE = full user equivalent, SAP’s cloud user metric); private cloud $150-200; RISE bundles near $160; on-premise perpetual licenses from about $3,200 per user plus 22% annual maintenance | User counts and tiers, negotiation timing, conversion credit for existing licenses |
| Implementation services (the SI) | Commonly 1.5X to 4X your license cost | Path chosen, customization depth, how much lands offshore |
| Consultant rates inside that fee | Around $150/hour mid-level; $200-300/hour senior or specialized | Module scarcity, onshore ratio, and the 2027 demand spike |
| Data migration and testing | Priced inside the SI fee, chronically underpriced there | Data quality, object count, number of mock conversion cycles |
| Infrastructure | Hyperscaler or on-prem hardware; on-prem implies a refresh cycle every 4-5 years | Deployment choice, sizing discipline after compression |
| Internal backfill | Your best people, pulled from their day jobs for a year or more | Project length; this is the line most budgets omit entirely |
| Contingency | 15-25% of the total | Everything above that turned out optimistic |
| Run cost after go-live | 20-25% of the original project cost per year for enhancement and support | How much optimization you actually do; studies show 15-20% reinvested in the first two years returns about 3:1 |
SAPinsider’s benchmark research found 73% of SAP customers had at least started a formal S/4HANA business case, and the top difficulty, named by 42%, was justifying the cost. That struggle is partly manufactured: it is hard to justify a number nobody will publish. The ranges above, plus our full SAP implementation cost breakdown, are the starting grid.
Bottom line: price the project as license cost times the services multiplier, plus backfill, plus 15-25% contingency, plus a permanent 20-25% annual run rate. Any proposal missing one of those layers is not a lower price. It is a later invoice.
Ranges tell you what the market charges. They do not tell you which vendor fits a 1,200-user ECC estate with heavy FI customization, and that matching problem is what our engine exists for: describe your own project and watch it rank vendors against it, free, no signup.
How Long an S/4HANA Migration Really Takes
Page one contradicts itself on this and never resolves it. One vendor says small-to-mid brownfield migrations run 4-9 months. A partner further down says a midsize ECC estate takes 12-24 months plus about six months of planning and vendor selection, with global landscapes at 30 months or more. Both are quoting real projects. Neither tells you which one is yours.
The resolution is size and cleanliness. A few companies really do land the short end: single instance, modest data, disciplined customization, brownfield path. Most mid-market estates live in the middle of the range. And the ones with multiple instances, industry solutions, or heavy integration webs sit at the long end no matter what the proposal promises. Independent IDC-derived figures back the middle: across SAP cloud migrations, planning alone averages 8.8 months and execution 17.4.
| Phase | What Happens | Duration Signals From Published Data |
|---|---|---|
| Readiness and assessment | SAP Readiness Check, fit-gap analysis, custom-code scan, data profiling | SAP’s own guidance: start readiness work about two years before target go-live |
| Planning and vendor selection | Path decision, deployment decision, SI shortlist, contract negotiation | About 6 months for a midsize estate; planning averages 8.8 months across cloud migrations |
| Build / convert | Conversion or new build, code remediation, integration rework | Brownfield 15-19 months end-to-end at $1-5B scale, compressing to 4-9 for small clean estates; greenfield 18-24; selective transition 20-28 |
| Test cycles and mock cutovers | Regression cycles, mock conversions, rehearsal weekends | Near-zero-downtime techniques demand multiple full mock runs |
| Cutover | The rehearsed weekend itself | Archiving beforehand can cut the downtime window by hours |
| Hypercare | Defect triage, role fixes, interface tuning | 4-6 weeks post-go-live |
Three profiles should assume the long end of every range from day one: estates with heavy integration hubs (SAP PI/PO or third-party middleware), heavily modified industry solutions like IS-Oil or IS-Retail, and companies with M&A on the calendar mid-project. At the other extreme, S/4HANA Cloud Public Edition with strict fit-to-standard discipline has published time-to-value as low as six months, which is real, and available only to companies willing to adopt SAP’s processes wholesale.
Now do the arithmetic against the calendar. A midsize company starting planning today will not be live before December 2027; the last comfortable start slipped past in early 2026. That is not a reason to panic. It is a reason to price extended maintenance (Section 1) as a deliberate bridge rather than pretend the timeline away.
One more input the schedules ignore: people. Deloitte’s own guidance to CFOs says the quiet part, warning that S/4HANA work will tie up your best staff for years and that as 2027 approaches “the best people will be in high demand.” Every company that waited is bidding for the same consultants you are. Scarcity prices itself into rates first and slippage second.
I have read enough post-mortems to add one pattern: boards get promised the short end of the range. One practitioner account describes a nine-month promise made to a board with no buffer; data migration overran, the go-live missed by three months, and the project team spent the next year rebuilding executive trust instead of optimizing the system. The promise was the failure.
The Work Itself, and Where It Goes Wrong
The phases above hide the actual labor. Four workstreams decide whether your migration is boring, and boring is the goal.
Readiness and Custom Code
SAP Readiness Check 2.0 is free and reads your production system: simplification items, add-on compatibility, custom-code usage, HANA sizing. Run it before you talk to any partner, because it converts their discovery phase from a billable mystery into a checklist. Then run custom code through the ABAP Test Cockpit against SAP’s Simplification Database and sort it three ways: retire, retain, redesign. Most projects retire 30-40% of custom objects once someone finally asks whether anyone still uses them. Use SUM (Software Update Manager) to clear the patch backlog that years of “not now” left behind, and check the older prerequisites early: Unicode compliance still catches long-lived systems out. For what it is worth, the LeanIX/PwC survey found more than half of companies now use enterprise-architecture tooling to map current state before planning the target; a spreadsheet works too, as long as somebody owns the map.
Data: the Part Every Estimate Underprices
The proposal will price the build to the dollar. Data migration gets a paragraph. It should get a chapter, because dormant vendors, obsolete materials, and duplicate customers inflate conversion runtime, downtime windows, and your future cloud bill all at once. Archive and cleanse first; classify what remains as hot (migrate), warm (keep accessible for reporting), or cold (compliance storage).
The tooling is better than its reputation. The SAP S/4HANA Migration Cockpit ships free with the license, auto-generates migration programs with no programming required, plugs into SAP Activate (SAP’s implementation methodology), and moves data two ways: staging tables you fill from templates or ETL tools, or direct transfer over RFC from ABAP sources including SAP ERP, CRM, and EWM. Mappings are maintained once per project and reused across every object, and a migration object modeler handles the custom objects. For the cleansing itself, SAP Data Services and SAP Information Steward do the profiling, deduplication, and validation work; your migration strategy can be selective, full historical, or phased by criticality, but decide it on paper first.
The Cockpit’s hard limit matters to your path decision: it moves master data and open transactions only. No history. Brownfield conversion is the only route that keeps your history inside the system, which is why data-retention requirements quietly decide more path choices than architecture does. We wrote up the failure modes in why SAP data migrations blow up.
Integrations, Security, and Cutover
Legacy interfaces (IDocs, RFCs, flat files) may reference structures that no longer exist after conversion; the modern targets are OData and event APIs on BTP, SAP’s Business Technology Platform. Pilot your order-to-cash and procure-to-pay flows before the first mock conversion, not after. Security deserves its own line: Fiori catalogs and the Universal Journal collapse old authorization objects, and dormant segregation-of-duties conflicts come back to life. Run SoD checks every sprint, because your auditors will run them once, later, expensively.
Then rehearse. Near-zero-downtime cutovers are earned through mock runs and rehearsal weekends, and the stakes are concrete: for a manufacturer or retailer, every hour of production freeze during cutover can cost millions in stalled orders. The change curve is real too: the GUI-to-Fiori shift dents productivity for a while, and phased releases, champion networks, and floor-walkers during hypercare are what dent it back.
After Hypercare
Go-live is the start of the payback period, not the end of the project. Instrument the system (SAP Solution Manager tracks response time, CPU, memory, and database performance; the Security Audit Log watches the rest) and keep a patch cadence, weekly or monthly on-premise. The sensible sequence afterward runs stabilize, then optimize (embedded analytics, predictive MRP, cash application), then extend on BTP, with a clean-core discipline so the next upgrade is boring. SAP’s roadmap items (the Joule AI copilot, the Sustainability Control Tower for CSRD reporting, Industry Cloud services) all assume you got that far. Budget for it: the 20-25% annual run rate from the cost table is where these gains get funded or quietly abandoned.
The Receipts
The failure cases are public record and they rhyme. Hershey went live in 1999 against its Halloween order peak and posted a 19% profit drop. Lidl spent seven years and more than €500 million before abandoning its SAP program; the system priced goods one way, Lidl insisted on another, and nobody with authority reconciled that on paper first. BP’s implementation grew from a $120 million budget to roughly $600 million on scope creep. Revlon’s ERP troubles cost it retail orders and 6.9% of its stock price in a day.
Read the post-mortems and the software is rarely the villain. The contract, the calendar, and the data were signed off by people who had been told what they wanted to hear.
Notice what is absent from that list: HANA performance, Fiori bugs, database corruption. The technology mostly works. The pattern behind the write-offs is planning and governance, and we cataloged it across cases in why ERP implementations fail.
Deployment Choices and the Commercial Fine Print
Where S/4HANA runs is a commercial decision wearing a technical costume. As Christopher M. Carter puts it in Mastering SAP, the strategy call comes down to “the complexity of their existing SAP system architecture, their business goals, and their budget.” Here is the decision matrix with the column the vendor decks leave out.
| Option | Who Runs It | Pricing Model | Custom Code Room | Lock-In and Exit | Fits |
|---|---|---|---|---|---|
| S/4HANA Cloud Public Edition | SAP (multi-tenant SaaS, quarterly releases) | Subscription per FUE (~$130/month benchmark) | Minimal; fit-to-standard or friction | High switching cost but clean contract; you never own anything | Smaller or standard-process firms; greenfield only |
| Cloud Private Edition / RISE | SAP runs OS, database, patches; 99.7% uptime SLA, annual upgrades | Single subscription bundling license, infrastructure, managed services (~$160/FUE benchmark) | Moderate | The deepest SAP relationship you can sign; exit means re-licensing and re-hosting | Firms that want one throat to choke and will pay for it |
| Hyperscaler IaaS (AWS, Azure, GCP) | You keep upgrades and patching; cloud provider keeps the iron | Perpetual or subscription licenses plus infrastructure billing | Full | Infrastructure portable; SAP contract separate, which preserves negotiating positions | Strong basis teams that want cloud economics without the bundle |
| On-premise | You, entirely | Perpetual license (~$3,200+/user) plus 22% maintenance plus hardware refresh every 4-5 years | Full | Maximum control, maximum burden, CapEx-heavy | Data-residency-bound or control-first organizations; SAP’s HEC variant offers on-prem managed by SAP for regulated industries |
RISE, From the Buyer’s Chair
RISE with SAP bundles the S/4HANA license, HANA, BTP, hyperscaler infrastructure, and managed services into one subscription. SAP asserts, on IDC-modeled estimates, that RISE cuts five-year total cost of ownership by 20% against on-premise. Treat that as what it is: the seller’s model of the seller’s product.
The counterweights are on the record. RISE is SAP’s preferred destination because it converts perpetual-license customers into recurring revenue, and SAP’s incentives follow that math, not yours. The offering is being rebranded SAP Cloud ERP, contract terms have been restructured along the way, and tools that used to sit inside the bundle, like SAP Datasphere and various AI capabilities, have been unbundled into paid add-ons. A bundle whose contents shift is a price you cannot benchmark.
The honest concession: for a company with a thin basis team, one contract covering software, infrastructure, and operations is worth real money and real sleep. RISE can be the right answer. It is just never the neutral answer, and the person recommending it is never neutral either.
The Levers Your Account Exec Won’t Volunteer
Audit your licenses before you convert, not after. Buyer-side audits find that large maintenance schedules typically carry 12-18% in overcharges: decommissioned products still billing, ghost users, duplicates left over from acquisitions. One documented European retailer case cut €6.2 million from a €28 million annual maintenance bill this way, before negotiation even started, while its 18-month S/4HANA migration plan ran in parallel. Every euro of base you clean off is a euro SAP cannot convert into your new subscription price.
On contract conversion itself: SAP does credit existing license value toward the new agreement, but the mechanics and the percentages are negotiated, not published, so get them in writing before you signal commitment. And put the SI contract through the same wringer: fixed bid or time-and-materials, who owns an overrun, what a change order costs, and whether the names in the proposal are the names on the project. A fixed bid caps your risk. But only the risk you remembered to put in the scope document.
Frequently Asked Questions
What is SAP S/4HANA migration?
S/4HANA migration is the move from SAP ECC (or another ERP) to SAP S/4HANA, SAP’s current ERP built on the HANA in-memory database. It happens one of three ways: converting the existing system in place (brownfield), building fresh and moving selected data (greenfield), or carving out chosen slices (selective data transition).
Why are many SAP customers struggling with S/4HANA migration?
Four compounding reasons: custom code written against ECC’s data model breaks under S/4HANA’s simplified tables; decades of unclean master data inflate every phase; experienced consultants are scarce as the 2027 deadline concentrates demand; and planning is routinely underscoped, which is where analysts note most migrations actually fail.
What are the 7 steps of cloud migration?
For an SAP move: assess readiness (Readiness Check, fit-gap); choose your path and deployment target; cleanse and classify data; remediate custom code; migrate and verify in mock runs; execute the rehearsed cutover; and stabilize through 4-6 weeks of hypercare. Skipping the first three steps is how the last four go over budget.
What are the challenges of SAP S/4HANA migration?
The recurring ones: data volume and quality driving runtime and downtime; legacy integrations referencing structures that no longer exist; revived segregation-of-duties conflicts under Fiori; user change fatigue moving off the old GUI; compressed cutover windows; and building a cost justification when almost nobody publishes real numbers.
Sources
- SAP maintenance strategy for SAP Business Suite 7: the 2027 mainstream maintenance end date and the two-percentage-point extended maintenance premium through 2030.
- Christopher M. Carter, Mastering SAP: quoted in the deployment section on how migration strategy follows architecture, goals, and budget.
The S/4HANA migration market runs on two things: a deadline and an information gap. The deadline is fixed. The gap is optional. A buyer who arrives with cost ranges, phase math, a cleaned license base, and one documented alternative is negotiating a different project than the one being sold, and every table in this guide exists to put you in that chair. When you are ready to see which firms actually fit your modules, industry, and budget, browse the vendor directory and make them compete on the record.
