Why S/4HANA timelines fail: the hidden link between data and functional change
By Jamie Neilan | 17 March 2026
SAP S/4HANA transformation programmes are often planned around business deadlines or maintenance end-dates, before organisations fully understand the functional and data implications of the move. From a data specialist’s perspective, this can introduce significant delivery risk, particularly when timelines are defined before key architectural and migration decisions have been explored. In this blog, Jamie Neilan shares his perspective on why data transition and functional change are so tightly intertwined in S/4HANA projects.
SUMMARY: SAP S/4HANA transformation programmes are often planned around business deadlines or maintenance end-dates, before organisations fully understand the functional and data implications of the move. From a data specialist’s perspective, this can introduce significant delivery risk, particularly when timelines are defined before key architectural and migration decisions have been explored.
In this blog, Jamie Neilan, Managing Director of the PRISM Transformation Global Service Line at EPI-USE Labs, shares his perspective on why data transition and functional change are so tightly intertwined in S/4HANA projects. Drawing on more than 20 years of SAP experience, he explains the preparation steps organisations should consider before beginning a transformation programme, and how different S/4HANA scenarios influence the complexity and automation potential of data migration.
The S/4HANA entanglement of data and functional change
SAP S/4HANA projects take many forms. Source systems differ, database changes vary, custom code can range from minimal to almost infinite, and the way organisations use SAP varies widely. Despite this complexity, project timelines are often defined very early, often based on business imperatives or financial modelling before enough insight exists to know whether those timelines are realistic.
From a data specialist’s perspective, this is where many projects begin to struggle.
At EPI-USE Labs, we work across many S/4HANA transformations and see a wide variety of approaches. Some organisations pursue Selective Data Transition (SDT); others plan full system migrations. Some move in carefully staged phases, while others attempt a single large conversion or upgrade. Across all of these scenarios, we examine similar questions:
- How much custom code exists?
- What does the technical baseline look like?
- How can data handling be automated as much as possible to reduce delivery risk and protect project timelines?
SAP remains extraordinary technology. A significant proportion of the world’s finance, logistics, payroll, manufacturing and project management systems run on SAP. Moving to S/4HANA therefore represents far more than a technical upgrade. It is a transformation of one of the most important systems inside the business.
Because of this, organisations often try to extract immediate value from the transition. The move to S/4HANA is expected to unlock benefits such as cloud architecture, improved security, modern data capabilities and AI readiness. However, what I frequently observe is that the requirements behind these programmes are still vague or insufficiently researched. The urgency is often driven by maintenance deadlines and the pressure to move away from legacy platforms.
That urgency is understandable. But pushing too hard, too early, often introduces unnecessary risk
Lessons from old fables
Most people know the story of the hare and the tortoise: slow and steady wins the race. The message is simple; moving too quickly without thinking carefully about the path ahead can cause you to lose.
Coming from a predominantly Gaelic ancestry, I have always been interested in where these stories originate. There is a similar Scottish Gaelic tale called Maol a’ Chreachainn, often translated as ‘The Bare-Skinned Fox’.
In this story, a ragged fox encounters animals that are larger and stronger than he is. Those animals rely on strength and speed. The fox relies on patience, observation and strategy. Through persistence and careful thinking, the fox repeatedly turns situations to his advantage. The stronger animals, who depend only on speed or power, end up defeated.
Scottish and Gaelic myths were largely passed down orally, so I cannot refer to an original text; but you can find examples online. One of the earliest collections was compiled by J. F. Campbell in the nineteenth century. These stories may be ancient, but the lessons remain important and, in the S/4HANA project context, are relevant (in my view). Many S/4HANA programmes could benefit from remembering them.
Data and functional change cannot be separated
One of the most common misconceptions in ERP transformation is that functional change and data transition can be planned independently. In reality they are tightly intertwined.
This sometimes creates tension between business stakeholders and technical teams. Yet by this point, most organisations recognise that IT is not simply a support function. It is fundamental to how the business operates.
For organisations considering or already executing an S/4HANA transformation, there are several areas that should be clearly understood before the project accelerates. If these areas are not yet defined, it is often better to pause and address them properly rather than rushing forward simply to meet a deadline.
Good preparation reduces transformation cost and significantly increases the likelihood of a successful go-live. In other words, the tortoise approach often proves more successful than the hare. Careful preparation may feel slower at the beginning, but it usually leads to a far more stable transformation journey.
Foundational preparation steps
Customer and Vendor Integration (CVI)
Customer and Vendor Integration introduces the Business Partner model and is a critical preparation step from a data perspective. SAP provides clear guidance and tooling, including the CVI cockpit. However, functional decisions need to be made before the technical process can begin.
SAP has recommended for many years that organisations complete CVI as pre-work ahead of their S/4HANA transformation. It can be handled during the project, but doing so adds complexity and risk.
Core functional changes to plan early
Several other functional changes should also be understood early in the programme. Asset Accounting changes in S/4HANA and organisations need a clear understanding of how the new model will be adopted and how existing structures will transition.
The new General Ledger is not simply an optional enhancement. It forms a fundamental part of the S/4HANA architecture and therefore requires careful planning.
Simplification items and related business process changes also play a significant role. These changes determine how legacy functionality evolves or disappears in S/4HANA. Understanding them early helps organisations decide whether a Greenfield, Brownfield or Hybrid transition approach is most appropriate.
Enterprise structure and architecture changes
Many organisations use the S/4HANA transition as an opportunity to redesign their enterprise structure. Company codes may be reorganised, systems may be merged, and reporting structures may be simplified. Yet it is common to see projects begin with only a vague description of the target architecture.
If structural change is part of the transformation, enterprise architecture expertise should be involved early. Baseline, transition and target architectures must be clearly defined because these decisions affect both functional design and data transition strategy.
Common S/4HANA transformation scenarios
From a data perspective, S/4HANA transformations usually fall into several broad categories. Each category influences which migration techniques and automation approaches are possible. Understanding these differences early requires patience and strategic thinking. Organisations that take the time to understand their landscape properly are usually the ones that avoid the most expensive mistakes.
Single system transformations
Brownfield big bang
These scenarios are relatively straightforward from a data perspective, although mandatory functional changes still exist. In many cases, a highly automated SDT approach can be used. Data can move point-to-point with a high level of automation.
Greenfield big bang
Greenfield transformations involve significantly more business process change. As a result, data migration becomes more functional in nature, and some data may be created anew rather than migrated.
SAP’s Data Migration Cockpit typically becomes the primary loading mechanism, although other certified tools can also be used. Selective extraction pipelines can still be automated, but the process usually involves more manual steps and functional validation.
Multi-system transformations
Integration to composable architectures
In the S/4HANA world, a single ECC system may evolve into a more composable architecture. Core functions such as Finance and Logistics may remain within S/4HANA, while other capabilities such as HCM, Payroll, Customer engagement or Contract accounting move into specialised platforms.
Where the target systems remain ABAP based, automation can remain highly effective. Where SaaS or API-driven systems are introduced, semi-automated migration approaches are typically required.
System consolidation
Another common pattern is system consolidation, where several legacy systems are merged into a single S/4HANA environment. While cost reduction or licensing simplification often drives these decisions, technically they represent some of the most complex transformation scenarios.
Initial data loads into a master system can often be automated. However, merging multiple systems or managing phased go-lives usually requires more semi-automated approaches combined with careful validation.
Why data expertise must be involved early
One pattern we frequently observe is that S/4HANA projects move into delivery stages before a coherent data strategy has been defined. Sometimes organisations release functional Requests for Proposals (RFPs) or define delivery timelines without consulting data specialists.
This usually leads to one of two outcomes:
- In the first scenario, a data solution is specified too early without fully understanding the constraints. When deeper analysis begins the design proves unworkable.
- In the second scenario, functional teams define the programme structure and timeline first. Data specialists are then asked to deliver solutions that simply cannot be achieved within those constraints.
Both situations introduce avoidable risk.
A final thought
S/4HANA transformations will continue for many years to come. These programmes represent some of the largest and most complex changes organisations undertake within their core systems.
The lessons of old fables remain surprisingly relevant. The hare relied on speed and confidence, and lost. The Gaelic fox relied on patience and strategy, and succeeded.
In S/4HANA transformations, careful preparation and realistic planning almost always outperform rushed timelines.
Continue the conversation
Data transition remains one of the most complex and underestimated aspects of SAP S/4HANA programmes.
In our upcoming webinar, ‘Automating data transition in SAP S/4HANA’, we explore how different transformation scenarios influence data strategies and how automation technologies can help reduce delivery risk.
Register to join the discussion, or explore the full De-risking SAP transformations webinar series, where experts from EPI-USE Labs and EPI-USE share practical insights from real transformation programmes.
Jamie Neilan
Jamie is the Managing Director of the EPI-USE Labs’ PRISM Transformation projects Global Service Line (GSL) in Europe, with 20 years of experience in the IT services Industry, primarily with businesses using SAP. Jamie’s career started as a SAP Technical Consultant; he then went on to specialise in SAP data projects, BASIS, RunSAP, and Pre-Sales/Solution Architecture. He has a variety of SAP certifications,and his background includes programming, DBA work, web design and SAP technical work. Jamie has broad experience on various platforms, and is passionate about leveraging SAP technology to bring value to our clients.