S/4HANA migration cost: what drives it by path

S/4HANA migration cost falls in the same bands as any SAP programme. Plan for $500K to $2M in a mid-market company, $2M to $10M or more in a large one and $10M to $50M or more in a global group. Where you land inside the band depends less on the path than on custom code, data, mock conversions, dual running and your SAP contract.

Short answer: no migration path is cheaper by default. Brownfield vs greenfield cost depends on how much custom code you carry, how clean your data is and how much process you want to change. In my experience custom code is the phase that overruns most often, and the hidden cost companies forget most often.

This article is about the migration bill specifically. The paths, steps and ECC deadlines are in my ECC to S/4HANA migration guide.

For what SAP costs in general and where the money goes, read how much SAP implementation costs. For why budgets overrun once the work starts, read why SAP projects go over budget.

A migration is a full SAP programme, so it uses the same working ranges I use for any SAP programme. They cover partner services, subscription or licences, data, testing, training and hypercare.

This is where each band sits, and what pushes a migration up its band:

Company size	Total programme cost (USD)	What moves a migration up the range
Small (under 200 staff)	$80K to $500K	Legacy data volume, add-ons that have no S/4HANA version
Mid-market (200 to 1,000)	$500K to $2M	Custom code volume, integrations, data quality
Large (1,000 to 10,000)	$2M to $10M+	Custom code, number of mock conversions, regression test scope
Global group (10,000+)	$10M to $50M+	Many entities and countries, dual running across rollout waves

Two shares hold across every band. Partner services take 35 to 50 percent of the total, and contingency of 10 to 20 percent sits on top, held by you rather than inside the partner's price.

Public benchmarks sit in the same place. LeverX, an SAP partner, puts a large-enterprise greenfield implementation in the US at $4M to $10M+ (LeverX US cost guide, 2026). For a first number on your own scope, try the SAP implementation cost calculator.

People want a percentage: brownfield costs X percent less than greenfield. My honest answer is that it depends, and I do not give a percentage. The path changes where the money goes more than how much of it there is.

A system conversion (brownfield) keeps your configuration, custom code and history. A new implementation (greenfield) starts clean and loads only the data you need, and a selective data transition does a bit of both with specialist tools.

This is where each path spends the money:

Path	Where the money goes	What makes it expensive	What keeps it down
Brownfield (system conversion)	Custom code remediation, conversion runs with the Software Update Manager, regression testing of everything you kept	A large custom code base nobody uses, add-ons to replace, a short downtime window on a big database	Retiring unused code before the conversion, processes that already work
Greenfield (new implementation)	Process design, configuration, extensions, data loads, training and change	Rebuilding old custom reports and logic in the new system, redesigning areas that worked	Adopting SAP standard, loading open items and only the history you need
Selective data transition	Specialist tools and partner, data scoping, plus some redesign and some conversion	Complex company code and history selection, mergers and carve-outs	A tight decision on which areas get redesigned

So what does it depend on? These four questions decide it:

1. How much custom code you carry, and how much of it is used. In a conversion every object you keep has to be checked, fixed where needed and tested.
2. How clean your data is and how much history you need. Bad data costs money on every path, in a different place on each.
3. How much process you want to change. My rule: greenfield when you come from other systems or new processes must be defined, brownfield when processes are defined and working, selective when some areas need redesign. Paying to redesign processes that already work is the expensive choice.
4. How much downtime the business can take. Large systems with short windows need downtime-optimised techniques and the specialists to run them.

Cost also follows time. In my experience brownfield takes 12 to 18 months, greenfield 18 to 24 months and selective data transition 12 to 18 months. My S/4HANA migration timeline and project plan breaks those down phase by phase.

Custom code is the phase I see overrun most often on a migration. It is also the cost companies forget most often when they set the budget.

It hides because it looks like a technical task. In a brownfield conversion your Z-programs, enhancements and modifications move across, and each one that touches a changed data model has to be adapted and retested.

The SAP Readiness Check is the right place to start, but it is a planning tool. In my experience the custom objects are what it misses that hurts later.

SAP's own Conversion Guide for SAP S/4HANA Cloud Private Edition 2025 sends you to the ABAP Test Cockpit for the custom code checks. It also recommends removing custom code that is no longer used before you convert.

That recommendation is where the savings are. On one programme, analysis with smartShift took us from 18,000 custom objects to 3,200, and every object retired was one nobody had to fix, test or carry into future upgrades.

Before anyone prices a migration, I would want answers to these:

1. How many custom objects exist? Count them from your own system, not from the partner's estimate.
2. How many are actually used? Usage data from production, over a full business cycle, including year-end.
3. Which ones will be retired, and who decides? A design authority of business and IT, not the developers alone.
4. What replaces the ones you keep? Standard functions, released APIs or side-by-side extensions, in line with a clean core.

Keep customisations to a minimum and govern the rest. The common mistake I see is trying to make SAP work like Oracle, which turns every difference into code. My SAP clean core guide explains how to classify what remains.

