SAP S/4HANA Migration Failures: The Three Decisions That Determine Whether Your Programme Recovers

Why S/4HANA Programmes Fail More Than They Should

SAP S/4HANA is a sound platform. The failure rate of S/4HANA migrations is not primarily a technology problem. It is a programme management problem, and more specifically, it is a decision-making problem. The decisions that determine whether a migration succeeds or fails are made early, often before the project has generated enough information to make them well, and their consequences are felt much later, when changing course is expensive.

In Elixir's experience across more than thirty SAP transformation engagements in the Gulf and South Asia, the programmes that failed or required significant recovery fell into patterns. The patterns were consistent enough to identify the three categories of decision where failure concentrates.

Decision 1: How Much to Customise

The customisation decision is the one that looks most controllable and is least controlled in practice. Every S/4HANA implementation begins with a commitment to adopt standard processes -- the SAP Best Practice approach. This commitment erodes under pressure from business stakeholders who want the system to work the way the business currently works, not the way SAP thinks it should work.

Customisation is not inherently wrong. Some degree of customisation is appropriate for almost every enterprise. The problem is customisation without discipline -- saying yes to requests from individual functions without evaluating the cumulative impact on implementation timeline, upgrade cost, and system performance. The programmes that fail are almost always the ones that hit 40% or more customisation without realising they had crossed the threshold where the implementation had become something fundamentally different from what was originally scoped.

Recovery from excessive customisation requires a difficult conversation: some of those customisations need to be unwound. The functions that requested them will resist. The programme team will be reluctant to restart work that was already completed. The programme sponsor needs to be in the room, with authority, when these decisions are revisited. Programmes where this conversation is avoided rarely recover on schedule.

Decision 2: How to Handle Integration

No large enterprise runs SAP in isolation. SAP connects to CRM systems, manufacturing execution systems, warehouse management systems, payroll platforms, banking interfaces, and a long list of legacy applications that have been running core processes for years. The integration layer is where S/4HANA implementations most commonly encounter problems that were not anticipated in the original scope.

The integration decision is the one where technical underestimation most consistently produces business consequences. Integration is typically scoped as a fixed-effort workstream early in the programme, before the actual complexity of the existing landscape is fully understood. When the reality of that landscape is revealed -- and it always is, eventually -- the integration workstream either expands and delays the programme, or it is constrained and the gaps show up at go-live as missing functionality.

Recovery programmes that succeed almost always include a dedicated integration audit: a systematic inventory of every connection between SAP and every other system, with a clear status on each. This audit typically reveals integrations that were never scoped, integrations that were scoped but not built, and integrations that were built but do not work correctly in the production environment. The audit is not comfortable, but it is the prerequisite for knowing what the programme actually needs to complete.

Decision 3: When to Go Live

The go-live decision is the most consequential single decision in an S/4HANA programme, and it is frequently made under the wrong kind of pressure. The pressure to hit the committed go-live date -- from the board, from the vendor, from the implementation team that has been working toward this date for two years -- can override the technical and operational indicators that the system is not ready.

Go-live when the system is not ready is not a recovery option. It is a different kind of failure, with different consequences. A programme that misses its go-live date has a delay and a cost overrun. A programme that goes live prematurely has a delay, a cost overrun, and a period of operational disruption that may affect customers, suppliers, and revenue. The recovery from a bad go-live takes longer and costs more than the recovery from a delayed go-live.

The organisations that make the go-live decision well have established, in advance, the specific criteria that must be met before the system goes live. These criteria are measurable and non-negotiable: data migration completeness above a threshold, performance testing within parameters, training completion above a percentage, open issue count below a number. When the criteria are not met, the go-live does not happen. The conversation is then about which criteria are not met and what is required to meet them, not about whether the criteria still apply.

What Successful Recovery Looks Like

Programmes in recovery have, by definition, already made at least one of these decisions badly. The recovery does not undo the original decision. It makes a new decision, clearly, with full information about the consequences of both paths. This requires programme leadership that is willing to be honest about what went wrong and why, and a governance structure that can absorb that honesty without looking for someone to blame.

Elixir's recovery engagements consistently begin with the same diagnostic: a structured assessment of the three decision points, with a clear-eyed view of where the programme currently stands on each one. The assessment is uncomfortable. It is also the fastest path to a recovery plan that the programme team will actually execute, because it is built on the truth of where the programme is rather than the story of where it was supposed to be.