Why do ECC to S/4HANA migrations run over budget?

The estimate is made at the point of least knowledge

Every SAP program has an inverted information curve. The moment you know the least about the estate is the moment you are asked to commit to a price for changing it. By the time the team genuinely understands the system — which custom programs still fire, which org units still carry volume, which interfaces are load-bearing — the budget was approved two quarters ago and the governance around changing it is heavier than the governance around delivering it.

This is not a criticism of the integrators. A partner asked to bid without system access has three sources: a set of workshops, whatever documentation survived, and an SAP Readiness Check summary. Workshops capture what people remember doing. Documentation captures what was true on go-live day. Readiness Check is genuinely useful, but it is a compatibility and sizing report — it tells you what will not work in S/4HANA, not what your business logic is or how much of it is worth carrying forward.

So the bid gets built on assumptions with a contingency wrapped around them. When the assumptions turn out to be optimistic, the contingency absorbs the first surprise and the change-request process absorbs the rest.

The four things that get discovered late

Across ECC estates, the same four categories account for most of the variance between the bid and the final number. None of them are exotic. All of them are knowable up front.

• The real custom-code count and its shape. Not the raw object count from a repository scan, but how many objects still execute, what business rule each encodes, and how many of them re-implement capability that S/4HANA now delivers as standard. The difference between a 'we have about 300 customizations' assumption and an evidence-based inventory is usually the largest single line of variance.
• Enterprise-structure change requests. The moment a stakeholder asks to merge two company codes or re-cut a sales organization, the program has moved from a conversion to a transformation. Discovered in month one it is an approach decision; discovered in month four it is a re-plan.
• Data readiness. Business-partner conversion, material-number field length, and customer/vendor harmonization generate remediation work that is proportional to how messy the master data actually is — a fact that is measurable in the source system long before anyone starts a mock conversion.
• Test scope. Regression testing is sized against the number of custom paths that must be proven, so an underestimated customization count produces an underestimated test plan by construction. This is the overrun that hits latest, when there is the least schedule left to absorb it.

Why late scope costs more than early scope

The same work is not the same price at different points in a program. Scope identified before signature is priced competitively against alternatives, sequenced into the plan, and staffed from the normal resourcing pool. Scope identified in month four is priced against a single incumbent, inserted into a plan that has already committed dependencies, and staffed by whoever is available — often at premium rates, sometimes by pulling people off the critical path.

There is a second, quieter cost. Late scope consumes the credibility of the program with its steering committee. A program that has requested three budget increases spends progressively more of its leadership attention defending the plan rather than executing it, and the pressure that creates tends to push teams toward the fastest technical answer rather than the right design answer — which is how modifications get carried forward that a calmer program would have retired.

What an evidence-based baseline looks like

The alternative is not a bigger estimating exercise; it is a different input. Instead of asking people what the system does, read the system. Every claim in the baseline should trace to an object, a configuration table, or a document count that someone can go and check.

On a reference estate — a live ECC system used to validate this approach, not a specific customer result — that read produced a concrete picture in days rather than weeks: 356 custom objects inventoried and classified, roughly 44% of them assessed as retirable because they duplicate standard S/4HANA capability, a fit score of 92/100 against standard, order-to-cash cycle times derived from 8,360 real sales documents, and a business case built by arithmetic on those figures rather than on a benchmark ratio. A customer's numbers come from their own system, and they will look different — the point is that they are numbers from a system rather than estimates from a meeting.

That baseline changes the shape of the negotiation. When the retirement percentage is evidenced rather than assumed, the conversion scope shrinks to something defensible, the test plan is sized against paths that provably exist, and the structural questions surface while the approach decision is still open.

What to ask for before you sign

Three requests, all answerable from read-only access to the existing ECC system, and all cheap relative to the variance they remove:

• An evidenced custom-code inventory with a retire / re-implement / carry-forward disposition per object, and the reasoning attached to each.
• The as-built enterprise structure read from configuration, tested against document volumes so dormant org units are visible before anyone plans to migrate them.
• A data-readiness assessment against the specific S/4HANA conversion rules, with defect counts by object type — because remediation effort scales with those counts, not with a percentage.