If your AI plans are queued behind an S/4HANA migration, they are queued behind an eighteen-to-thirty-six-month programme that most organisations have not finished. They do not need to be. AI enablement and ERP migration should be coordinated - but delivered as two separate programmes.
Start with the timeline, because it is the whole argument. A full ECC-to-S/4HANA migration typically runs eighteen to thirty-six months for a large enterprise, and often longer. Mainstream support for ECC ends at the close of 2027, which is driving a scramble; even so, industry estimates suggest only around a third of moves are complete, with a large share of organisations still mid-cycle or not yet started. Migrations also have a habit of slipping - research has put the proportion running late or over budget at roughly sixty per cent.
Now place your AI ambitions behind that. If AI on SAP is treated as something that comes “after S/4HANA”, it comes after all of the above. For a transformation leader, that is years of deferred value - and years in which competitors who separated the two pull ahead.
Why the two get bundled together
The instinct to fold AI into the migration is understandable. There is a belief that only S/4HANA is truly AI-ready; a reluctance to build anything on a platform you are about to replace; and a wish to keep governance simple by having one big programme rather than two. Each of these is reasonable on the surface. Each is also beatable, and the cost of not beating them is measured in years.
The case for two programmes
AI enablement and ERP modernisation are related, but they have different clocks, different risks, different owners and different value profiles. The migration is a large, slow, high-risk platform change that touches everything. AI enablement, done well, is a series of smaller, faster, lower-risk capability additions that sit in a governed layer over the estate you already run.
Coordinating the two is wise. Merging them into a single critical path is not - it chains the fast, low-risk work to the slow, high-risk work, and guarantees the AI value arrives at the pace of the migration rather than the pace of the opportunity.
Coordinating AI with your S/4HANA migration is wise. Chaining them into one programme is not.
“But we are about to replace it”
This is the strongest objection: why build anything on ECC if S/4HANA is coming? The answer is in how you build. The AI experience and the tool contracts are kept stable and deliberately separate from the underlying connector. When ECC is later replaced, you swap the connector to S/4HANA APIs and update the mappings where the object model changes - and the AI experience carries on unchanged.
So the work is not throwaway. You are not building on ECC; you are building a portable layer that happens to sit over ECC today and will sit over S/4HANA tomorrow. The investment outlives the platform beneath it, which is the opposite of stranded.
The bonus: AI can help the migration, not just wait for it
Here is the reframe that turns the objection on its head. An AI layer over legacy SAP is not only something you can build before the migration - it can help the migration land. A migration-discovery assistant can read and explain the customised estate: surfacing custom objects and dependencies, unused reports, data-quality issues and candidates for rationalisation.
That matters because migrations run late and over budget largely when teams do not understand their own customised estate - the Z-objects nobody wants to touch, the interfaces whose owners have left. AI that reads and explains that estate attacks the exact cause of the overruns. Far from being a distraction from the migration, an AI layer can de-risk it.
AI over legacy SAP is not a distraction from your migration. Done right, it helps the migration land.
What “coordinated but separate” looks like
In practice, this is not two disconnected efforts - it is one roadmap with two delivery tracks, each with its own gates and its own pace:
- Shared roadmap, separate tracks. Both programmes appear on one plan so dependencies are visible, but neither is on the other’s critical path.
- Reuse the semantic model. The canonical business model you build to make SAP AI-consumable documents your estate in business terms - an asset the migration can reuse, since you have to understand the estate to migrate it anyway.
- Let the governance reinforce. The clean-core discipline a migration encourages and the governed-access discipline AI requires pull in the same direction; each makes the other easier.
The cost of waiting
Every quarter AI sits behind the migration is a quarter of deferred productivity, and a quarter competitors are free to use. With migrations running eighteen to thirty-six months and many organisations only mid-cycle, “after S/4HANA” can realistically mean 2028 or later. That is a long time to leave the most valuable operational data in the business untouched by AI, waiting for a platform change to finish.
The bottom line
You do not have to choose between doing AI and doing S/4HANA, and you do not have to do them in sequence. Coordinate them on one roadmap, run them as two tracks, and let a governed AI layer deliver value now - and even help the migration arrive on time. If you are weighing how to sequence the two without holding either hostage, that is exactly the conversation we would have.
Contact us to know more.
