How do you build a business case for an ECC to S/4HANA migration?
A business case a CFO signs is arithmetic over numbers from your own system — not a benchmark deck with a confident total.
The short answer
A credible ECC-to-S/4HANA business case is built from four quantities read out of your own system rather than borrowed from a benchmark deck: the annual carry cost of the custom code you can retire, the rebuild effort you avoid by mapping custom objects to standard S/4HANA capability, the cycle-time and working-capital value released by the processes you are actually changing, and the ownership-cost difference between the deployment options you are choosing among. Every one of those numbers has to trace to a specific read — an object count, a lead time computed from document flow, a license or infrastructure line — because finance will discount any figure whose only provenance is a slide. On a reference estate (a live ECC system we analyze end to end; a customer's numbers come from their own system) an evidence-weighted read found that 44% of custom objects were re-implementations of capability S/4HANA now delivers as standard, carrying roughly $1.9M a year in avoidable cost. The other half of the case is the cost of doing nothing: mainstream maintenance for ECC ends at the end of 2027, so the real comparison is never migrate versus stand still — it is migrate on your schedule versus migrate on someone else's. Build the case as arithmetic over auditable inputs and it survives the finance review; build it as a benchmark narrative and it stalls there.
Why most S/4HANA business cases stall in the finance review
The typical migration business case is assembled from industry averages: a percentage uplift in productivity, a benchmark reduction in close time, a vendor's stated TCO improvement. It reads well and it dies quietly, because the CFO's first question is always the same — where did this number come from in our system? When the answer is "an analyst report," the number gets discounted to zero and the program goes back in the queue for another quarter.
The analogy is a house appraisal versus an online estimate. An online estimate is derived from comparable properties and is fine for curiosity; a bank will not lend against it. An appraisal is derived from this house — its actual square footage, its actual condition — and it is what unlocks money. A migration business case is a lending decision. It has to be an appraisal of your estate, not a comparable.
The four value levers, and where each number comes from
A defensible case has fewer moving parts than most people expect. Four levers carry almost all the value, and each one is computable from your live system before the program starts:
- Retired custom-code carry cost — for every custom object that duplicates standard S/4HANA capability, you stop paying to maintain, regression-test, and re-certify it at each upgrade. The input is an object-by-object fit determination with the reason attached, not a percentage.
- Avoided rebuild effort — objects that must move are the cost side of the case. Knowing which ones, and whether each is a re-implementation of standard or a genuine differentiator, is what turns a lump-sum remediation estimate into a scoped work package.
- Process cycle time and working capital — lead times computed from document flow (order to delivery to billing) give you a baseline that a process change is measured against. Days out of order-to-cash is a cash-flow number finance already knows how to value.
- Ownership and run cost — infrastructure, license, and operations differences between deployment options, held over five years rather than at signature.
- Risk avoided — the conversion cycles you do not have to repeat because data and code defects were counted early. Harder to monetize, but it belongs in the case as a documented contingency reduction rather than as optimism.
The cost of doing nothing belongs in the model
SAP has committed to mainstream maintenance for ECC through the end of 2027, with an optional extended-maintenance window to 2030 at additional cost. That changes the shape of the business case: there is no baseline scenario in which nothing happens and nothing is spent. Deferral has a price — extended-maintenance premiums, a compressed timeline later, and a tighter market for the skills you will need when everyone else is also converting.
This is also where honesty pays off. Overstating the urgency to force a decision damages credibility when the board notices that 2030 exists. The stronger framing is that the clock removes the do-nothing option, and the only remaining variable is whether you migrate with a scoped estate or an unscoped one. Sizing the estate now is what buys the calm timeline.
Where the deployment choice fits
Business cases often collapse the deployment decision into the migration decision, and the two should be separated. Hosting is not the differentiator: RISE with SAP, S/4HANA on AWS, and other hyperscaler options all run S/4HANA competently — SAP is itself an AWS partner, and RISE runs on AWS. What differs is ownership. RISE bundles infrastructure, tooling, and operational responsibility into a managed subscription; self-managed S/4HANA on a hyperscaler keeps configuration, data access, and the surrounding AI and analytics estate under your control.
Model both as five-year ownership scenarios with the same estate assumptions, and be explicit that the tradeoff is control versus managed convenience, not good versus bad. A business case that argues fairly about the alternative is the one an executive committee trusts on the rest of its numbers.
Make the model auditable rather than impressive
The practical test of a business case is whether someone can open it and see the arithmetic. That means a documented constants file — loaded rates, license costs, maintenance hours per object class — and visible formulas that combine those constants with counts read from the system. No blended "value realization" figures that cannot be decomposed. If a reviewer can change one assumption and watch the total move, they will engage with the model instead of rejecting it.
This is also where agent-led analysis changes the economics of building the case at all. SAP announced at Sapphire 2026 that its agent-led transformation tooling automates system analysis, code remediation, configuration, and testing to reduce ERP migration effort by more than 35% (attributed to SAP News, Sapphire 2026). The same logic applies upstream: when an agent reads the live system read-only and quantifies fit object by object, the business case stops being a six-week consulting deliverable and becomes a recomputable artifact you refresh as the estate changes.
Two honest caveats, because a business case built on overstated capability is worse than none. The automated functional-testing agent — the piece that would validate a reconfigured process end to end — is in build and design preview, not shipped, so testing effort still belongs in your estimate at conventional rates. And where an agent proposes configuration, it drafts a governed customizing transport in development systems only; your change board decides whether it lands, and it never touches production on its own.
Frequently asked
How long does it take to build a defensible S/4HANA business case?
The analysis is no longer the bottleneck — a read-only scan of the live estate produces the object-level fit determinations and process baselines in days. What takes time is agreeing the financial assumptions with finance: loaded rates, the discount rate, and how much of the process benefit the business will commit to. Budget more calendar time for the assumption review than for the measurement.
Should soft benefits like productivity and agility be in the business case?
Include them, but never in the headline total. Put hard, traceable savings — retired custom-code carry cost, avoided rebuild effort, run-cost differences — in the primary case, and list qualitative benefits separately as strategic rationale. Mixing unverifiable benefits into the ROI is the fastest way to have the whole model discounted.
What if the numbers from our own system do not justify the migration?
Then you have learned something valuable early and cheaply, and the conversation shifts to sequencing and scope rather than approval. Because ECC mainstream maintenance ends in 2027, the decision is rarely whether to move; a weak benefit case usually means the value is concentrated in fewer processes than assumed, which argues for a narrower first wave rather than for standing still.
See your own Clean Core Score.
Run the free S/4 readiness scan in under a minute — no system access required.
Keep reading