Ask anyone who has sat through the post-mortem of a delayed S/4HANA programme and you will hear the same suspects named. Development took longer than the estimate. The integrations turned out messier than anyone expected. Testing dragged. All true, usually, but those are symptoms. In most of the delayed migrations we have seen, the clock started slipping months before a developer opened Eclipse or the first transport request was created.
The problem is rarely poor development. It is decisions that never got made.
Companies spend serious money on migration factories, automation tools and experienced consultants, then still run into repeated scope changes, surprise dependencies and stabilisation phases that drag on a quarter longer than planned. The common thread is not technology or talent. It is uncertainty, and specifically the habit of postponing hard calls until execution is already underway.
The Industry Has Been Solving the Wrong Problem
The SAP ecosystem has spent the last decade getting very good at technical complexity. Code scanners, automated conversion utilities, AI-assisted remediation, impact analysis, test automation, readiness checks. Genuinely useful, all of it. And yet delays still dominate transformation programmes.
Here is the gap: a tool can identify issues, but it cannot decide which issues matter. A scanner will happily report 4,000 custom objects that need attention. It will not tell a CIO which two hundred of those deserve real investment, which ones still earn their keep, or how to separate an enhancement propping up a mission-critical manufacturing process from one that has not run since 2019.
That distinction takes business context, and business context only shows up when someone actually makes a decision.
Migration Does Not Start With Development
Most organisations still file migration under “technical project”. It is closer to a business transformation with a technical phase inside it. Long before anyone modernises a line of ABAP, someone has to answer the awkward questions. Which custom developments still create measurable value? Which exist purely because of a process that died years ago? Which interfaces touch revenue? Which enhancements would be genuinely dangerous to modify, and which objects can safely wait until after go-live?
None of those are technical questions. They are business decisions that happen to need technical evidence. The trouble is that plenty of enterprises try to answer them while development is already running, and by that point every change costs more, every assumption carries more risk, and the plan grows another branch each time a call gets deferred.
The Hidden Cost of Decision Debt
Everyone in enterprise IT knows the phrase technical debt. There is a quieter cousin that does at least as much damage in migration programmes: decision debt.
Decision debt builds up every time a team says “we will decide that during development” or “let’s validate it in testing”. Each postponed call leaves a pocket of uncertainty in the plan, and uncertainty has a way of maturing into rework. Unlike technical debt, none of it lives in source code. It lives in project plans, undocumented dependencies, conflicting stakeholder expectations and half-finished migration strategies. By the time it surfaces, the development team is committed, the timeline is public, and every fix is expensive.
In a fair number of programmes, decision debt ends up causing more delay than the technical debt everyone was worried about at the start.
Why Custom ABAP Is Not the Villain
There is a persistent idea that custom ABAP is the root problem in SAP modernisation. It is not, or at least not in the way people assume. That code exists because standard SAP could not do something the business needed. Over the years it automated manufacturing steps, tightened financial controls, stitched third-party systems together and, in some cases, created genuine competitive advantage.
The real difficulty is that after ten or fifteen years of continuous change, almost nobody has full visibility into which developments are still used, which quietly duplicate standard functionality that now exists, which support business-critical operations and which are dead weight. Treat all custom code as migration work and you burn effort on objects nobody needs. Treat none of it as important and you take on far worse risk. The whole game is telling the difference.
When Migration Plans Collide With Reality
Picture a global manufacturer moving from ECC to S/4HANA after fifteen years of customisation: thousands of reports, user exits, interfaces and custom transactions spread across procurement, finance, production and logistics. The roadmap looks tidy on paper. Assessment done, developers allocated, modernisation underway based on the technical findings.
Three months in, momentum stalls. Business users testing the finance workstream discover that a custom program flagged for retirement still drives part of the monthly reconciliation. A production planning enhancement everyone assumed was dead turns out to be in daily use at one regional plant. An interface nobody had on the map is quietly feeding data into three downstream systems.
No developer made a mistake here. The organisation simply started executing before it understood its own landscape. So development pauses, architecture gets revisited, plans get redrawn and test cycles repeat. The schedule slips, the budget grows, and the steering committee starts asking harder questions. The real cost is not the weeks lost. It is executive confidence, which is much slower to rebuild than a project plan.
What Successful SAP Transformation Programmes Do Differently
The organisations that land S/4HANA migrations on time rarely have better tools than everyone else. What they have is a different sequence. Planning is not treated as a warm-up exercise; it is where the important decisions actually get made. Four things stand out.
1. Business value before technical complexity
Not every object deserves equal attention. Strong teams start by identifying which custom developments touch revenue, customers, compliance or business continuity, and let that (rather than object counts) set the priority order.
2. Dependency visibility
SAP estates are deeply interconnected, and one minor-looking enhancement can sit underneath dozens of reports, workflows and external applications. Mapping those relationships before execution is what prevents the nasty surprises later.
3. Explainable decisions
A migration programme answers to CIOs, architects, auditors, finance and delivery partners. “Why are we retiring this application?” and “why redesign this enhancement instead of keeping it?” need evidence-based answers, because explainability is what lets stakeholders sign off quickly instead of relitigating every choice.
4. Governance before automation
Automation is brilliant at speed and hopeless at judgement. Without human approval, architectural guardrails and traceable decisions, it simply helps you move faster in the wrong direction. Teams that pair the two see far fewer late-stage surprises than teams leaning on automation alone.
The Missing Layer Between Analysis and Execution
Most migration tooling does one of two jobs well. It either produces technical findings or automates technical execution. Very little helps with the awkward middle bit: turning a mountain of findings into decisions people are willing to commit to. That middle bit is exactly where programmes tend to wobble.
This is the thinking behind Aceteroid. Rather than positioning itself as yet another automation tool, it works as an ABAP-native decision and execution platform for SAP migrations. The premise is blunt: clarity before execution. Work out what should be retained, adapted, redesigned or retired before modernisation starts, then let execution follow approved decisions instead of assumptions. Speed turns out to be a side effect. The real product is confidence.
Looking Beyond Go-Live
One more misconception worth clearing up: the idea that success is measured on deployment day. Go-live is the start of a new operational phase, not the finish line. The teams that do this well keep watching application stability, fix runtime issues quickly, keep improving custom developments within Clean Core principles, and make sure new work does not quietly recreate the technical debt they just spent two years removing. Migration is less an event than the opening move of a longer modernisation effort, and governance needs to run through all of it, not just the implementation phase.
Start With Clarity
S/4HANA migrations rarely fail for lack of developer skill or clever automation. They struggle because organisations start changing systems before working out what should change. Every deferred decision adds a little uncertainty, and every unmapped dependency sits there quietly as rework waiting to be discovered in test.
The programmes that finish well treat modernisation as something that begins with clarity, months before development. Replace assumptions with evidence, raw findings with decisions someone owns, and unattended automation with governed execution, and migration becomes a far more predictable exercise. When business continuity is on the line, that sort of clarity is not admin. It is an advantage.
Frequently Asked Questions
Why do SAP S/4HANA migration projects get delayed?
Usually because execution starts before scope, dependencies and business impact are properly understood. Weak early decisions create more delay than slow development does.
Is custom ABAP the main reason migrations are difficult?
No. The code itself is not the problem. The missing piece is knowing which developments still earn their place and which can be retired or reworked safely.
How can organisations reduce migration risk?
Invest in decision clarity up front: dependency analysis, business context, prioritisation and governance, with reasoning stakeholders can actually inspect before anything is built.
What role does governance play in SAP modernisation?
It keeps every change transparent, reviewed and tied to a business objective. Automation provides speed; governance provides accountability and stops unnecessary change.
