Sector Research - ERP Transformation

SAP S/4HANA: The Completion Rate Problem

Only 39% of SAP S/4HANA migrations in our research completed within 120% of their original timeline. This report examines the patterns behind the completion rate and identifies the programme-level decisions that distinguish the programmes that complete from the ones that do not.

Published Type Sector Research Report Coverage Gulf, India, Southeast Asia Sample 83 SAP S/4HANA migration programmes
83SAP S/4HANA migration programmes analysed
39%completed within 120% of original timeline
2.3xaverage budget overrun for programmes that stalled
18 monthsaverage delay for programmes that required recovery intervention

About This Research

This report draws on Elixir's direct involvement in 83 SAP S/4HANA migration programmes across the Gulf, India, and Southeast Asia, supplemented by structured interviews with programme directors and technology leaders from organisations that underwent S/4HANA migrations between 2022 and 2025. It represents the most comprehensive analysis of S/4HANA programme outcomes in these markets to date.

The research does not aim to evaluate whether S/4HANA is a good platform. It is. The research aims to understand why, given a sound platform and typically adequate initial investment, most programmes do not complete on time or on budget. The answer, consistently, is programme-level decision-making, not technology capability.

The Completion Rate Data

39% of the programmes in our sample completed within 120% of their original timeline. This means they were allowed a 20% buffer on timeline before being counted as an overrun, and still more than 60% exceeded it. The average overrun for programmes that did not complete within this threshold was 71% of original timeline -- nearly doubling the duration of the programme.

Budget overruns correlate strongly with timeline overruns. 91% of programmes that significantly exceeded their timeline also significantly exceeded their budget. The reverse is less reliable: some programmes absorbed budget overruns without major timeline impact, usually by adding resources at inflection points. But the correlation is strong enough that timeline management is the most useful single indicator of programme health.

What Distinguishes Completing Programmes

Customisation Discipline

Programmes that completed within threshold had an average customisation rate of 18% against standard SAP processes. Programmes that required recovery had an average customisation rate of 41%. The relationship is not perfectly linear -- some high-customisation programmes completed, some low-customisation programmes did not -- but it is strong enough to be the single best predictor of programme outcome in our data.

More important than the absolute customisation rate is the governance of customisation decisions. Completing programmes had a defined process for evaluating customisation requests against a standard -- cost, risk, strategic necessity -- and a named authority empowered to reject requests that did not meet the standard. Stalled programmes typically had informal customisation governance: requests were evaluated case by case, without a standard, and approval was often easier than rejection.

Integration Investment

Completing programmes invested, on average, 22% of total programme budget in integration -- mapping, building, testing, and managing the connections between SAP and the rest of the enterprise landscape. Stalled programmes invested 11%. The difference is not primarily in the budget allocation decision. It is in the quality of the integration landscape assessment at the start of the programme. Completing programmes identified more integration requirements earlier; the budget reflected the actual scope. Stalled programmes underestimated the scope and could not recover when the reality became clear without expanding the budget.

Go-Live Discipline

The most striking finding in our research is the long-term cost of going live before the system is ready. Of the 14 programmes in our sample that went live with significant open issues -- proceeding to production despite known, material gaps in functional completeness or data quality -- 13 experienced a period of operational disruption that required emergency stabilisation. The average duration of this stabilisation period was six months. The average cost was 35% of the original programme budget.

The 11 programmes that delayed their go-live to resolve significant issues had shorter total elapsed times from programme start to stable production than the 14 programmes that went live early. Going live early is not faster. It is faster to the go-live date and slower to stable production. The distinction matters: the business is not benefiting from the new system during the stabilisation period, regardless of which date appeared on the programme calendar.

"Going live is not the destination. Stable, performant operation is the destination. The organisations that confuse the two consistently pay more to reach the one they actually want."

Recommendations for Programmes at Risk

For programmes currently in flight that are showing signs of stress -- timeline slippage, scope expansion, team turnover, or go-live delays -- the most important thing is an honest assessment of where the programme stands against the three predictors: customisation rate, integration investment adequacy, and go-live readiness criteria. This assessment will usually surface uncomfortable findings. Those findings are the prerequisite for a realistic recovery plan.

Recovery programmes that succeed are the ones that make hard decisions early: unwinding customisations that are blocking progress, investing in integration scope that was underestimated, or accepting a go-live delay that the programme cannot safely avoid. The alternative -- managing appearances while the programme continues to drift -- consistently produces more expensive outcomes than the hard decision would have.

Download the Full Report

The complete report includes programme-level data, decision framework analysis, detailed case studies of recovery interventions, and a self-assessment tool for programme teams to evaluate their risk position.