Back to Blog
SAP Migration

Why Most S/4HANA Migrations Run Over Budget

Research finds most S/4HANA migrations exceed budget: only 8% finish on schedule and six in ten overrun. The recurring causes are planning failures, not technical ones, and data planning is the most fixable.

Prakash Palani

The short answer. Independent research consistently finds that most S/4HANA migrations exceed budget. A 2025 Horvath study of 200 SAP user companies found only 8% finished on schedule, projects ran 30% longer on average, and more than six in ten overran budget. The causes named most often are not technical: scope expansion, custom code complexity assessed too late, inadequate data migration planning, and weak governance. Each of those is a planning failure, which means each is preventable.

It is unusual for an entire category of project to overrun this consistently. That consistency is actually useful, because it means the causes are known rather than mysterious. Here is what the research says and what a programme can do about it.

What the research actually found

The most cited dataset is a 2025 Horvath study of 200 SAP user companies. It reported that only 8% of organisations completing an S/4HANA migration did so on schedule, that the average project ran 30% longer than planned, and that in more than six out of ten cases the budget was exceeded. A separate 2026 survey by Precisely and ASUG found roughly 30% of migration projects already delayed or over budget among organisations actively in motion. SAPinsider research in 2026 added a related finding: 63% of organisations with no S/4HANA plan cite rising cloud and deployment costs as their main barrier, and half cannot construct a value proposition at all.

The causes that keep recurring

  • Scope expansion. Requirements added during execution without cost-impact analysis, so the budget set at the start describes a smaller project than the one being delivered.
  • Custom code assessed too late. Complexity is discovered after budgets are fixed rather than before, which is a sizing failure rather than a technical one.
  • Inadequate data migration planning. The condition of master data is unknown when the plan is written, so the cleansing effort is guessed.
  • Weak governance. Decisions take months instead of weeks, and mid-programme blueprint revisions follow.
  • Process change underestimated. Business process redesign is treated as a side activity rather than a workstream.

None of these is a technology problem. All of them are decisions made before anyone looked hard enough at the detail.

The governance gap is real

One finding deserves separate attention. Research reported in 2025 found that at smaller firms the CEO personally leads the S/4HANA project in only 14% of cases, with CFOs or COOs involved in just 7%, and that only 17% of companies back migration preparation with change-management measures such as training or process workshops. For what is often the largest IT investment of the decade, that is thin executive ownership. Programmes without senior sponsorship tend to resolve scope disputes slowly, and slow scope decisions are expensive.

Why data planning is the controllable one

Of the causes above, data planning is the one a programme can most directly fix, and fix early. Custom code complexity requires an assessment. Process redesign requires business time. Governance requires executive attention. But the condition of your data can be established quickly, before the budget is committed, by profiling it. That single step converts the largest open variable in the plan into a measured quantity. Reporting consistently identifies historical and master data as a hidden cost driver, and notes that organisations which deal with data volume before migrating are the ones that finish on budget.

What prevention looks like

  1. Assess before you commit. Run a landscape assessment and profile the data before fixing scope, timeline or budget.
  2. Name the data workstream. Itemise profiling, cleansing, conversion, transformation and reconciliation rather than absorbing them into contingency.
  3. Decide scope deliberately. Agree what migrates, what is archived and what is dropped, and hold that line.
  4. Secure real sponsorship. Scope disputes resolve faster when someone senior owns the decision.
  5. Apply a risk premium. Given documented overrun rates, a contingency on the data and code workstreams is a realistic allowance rather than pessimism.

Late discovery is the common mechanism

Look across the causes and one mechanism connects them: problems are discovered after commitments are made rather than before. Custom code complexity is assessed after the budget is fixed. Data condition is established after the timeline is published. Process change surfaces during build. In each case the work itself was always going to be necessary; what made it an overrun was that nobody measured it while the numbers were still adjustable. This reframing is useful because it points at a cheap intervention: move discovery earlier. Assessment and profiling cost a fraction of what the resulting surprises cost, and they happen at a point where the plan can still absorb what they find.

A realistic plan beats an optimistic one

There is organisational pressure to present an attractive number, particularly when a deadline is driving the decision. The problem is that an optimistic plan does not make the work smaller; it just relocates the overrun to a later and more painful moment. Given documented overrun rates across the industry, a plan that includes a properly sized data workstream and a sensible contingency is not pessimistic, it is calibrated. It is also easier to defend afterwards than a plan that looked good at approval and missed by a third. The teams that report smooth programmes are generally the ones that argued for realism early and were allowed to have it.

Deadline pressure makes it worse

With ECC mainstream maintenance ending in December 2027, there is real pressure to commit to dates. That pressure pushes teams to plan backwards from a deadline rather than forwards from evidence, which is how aggressive timelines get approved before anyone has measured the work. The honest response is not to ignore the deadline but to establish the facts early enough that the conversation about feasibility happens while options remain: start sooner, narrow scope, or take extended maintenance as a bridge. Profiling and assessment are what make that conversation possible. Without them the deadline is met with optimism, and optimism is the input that produces the overrun statistics in the first place.

How deKorvai helps

deKorvai addresses the data planning cause directly. It profiles ECC data to establish completeness, duplication and consistency before commitments are made, which turns the cleansing effort into a measured number. It then carries out that work: cleansing and de-duplicating master data with fuzzy matching, transforming and mapping to the S/4HANA model while preserving referential integrity, and reconciling the loaded result against the source so the outcome can be evidenced. Because the flow repeats consistently across mock cycles, effort is predictable rather than compounding, which is precisely where migration budgets tend to slip.

Key takeaways

  • Overruns are the norm, not the exception, across independent studies.
  • The causes are planning failures: scope, late code assessment, data planning, governance.
  • Executive ownership is thin, which slows the scope decisions that drive cost.
  • Data planning is the most controllable cause, because profiling settles it early.

Frequently asked questions

What percentage of S/4HANA migrations go over budget?

A 2025 Horvath study of 200 SAP user companies found more than six in ten exceeded budget, with only 8% finishing on schedule and projects averaging 30% longer than planned. A 2026 Precisely and ASUG survey found around 30% of in-flight projects already delayed or over budget.

Why do S/4HANA migrations go over budget?

The recurring causes are planning failures rather than technical ones: scope expansion without cost-impact analysis, custom code complexity assessed after budgets were set, inadequate data migration planning, weak governance that slows decisions, and underestimated process redesign.

Is executive sponsorship a factor?

It appears to be. Research reported in 2025 found the CEO personally leads the S/4HANA project at only 14% of smaller firms, with CFOs or COOs involved in 7%, and only 17% of companies backing preparation with change management. Thin sponsorship slows the scope decisions that drive cost.

Which cause is easiest to fix?

Data planning. Unlike code complexity or process redesign, the condition of your data can be established quickly by profiling it before the budget is committed, which converts the largest open variable in the plan into a measured quantity.

Ready to transform your data migration?

See how deKorvai can simplify your S/4HANA transformation program.

Book a Demo