Your S/4HANA Migration Is a Deadline, Not a Modernization Program

There is a particular kind of board slide circulating in SAP-centric enterprises right now. It shows a three-year program, a nine-figure number, and a title along the lines of "Digital Core Modernization." Underneath the title is something much narrower: a technical conversion driven by SAP's maintenance calendar. Mainstream ECC support ends in 2027, extended maintenance runs to 2030, and the compatibility-pack transition period has already closed. Those dates are real and they justify real budget. What they do not justify is the belief that hitting them constitutes modernization. Plenty of organizations will land on S/4HANA in 2028 with the same brittle integration topology, the same 14,000 custom objects re-platformed into cloud infrastructure, and the same inability to expose a trustworthy business capability to anything outside SAP. The deadline will have been met. Nothing will have been modernized.

Two ledgers, not one program

The most useful discipline we impose on SAP transformation programs is a hard separation between two funding ledgers. Ledger one is deadline work: conversion, remediation, data migration, custom code cleanup, license restructuring. It is largely non-discretionary and delivers no new capability — its business case is risk avoidance. Ledger two is capability work: the side-by-side extension layer, the event backbone, the domain services and product data models that let non-SAP systems and AI agents transact against your core safely.

Blend the two and ledger two always loses. Every time a conversion milestone slips, capability work becomes the release valve, and it slips into a "phase two" that never gets funded because the deadline money is gone. Keeping them separate lets you defend the capability spend on its own merits, and it forces an honest conversation: if the entire program is ledger one, say so out loud and stop calling it transformation.

Composability is now an AI prerequisite, not an aesthetic

The argument for composable architecture used to be speed and vendor optionality. That argument was easy to defer. The newer argument is harder to dismiss: composability is emerging as the strongest predictor of whether AI initiatives actually reach production. The MACH Alliance's 2025 global research found that enterprises well advanced in composable adoption were roughly twice as likely to successfully deploy AI — not because composability is magic, but because agents need stable, granular, well-governed entry points into business capability. A monolithic core with 400 undocumented Z-programs and batch-file integration offers nothing an agent can reason about.

SAP's own direction reinforces this. Joule agents, AI Foundation on BTP, and the semantic layer emerging around SAP Business Data Cloud all assume a landscape where extensions live outside the core and business context is modelled explicitly. If your conversion strategy re-embeds logic in the core because that is the fastest path to the 2027 date, you are optimizing against the platform's own roadmap.

Drawing the composability boundary

The practical work is deciding, capability by capability, where something belongs. We run this as an explicit boundary decision with four options:

• Keep in the core, standard: the process is regulated, undifferentiated, and SAP's standard behaviour is good enough. Most finance and compliance logic lands here.
• Extend side-by-side on BTP: the logic is differentiating and changes faster than your core release cycle. Pricing nuances, partner-specific workflows, custom approval chains.
• Move to a domain service outside SAP: the capability is genuinely product-like, needs its own release cadence, and serves multiple consumers — commerce experiences and CX journeys are the usual candidates in the SAP Commerce and CX landscapes we work in.
• Retire: the capability exists because someone in 2011 needed a report. Roughly a fifth of custom objects in a typical ECC estate fall here, and finding them is the cheapest win in the program.

The boundary is not a one-time exercise. It is an architectural standard that governs every change request for the next decade, which is why it belongs to enterprise architecture rather than to the systems integrator running the conversion.

What good looks like at the end

Judge the program on capability, not on go-live. Can a new channel consume order, inventory, and customer data through a governed contract without an SAP developer in the loop? Can an agent read master data with the permissions of the user who invoked it? Can you upgrade the core without a six-month regression cycle? If the answer to all three is yes, the 2027 date was incidental. If the answer is no, you bought a very expensive extension of the status quo.

The organizations that will look smart in 2030 are not the ones that converted earliest. They are the ones that used a compliance deadline as cover to fund the architecture they needed anyway — and were rigorous enough to keep the two ledgers apart.