Every year, large enterprises commit tens of millions of euros to S/4HANA migration programmes. They assemble steering committees, sign partnerships with system integrators, and launch kickoff workshops with genuine ambition. Then, somewhere between the business blueprint and the first wave of user acceptance testing, things begin to unravel.
Timelines slip. Budgets stretch. The go-live date moves — once, twice, three times. Post-implementation reviews cite “underestimated complexity” and “data quality issues.” And the people who were supposed to benefit from the transformation spend the first twelve months fighting workarounds that feel suspiciously familiar.
The technology is rarely the problem. SAP S/4HANA is a mature, powerful platform. The roadmap is clear, the tooling has matured, and the migration pathways — greenfield, brownfield, selective data transition — are well-documented. So why does this keep happening?
The Real Culprit: Inherited Process Assumptions
Every legacy ERP system is, at its core, a crystallisation of decisions made by people who are often no longer with the organisation. Workarounds that were implemented in 2009 to compensate for a process gap. Custom Z-tables that no one can fully explain. Approval workflows that exist because a CFO who retired four years ago once requested them.
These artefacts are invisible on a system architecture diagram. They are not captured in a standard fit-gap analysis. They do not appear in the RFP response from your implementation partner. But they are there — embedded in how your finance team actually closes the month, how your procurement team actually manages exceptions, how your warehouse team actually processes returns.
When a migration programme begins by mapping “as-is” processes based on documentation rather than observation, it inherits every one of these assumptions. When it then configures S/4HANA against those inherited assumptions without questioning them, it builds a new system on an unverified foundation.
The concrete goes down. The building goes up. And then the cracks appear.
The Fit-Gap Analysis Problem
The standard fit-gap analysis is one of the most widely used and least reliable artefacts in enterprise transformation. In theory, it compares current business processes against standard SAP functionality to identify gaps requiring customisation or development. In practice, it is often completed by consultants who are mapping documentation against templates, generating a report that reflects what the organisation believes it does — not what it actually does.
This distinction matters enormously. The business process documentation that feeds a fit-gap analysis is typically written by process owners who describe the intended process, not the operational reality. Shadow processes, local adaptations, and systematic workarounds simply do not make it into the documentation.
The result is a configuration blueprint that addresses documented requirements accurately while entirely missing the operational complexity that will surface the moment users touch the new system.
Data Migration: The Most Underestimated Work in Any Programme
If process assumptions are the first failure point, data migration is the second — and it is almost universally underestimated.
Data migration is treated, in too many programmes, as a technical task. Extract the legacy data, transform it to fit the S/4HANA data model, load it into the new system. The complexity is assumed to be technical: mapping fields, handling character sets, managing volume.
The real complexity is analytical. Legacy data carries the history of every inconsistency, every exception, every workaround that was ever applied to the source system. Vendor master records that were created by five different people using five different naming conventions. Material masters with incomplete classification hierarchies because the product team never had time to maintain them properly. Open items in accounts receivable that were partially resolved through journal entries that do not reconcile cleanly to the subledger.
None of this is visible until you actually run data quality analysis against the source system with honest intent. Organisations that do this early — before configuration begins — discover things that change the scope of the programme. Organisations that do it late discover the same things when they can no longer afford to address them properly.
The Senior-Resource Bait and Switch
There is a structural problem in large systems integrators that deserves direct acknowledgement: the team that wins the programme is rarely the team that delivers it.
Proposal presentations are staffed with senior architects and experienced programme managers. Delivery teams are assembled from consultants at earlier stages of their careers, often working from delivery centres where the hourly rate economics make more sense for the partner’s margin structure.
This is not always the case. But it is common enough to be a pattern that procurement teams and CIOs should interrogate directly. The question to ask is not “who will lead this programme” but “who will be on site, in the configuration workshops, in the design decisions, week by week throughout delivery.”
The gap between those two answers is often where project risk lives.
What a Diagnostic-First Approach Actually Looks Like
The alternative to inheriting assumptions is to surface them deliberately before they become embedded in the design.
A proper pre-implementation diagnostic looks different from a standard fit-gap analysis. It begins with process observation, not process documentation — shadowing the people who actually run the end-of-month close, who process the supplier invoices, who manage the exceptions in the warehouse. It looks at the actual data in the legacy system, not a summary of what should be there. It asks the uncomfortable questions: why does this workaround exist, what would break if we removed it, and what does that tell us about the process we are about to configure?
The output of this diagnostic is not a gap list. It is a set of process truths — verified, observed, and understood — that become the actual foundation for the configuration blueprint. It also typically includes a data quality remediation backlog and a list of process decisions that need to be made by the business before configuration can responsibly proceed.
This adds time at the front of the programme. It almost always saves more time at the back.
The Intelligence Layer That Changes What Is Possible
One final shift is worth noting for organisations planning S/4HANA programmes in 2025 and beyond: the emergence of genuine AI capability inside the SAP platform changes what post-go-live value looks like.
SAP Joule, the AI copilot embedded across the S/4HANA suite, is maturing rapidly. BTP-based ML pipelines enable predictive analytics directly against ERP data without the latency of external data warehouse architectures. Intelligent automation, built properly on top of accurate processes and clean data, can compress cycle times and reduce exception handling in ways that were not achievable five years ago.
None of this is accessible on top of a poorly implemented foundation. The AI layer that makes your ERP act intelligently depends entirely on the quality of the processes and data underneath it.
This is why the diagnostic-first principle is not just a risk management posture. It is a prerequisite for realising the full value of what the modern SAP platform can actually deliver.
The organisations that will extract genuine competitive advantage from S/4HANA over the next decade are the ones that invest in getting the foundation right — before a single line of configuration is written.