In my experience data migration takes 30 to 40 percent of the effort. A good share of that effort sits with your own business users, cleansing and validating, so it rarely shows up in a partner quote.

On a brownfield conversion I plan three mock conversions before cutover. Each one costs real money: a system copy, the technical team running the conversion, functional checks and business reconciliation of the results.

Check what your contract already covers. SAP's conversion guide for Private Edition says the standard contract scope includes two dry runs, one for non-production systems and one for production. More can be added as a billable service.

If you plan three, agree up front who pays for the third.

Downtime is the other cost in this phase. The cutover downtime I have seen ranges from a weekend to a week, and the business pays for every day it cannot ship, invoice or close.

You can shorten it. The Software Update Manager offers a downtime-optimised conversion, but SAP's guide says the Private Edition version needs an SAP expert who has completed the ADM329 training course. That is a specialist line in the budget, not a free switch.

Testing closes the loop. A conversion keeps everything, so regression testing has to cover everything you kept, and that scope grows with every custom object you did not retire.

Two costs sit outside the project plan, and both land on the CFO's desk.

The first is dual running. For SAP ERP 6.0 on enhancement packages 6 to 8, mainstream maintenance ends on 31 December 2027. Optional extended maintenance to the end of 2030 costs two extra percentage points (SAP News).

A greenfield programme started today runs into 2028, so ECC keeps running, and costing, while you build. Budget for at least some extended maintenance, the ECC support team and any interfaces that have to feed both systems during a phased rollout.

The second is the contract conversion. Moving to RISE with SAP means S/4HANA Cloud Private Edition, which SAP now markets as SAP Cloud ERP Private. Your licence and maintenance position changes into a subscription, and the terms are negotiated, not published.

The biggest traps I see in a RISE contract are renewal terms, full user equivalent (FUE) sizing and AI credits. What I always negotiate in is the list of modules included, and phase-wise pricing, so you pay as phases go live rather than from day one.

Ask SAP in writing what happens to your existing licences and maintenance payments. My guide to RISE with SAP contract and pricing covers what is in, what is out and what to push on.

Across the 21 SAP programmes I have led or rescued, the biggest mistake I see is not planning properly at the start. Budgets get hit in the Explore phase, as the WRICEF list (reports, interfaces, conversions, enhancements, forms, workflows) grows, and letting vendors control the scope is a root cause.

This is the order I would follow:

1. Run the SAP Readiness Check and the custom code checks before you ask anyone for a price.
2. Decide what custom code retires through a design authority of business and IT.
3. Profile the data and size the data effort at 30 to 40 percent of the programme.
4. Count the mock conversions and dry runs, and agree who pays for each.
5. Price dual running, including extended maintenance if go-live lands after 2027.
6. Write the scope yourself, so the partner prices your scope and not theirs.
7. Add 10 to 20 percent contingency, held on your side.

Then go to partners. Ask for references and for their high-level design of your migration, and walk away from generic answers that could apply to any company. My guide to choosing an S/4HANA migration partner covers the rest of that conversation.

The concrete next step: pull the custom object count and the usage data from your own production system this month. It is the one number that moves a migration budget most, and you can have it before any partner is in the room.

If you want an independent view on a migration budget or a partner proposal, I help organisations with this. You can contact me here.

How much does an S/4HANA migration cost?

The working ranges I use are $80,000 to $500,000 for a small company and $500,000 to $2 million mid-market. A large enterprise should plan for $2 million to $10 million or more, and a global group $10 million to $50 million or more. Partner services take 35 to 50 percent of the total, and custom code, data and the number of mock conversions decide where you land in the range.

Is brownfield cheaper than greenfield for S/4HANA?

Not by default. It depends on how much custom code you carry, how clean your data is, how much process you want to redesign and how much downtime you can take. A brownfield conversion with a large unused custom code base can cost more than a greenfield implementation that adopts SAP standard.

What is the biggest hidden cost in an S/4HANA migration?

Custom code. In my experience it is the cost companies forget most often and the phase that overruns most often. Count your custom objects and check which are used before anyone prices the migration.

How many mock conversions does an S/4HANA conversion need?

On a brownfield conversion I plan three mock conversions before cutover. SAP's conversion guide for Private Edition includes two dry runs in the standard contract scope, one for non-production and one for production, with more available as a billable service. Agree who pays for any extra run before you sign.

How much contingency should I add to an S/4HANA migration budget?

Hold 10 to 20 percent on top of the budget, on your side rather than inside the partner's price. Release it against named risks, such as custom code or data issues found in testing, not to cover scope that was never priced.

Does RISE with SAP make an S/4HANA migration cheaper?

It changes the shape of the cost more than the size. Licences, hosting and technical operations move into a subscription, but custom code, data, testing and change still sit in your programme budget. Watch renewal terms, FUE sizing and AI credits, and negotiate the included modules and phase-wise pricing.