The Custom Code Trap
Most SAP ECC environments accumulated custom code over 10 to 20 years of operation. Custom transactions, ABAP enhancements, user exits, BAdIs, reports, and interfaces were built to address real business needs that standard SAP couldn’t handle at the time. And many of them still work.
But working and migration-ready are not the same thing. Every custom object in your ECC system is a potential compatibility issue in S/4HANA. The Simplification Database (SAP’s catalog of changes between ECC and S/4HANA) documents thousands of table changes, function module deprecations, and transaction replacements. Custom code that references any of these needs assessment, remediation, or retirement.
Industry data confirms the scale of this challenge. 44% of organizations cite customizations as a top migration barrier. Migrations are running roughly 30% longer than planned, and custom code remediation is the single largest variable in that overrun. Organizations with fewer than 500 custom objects may face minimal costs here. Those with 5,000+ can face months of dedicated remediation effort before the conversion even begins.
The organizations that underestimate their custom code exposure are the ones that blow their budgets and timelines. But there’s a structural solution to this problem, and it starts with rethinking where customization lives.
What Clean Core Actually Means
Clean Core is SAP’s architectural principle for S/4HANA: keep the core ERP system as close to standard as possible, and extend functionality through the SAP Business Technology Platform (BTP) rather than modifying the core.
This isn’t about eliminating all customization; that’s neither practical nor desirable. Every organization has unique business logic that standard SAP doesn’t cover. Clean Core is about separating what must live in the core from what can live outside it.
Core business processes (financial accounting, materials management, production planning, sales and distribution) run on standard S/4HANA. Extensions, integrations, custom UIs, reporting logic, and industry-specific workflows move to BTP, where they can be developed, deployed, and updated independently of the core system.
The benefit is architectural and long-term: a clean core is upgrade-ready. When SAP releases new functionality or quarterly updates, a clean core system can absorb them without regression risk from custom modifications. Your S/4HANA environment stays current, maintainable, and future-proof. This matters because SAP is increasingly delivering innovation through quarterly updates (embedded AI, process automation, Fiori UX improvements) and organizations with heavily customized cores can’t adopt these without extensive regression testing.
SAP BTP: The Extension Platform
SAP BTP is the cloud-native platform that enables the Clean Core approach. It provides three primary capability areas for enterprise extension, each addressing a different type of customization need.
Integration Suite and SAP Build
SAP Integration Suite (formerly CPI) handles all system-to-system connectivity, replacing the aging PI/PO middleware with cloud-native integration flows, API management, pre-built connectors, and event-driven messaging. Adoption jumped from 33% to 46% year-over-year among surveyed organizations, reflecting how central integration has become to migration strategy. For organizations running PI/PO today, migration to Integration Suite is increasingly a prerequisite for S/4HANA, not an afterthought.
SAP Build complements Integration Suite with low-code/no-code tools for process automation (replacing custom ABAP workflows with visual designers), application development (building custom Fiori apps without deep coding), and work zone design (role-based digital workspaces). It enables citizen developers and business analysts to build extensions without ABAP expertise, particularly valuable for mid-market organizations where SAP development resources are constrained.
Cloud-Native Extensions
For custom logic that requires full development capability, BTP supports cloud-native extensions using CAP (Cloud Application Programming model), Node.js, Java, and ABAP Cloud. These extensions connect to S/4HANA via APIs and events, maintaining clean separation between core and custom. They’re versioned, independently deployable, and don’t require S/4HANA downtime for updates. This is where complex industry-specific logic, custom analytics, and AI-powered workflows live.
How BTP Changes the Migration Equation
Clean Core with BTP fundamentally changes the migration cost-benefit analysis in three ways.
It Reduces Migration Scope
Custom code that can be re-implemented as BTP extensions doesn’t need ECC-to-S/4HANA remediation. Instead of converting thousands of custom ABAP objects for compatibility, you categorize them: retire what’s no longer needed, remediate what must stay in the core, and re-implement everything else on BTP using modern tools. This typically removes 30 to 50% of custom code from the migration critical path.
It Reduces Ongoing Maintenance Cost
BTP extensions are cloud-native, versioned, and independently deployable. They don’t create regression risk during S/4HANA updates. When SAP releases a quarterly update, your clean core absorbs it; your BTP extensions continue running independently. The long-term TCO of a clean core + BTP architecture is significantly lower than a heavily customized environment that requires extensive testing with every update.
It Unlocks Innovation
BTP is the platform for AI, automation, and advanced analytics in the SAP ecosystem. Embedded AI, predictive models, Agentic AI workflows, and advanced analytics all run on BTP. With 61% of organizations planning to adopt SAP BTP (up from 57% the prior year), the platform isn’t optional; it’s the standard. A clean core architecture positions you to adopt these capabilities as they mature, without re-architecture.
Real-World BTP Use Cases
At Tachyon, we’ve implemented BTP solutions across multiple enterprise scenarios. Here are four that illustrate the range:
Integration and Process Automation
PI/PO to CPI migration: For a global materials manufacturer, we migrated their entire integration middleware from on-premise PI/PO to cloud-native Integration Suite. This replaced aging infrastructure with modern API-based connectivity, reduced hosting costs, and enabled real-time event-driven patterns that PI/PO couldn’t support. It also positioned them for S/4HANA by removing a major integration dependency on the legacy landscape.
Bulk HR process automation: For a major European energy company, we used SAP Build Process Automation to replace custom ABAP programs handling bulk hiring and termination in SuccessFactors. A fragile, code-heavy process became a visual, low-code automation that the HR operations team could modify themselves.
UX and Identity
Fiori UX development: Building role-based Fiori applications on BTP (mobile-ready, persona-specific, integrated with S/4HANA via standard APIs) without modifying the core system. Critical for user adoption, since S/4HANA’s value depends heavily on the Fiori UX layer.
Cloud Identity Services: Implementing IAS/IPS for unified identity management across the SAP landscape. Without centralized identity, managing authentication across BTP, S/4HANA, SuccessFactors, and third-party systems becomes a security and operational burden. This is foundational for any cloud-native extension architecture.
The Migration-Ready Architecture
The ideal S/4HANA migration architecture separates concerns clearly. The S/4HANA core handles standard business processes. BTP handles integrations, extensions, and custom logic. Data flows between them via clean APIs and events. Each layer can be updated independently.
At Tachyon, we approach every S/4HANA migration with this architecture in mind. Our readiness assessments include a custom code disposition analysis that categorizes every object: retire (no longer needed), remediate (must stay in core for technical reasons), or re-implement on BTP (can move to modern platform). This analysis drives both the migration timeline and the target architecture, ensuring that you don’t just get to S/4HANA, but arrive with an environment that’s built for the next decade of innovation.
The Clean Core approach also aligns with Tachyon’s cross-practice advantage. Our SAP practice designs the core architecture. Our Data & Analytics practice builds the data pipelines on BTP. Our Agentic AI team deploys intelligent agents that use BTP’s AI capabilities. And our Salesforce practice ensures CRM integration flows cleanly through Integration Suite. It’s one architecture, designed by one team.
Conclusion
Custom code is the legacy of decisions that made sense at the time. Clean Core is the architectural principle that ensures your S/4HANA investment stays modern, maintainable, and upgrade-ready. SAP BTP is the platform that makes Clean Core practical, providing the tools to extend, integrate, and innovate without compromising the core.
If you’re planning an S/4HANA migration, start with your custom code inventory and your Clean Core strategy. Everything else (timeline, budget, migration path) flows from that foundation.
Evaluating Clean Core for your S/4HANA migration?
Clean Core isn’t just a migration methodology — it’s a long-term architectural decision. Before you commit to a path, make sure you understand what stays, what moves to BTP, and what gets retired. Our team helps you build that roadmap with clarity.
