What SAP's Autonomous Enterprise Means for Your Custom Code
The energy coming out of SAP Sapphire 2026 is real, and it deserves to be taken seriously. SAP's vision of the Autonomous Enterprise, a unified AI platform, more than 50 domain-specific Joule Assistants, 200 specialized agents, and a completely rethought user experience through Joule Work, represents the most coherent AI strategy SAP has put on stage. The platform architecture is sound.
We welcome it. Not cautiously, not with caveats buried in footnotes, genuinely. A stronger, more AI-capable SAP platform raises the bar for what constitutes good transformation and benefits every organization running SAP.
But between SAP's vision and your actual SAP landscape sits a problem that no keynote fully addressed, and that every SAP customer and partner needs to understand before they commit to an agentic strategy: your custom code carries the business logic your agents will depend on. And if that logic is not handled correctly, you are not building toward the Autonomous Enterprise. You are building toward something far more dangerous.
Welcome to Hallucination City
There has been substantial discussion at Sapphire and in the broader market about data quality as the foundation for agentic AI. Master data governance, golden record strategies, data fabric architectures, all of it is necessary, and purpose-built platforms for it are valuable investments. Clean data is the right starting point.
The agent does not hallucinate randomly. It executes confidently, at machine speed, on false premises.
But here is the problem nobody is talking about loudly enough: the cleanest data on the planet is not sufficient if an AI agent acts on that data without understanding the business logic embedded in your custom code.
Consider what happens when an AI agent processes a result that passes through customized business rules, pricing logic, compliance checks, and customer-specific fulfillment conditions that were never properly analyzed, remediated, or documented during the transformation. The agent does not hallucinate randomly. It executes confidently, at machine speed, on false premises. It carries false cargo.
Custom code carries its own category of risk, one that data quality programs are not designed to address. The issues embedded in custom code are different in kind: an agent operating on clean data but flawed business logic will produce results that look correct until something goes wrong downstream, in a financial close, in a compliance audit, or in a customer-facing process. By the time the failure is visible, the damage is done, and the root cause is buried in code that nobody fully understood to begin with.
If you ignore custom code, you are digging a hole you will not be able to crawl out of. You will end up with AI technical debt that makes today's technical debt seem trivial in comparison.
The Number That Deserves a Second Look
SAP announced at Sapphire that its new agent-led transformation tooling can reduce ERP migration effort by more than 35 percent, by automating system analysis, code remediation, configuration, and testing at scale. That is a meaningful claim.
But let us put that number in context.
At smartShift, we have been automating SAP custom code transformation for over two decades, from mainframe modernization through SAP Unicode conversions, Enhancement Pack Upgrades, custom code impact on relational databases, the move to in-memory with HANA, S/4HANA migrations, and now Continuous Custom Code Lifecycle Management. Our patented methods deliver 99.99% automation precision. That institutional depth is not incidental. It is what makes the difference between a tool that accelerates migration and a platform that guarantees outcomes.
For Kimberly-Clark, we resolved more than 305,000 ABAP issues across 5.8 million lines of custom code and delivered S/4HANA-ready results in six weeks, one month ahead of schedule.
For CONA Services, the largest Coca-Cola bottling network in North America, we transformed 45,000 custom objects and six million lines of code in eight weeks, compressing a support window that had previously taken four weeks to one.
For Potters Industries, 4,783 custom objects were transformed in four weeks under budget, saving approximately 960 developer days, with only two objects requiring minor manual adjustments during testing.
Thirty-five percent is a floor, not a ceiling. And for the customers carrying the heaviest custom code burdens, which describes most large SAP customers, the distance between 35 percent and what is actually possible is where the real cost and risk live.
Two Problems That Look Alike But Are Not
The expanded partnership ecosystem announced at Sapphire includes sophisticated players focused on data migration, analysis, mapping, and the movement of enterprise data as part of the cloud ERP journey. This is genuinely complex work, and purpose-built tooling for it has real value.
Data migration and custom code transformation are not the same problem.
But data migration and custom code transformation are not the same problem. They share a project timeline and sometimes a steering committee. They require entirely different capabilities.
Data migration is the process of moving structured records, master data, transactional history, and open items from one system to another with integrity and completeness. Custom code transformation is about understanding what thousands of ABAP programs, modifications, user exits, and Z-developments actually mean: the business logic encoded over decades, and then deciding with precision what to eliminate, what to preserve, and what to rebuild clean-core-compliant in the new architecture.
That second problem is fundamentally semantic. The code is not just instructions; it is corporate knowledge accumulated over years, written by people who often no longer work at the company, rarely fully documented, and almost never neutral in business impact. Up to 80 percent of custom code in a typical landscape is no longer actively used — but identifying which 80 percent, with confidence, is not a data mapping exercise. It requires deep SAP domain knowledge, a proven methodology, and precision tooling that can distinguish between a critical differentiating business process and an obsolete report from 2007.
Combining these under a single-provider assumption is a risk that shows up late in the project, when timelines are already under pressure, and the agents you have built are beginning to operate on business logic that nobody has fully analyzed.
Speed with Control: The Goal That Actually Matters
When we talk to CIOs and IT leaders navigating S/4HANA transformations, what they don’t ask for is autonomy in the abstract. What they ask for is speed without loss of control.
They need to move faster than traditional consulting timelines allow, because the maintenance window is real, consulting rates are rising 30 to 50 percent, and board patience has limits. But they also need to know exactly what happened to their custom code. Which objects were transformed? Which were retired? Which needed to be rebuilt? And why. Because that code carries legal, compliance, and operational weight that no organization can hand over to a black box and simply trust.
What CIOs want is not autonomy in the abstract. They want speed without loss of control.
Speed with control is not a compromise between ambition and caution. It is the right design goal for enterprise transformation.
This is what deterministic, engineering-disciplined automation delivers. Not AI that suggests and hopes, AI grounded in patented, rule-based methods validated to 99.99% precision, with every decision traceable and every output transparent. The customer retains authority. The transformation moves at machine speed. Both things are true simultaneously.
Imagine the benefit of this kind of deterministic platform as your foundation for all things agentic. The agents SAP is building through Joule will only be as reliable as the business logic they operate on. That logic lives in your custom code. How you handle it today determines whether your agentic strategy succeeds or your agents carry false cargo confidently at scale.
The Custom Code Landscape Does Not Stand Still
There is a broader point that gets lost in migration-focused conversations: custom code is not a problem you solve once.
SAP landscapes are living systems. Regulatory requirements change. Business models evolve. New functional requirements emerge every quarter. Even after a successful S/4HANA migration, organizations will continue to build and adapt custom extensions, and every new object they add is a future migration risk and a future agentic reliability risk if it is not built clean-core-compliant from the start.
The organizations that will benefit most from SAP's AI vision are not those who migrate and then drift back into customization debt. They are the ones who treat custom code governance as an ongoing discipline: knowing what they have, understanding what it does, retiring what they no longer need, and building what is new in a way that stays clean and stays visible.
That is not a migration project. That is a capability, and it becomes more important, not less, as agentic AI moves deeper into enterprise operations.
What This Means for SAP Customers and Partners
For organizations evaluating their path forward after Sapphire, three questions are worth asking before committing to an agentic strategy:
First: Has your custom code been fully analyzed for business logic, not just counted for object volume? The gap between estimated and actual effort in code remediation is where more than 60 percent of SAP projects exceed budget or timeline. More importantly, it is where agentic AI strategies built atop unresolved custom code will eventually fail.
Second: Are data migration and custom code transformation being resourced and tooled separately, with the right specialists for each? Assuming one addresses the other is one of the most common and most expensive mistakes in SAP transformation programs.
Third: After migration, what is your plan for the custom extensions you are keeping, and the new ones your business will inevitably require? A clean core is not a destination. It is a practice. And the AI technical debt created by ignoring this discipline now will compound as agentic capabilities mature.
The Vision and the Foundation
SAP's Autonomous Enterprise vision is the right direction for enterprise software. The ambition is real, the architecture is serious, and the ecosystem being assembled around it reflects genuine investment in making it work.
The foundation on which this vision depends runs through every custom ABAP object in every SAP landscape. The business logic that decades of customization encoded is not noise to be discarded. It is institutional knowledge, often the most accurate record of how a company's critical processes actually work. Handled correctly, it becomes the semantic layer that makes AI agents reliable. Ignored or approximated, it becomes the source of failure that no data program can compensate for.
The work of building that foundation, at machine speed, with engineering precision, and with full customer control over every outcome, is not something that happens automatically. It is where transformation actually happens.
That is the work smartShift has done over the past twenty years. And as the platform ambitions grow, the discipline required to execute on them becomes not a nice-to-have, but the difference between an agentic enterprise that works and one carrying false cargo.
