S/4HANA Migrations Fail Before They Start

A 2026 study of 200 companies running S/4HANA migrations found that only 8% finished on schedule. Over 60% exceeded budget. Nearly 65% reported severe quality deficiencies after go-live.¹

Those numbers are bad. The root cause ranking is worse.

The top five failure drivers were not data quality, not technical complexity, not ABAP remediation backlogs. They were: lack of IT integration in project planning (28%), poorly defined processes (24%), missing documentation on third-party systems (23%), insufficient cross-functional thinking (22%), and unclear role definitions (21%).

Read that list again. Every item is a decision failure.

The Migration Did Not Fail at Go-Live

It is tempting to treat post-migration quality deficiencies as go-live problems. The cutover ran long. The data load was bigger than expected. The interfaces broke. Something went wrong in the final stretch.

But that is not what the data says. “Poorly defined processes” means nobody assessed whether the business process was standardised enough to survive a brownfield conversion before choosing brownfield. “Unclear role definitions” means nobody established who has the authority to override a constraint when a system freeze window collides with a wave dependency. “Insufficient cross-functional thinking” means nobody modelled what happens when two workstreams that share a business process go live in different waves.

These are not execution failures. They are planning failures. And they happened months before anyone touched a transport.

What the Tooling Misses

The SAP migration tooling market is large and growing. Impact analysis. Process mining. Landscape management. Data acceleration. One vendor recently claimed AI can compress migrations from years to weeks.

Each of these tools addresses a real slice of the problem. Impact analysis tells you what custom code is affected. Process mining shows you how transactions actually flow. Data accelerators speed up the extraction and load.

But none of them answers a different question: who decides what, under which constraints, with what authority?

Consider the practical decisions that shape a migration programme:

A finance workstream scores 40% on process standardisation. Is that ready for brownfield, or does it need greenfield? Who decides, and what information do they need?

A production system freeze window blocks the preferred go-live date for Wave 1. Do you shift the wave, negotiate the freeze, or split the rollout? Who has the authority to make that call, and what are the downstream consequences?

Two workstreams share an intercompany pricing process. One goes live in Q2, the other in Q4. Someone needs to build and maintain an interim integration bridge for six months. Who owns that decision? Who funds it? Who decommissions it when the second wave lands?

These questions do not live in any impact analysis tool. They do not show up in process mining output. They are the connective tissue of the programme, and when they are left implicit, they become the root causes that show up in studies like this one.

The Constraint Problem

SAP migrations operate under a dense web of constraints that interact in non-obvious ways.

Hard constraints are binary. S/4 requires Unicode. GROW with SAP requires greenfield. Two cells sharing the same production system cannot have overlapping go-lives. These are enforceable by tooling and rarely cause surprises.

The problems live in the soft constraints and graduated thresholds. A rollout that exceeds key-user capacity during year-end close. A brownfield path on a system with 2,000 custom objects and a Clean Core target. An ECC instance on Enhancement Package 5 that needs an interim upgrade before conversion, injecting a dependency nobody planned for.

Each of these requires a human decision with clear ownership. Programme Director approves the capacity override. Enterprise Architect signs off on the Clean Core exception. Migration Lead accepts the data volume risk on a selective data transition.

When these approval chains do not exist before the wave plan is built, the plan contains implicit assumptions that nobody owns. The 65% quality deficiency rate is what those unowned assumptions look like after go-live.

The Deadline Makes It Worse

SAP ends mainstream support for ECC in 2027. Extended maintenance is available, but only on SAP’s terms. The clock is ticking for every organisation that has not yet migrated or committed to a path.

Deadline pressure compresses planning. And compressed planning is where decision architecture gets skipped. The temptation is to start moving. Pick brownfield because it is faster on paper. Sequence waves by geography because that is how the org chart works. Estimate costs as single points because there is no time for probabilistic modelling.

This is how you reproduce the 8% success rate. Not through incompetence, but through rational responses to time pressure that skip the structural questions.

What Would Change This

I have spent 25 years in this territory, building decision systems for organisations running complex transformations. The pattern I see is consistent: the programmes that land well are the ones that mapped the decision architecture before they mapped the data.

Concretely, that means:

Scoring process readiness per workstream before choosing a transition path. Not just “is it documented?” but “is it standardised enough that a brownfield conversion won’t break the business logic?”

Defining constraint ownership in advance. Every soft constraint has an approval authority. Every graduated threshold has a trigger point and an escalation path. These exist on paper before the wave planner runs, not as ad hoc decisions during execution.

Modelling cross-functional dependencies at the workstream level. If Order-to-Cash depends on Finance for intercompany pricing, that dependency is declared once and the downstream integration bridge requirements are inferred for every rollout pair where those workstreams have different timelines.

Running probabilistic simulations across the full matrix. Not single-point estimates, but P10/P50/P90 confidence bands on timeline and cost, with the ability to ask: “What would change if we added five ABAP developers instead of buying a data accelerator?”

None of this is exotic. It is the kind of structured decision-making that organisations apply to capital expenditure approvals, regulatory submissions, and clinical trial design. Yet it rarely gets applied to the programme that touches every business process in the enterprise.

Decision Architecture Does Not Fix Everything

Decision architecture does not fix everything. A programme with perfect constraint mapping and clear role ownership can still fail if the ABAP remediation is genuinely harder than expected, if a critical vendor goes dark, or if the business changes direction mid-flight.

But the study data suggests that those technical and external failures are not the primary drivers. The primary drivers are structural. And structural failures are the ones you can actually prevent, if you do the work before the programme starts.

The 65% quality deficiency rate is not a technical statistic. It is an organisational design failure measured after the fact.

The question for every CIO running an S/4HANA programme today is not “which tools should we buy?” It is “have we mapped the decisions that will determine whether this programme lands?”

If the answer is no, the migration has already started failing.