SAP clean core is an approach to keeping anERP landscape maintainable while allowing the business to build thecapabilities it needs. A practical SAP clean core strategy starts byunderstanding each customization, choosing supported extension mechanisms, andassigning responsibility for its continuing operation. Moving code outside thecore is only one part of that work.
For U.S. companies planning SAP S/4HANAmodernization, this is a business decision as much as an architecture decision.An extension may protect a valuable pricing process, support a distributionchannel, or compensate for a process that should have changed years ago.Treating all customizations alike can remove useful differentiation or preserveunnecessary complexity.
SAP’s guidance onextending S/4HANA Cloud describes on-stack and side-by-sideapproaches and a clean core level concept for evaluating extensions. Leaderscan use that guidance as a starting point for a more specific question: whatshould this business keep, change, or retire?
Begin with the business purpose of each extension
Start with an inventory that connectstechnical objects to business activities. A list of programs does not explainwhich customers, employees, or financial commitments depend on them. Identifythe process owner, the intended result, the records changed, and the teamsaffected when the extension fails.
Consider an illustrative U.S. industrialdistributor with a custom customer rebate calculation. Sales considers itessential because negotiated agreements differ across customers. Finance needsthe resulting accruals to reconcile. IT knows the program requires extra workduring upgrades. Those perspectives describe one dependency that must beevaluated together.
Ask whether the underlying businessrequirement still applies. Some extensions serve contracts that remain active.Others were created for a discontinued product line or an old organizationalstructure. Usage data helps, but infrequent execution does not prove anextension has no value. A year-end calculation may be critical despite runningonly once annually.
For every retained extension, document aconcise reason to keep it. That reason should be understandable to someoneoutside the original development team. If nobody can explain the currentpurpose, investigate before investing in another technical rewrite.
Compare the requirement with standard capabilities
Before selecting a development approach,examine the standard process available in the intended SAP edition and release.A capability introduced since the original customization may now meet the need.Confirm configuration requirements, process differences, and relevantrestrictions with the functional team.
The comparison should focus on businessoutcomes. In the rebate example, the question is whether the standard approachsupports the actual agreement terms, approval requirements, and accountingtreatment. Similar screen labels are insufficient evidence that the replacementbehaves correctly.
Where a standard process can meet therequirement, calculate the transition work. Users may need differentprocedures, historical records may need reconciliation, and integrations mayneed adjustment. Removing code can simplify future maintenance while stillrequiring a carefully managed change today.
Avoid presenting standardization as anautomatic saving. Establish a baseline that includes maintenance effort,business exceptions, training, and upgrade testing. Then compare the expectedfuture process against that baseline using assumptions the business owneraccepts.
Choose an extension approach that fits the dependency
An extension that needs close transactionalcoordination has different requirements from a separate customer portal.Architectural placement should follow those requirements. Review supportedinterfaces, transaction boundaries, data access, latency expectations, and thelifecycle of the extension.
SAP’s BusinessTechnology Platform overview provides context for capabilities usedto extend and connect enterprise applications. However, choosing SAP BTP doesnot automatically resolve ownership or support design. A separate applicationstill needs deployment controls, monitoring, security administration, and arecovery procedure.
SAP also describes SAP Buildas a way to create and extend applications and automations. Evaluate therelevant tools against the requirement and the team’s ability to operate theresult. A fast prototype should not bypass production acceptance.
For the distributor, a rebate extensionmight require a carefully governed calculation service, an approval workflow,and a reliable posting interface. Each component should have a defined purpose.Adding another platform without removing an existing dependency can increasethe operational burden.
Review interfaces before promising upgrade stability
An extension can be physically separate andstill rely on fragile assumptions. It may depend on an internal object, a fieldinterpretation, or a response format that the team has not documented. Examinethe contract between the extension and the ERP system, rather than judgingcleanliness by location alone.
Use supported interfaces appropriate to theintended environment and confirm their release status. Record which operationsare permitted, which credentials are used, and how errors are handled. Theintegration should also identify the business object being changed so supportteams can trace an outcome.
SAP’s IntegrationSuite overview explains its role in connecting SAP and third-partyapplications through integrations, APIs, and events. Platform capabilitiesprovide useful building blocks, but the implementation must still defineduplicate handling, reconciliation, and business acceptance.
Test the interface when a dependent serviceis unavailable. If the rebate service returns late, does the process wait,retry safely, or request manual review? The answer affects the business andbelongs in the extension design.
Make testing part of the extension lifecycle
A clean core initiative needs evidence thatretained extensions continue to work. Build tests around the decisions andrecords that matter. For rebates, include an ordinary agreement, an amendedagreement, an unusual return, and a correction after a posting has alreadyoccurred.
Check the full process. A calculation maybe mathematically correct while reaching the wrong account or bypassing anapproval. Validate authorization, integration behavior, accounting impact, andthe information users need to investigate an exception.
Repeat relevant checks when the ERPrelease, extension, interface, or business rule changes. Keep test ownershipexplicit so the responsibility survives personnel changes. Automated checks canreduce repeated effort, while business review remains necessary for the meaningof the result.
SAP’s Cloud ALMoverview describes implementation and operations capabilities,including test orchestration and traceability. Confirm the supported scope andsetup for the landscape rather than assuming every component is coveredautomatically.
Fund the continuing work around the extension
The business case should include more thandevelopment. Budget for credentials, monitoring, change review, regressiontesting, incident investigation, and documentation. Identify who will respondwhen a process crosses between ERP and a separate service.
Measure progress through a combination ofarchitecture and business indicators. Useful measures include extensionsretired with owner approval, maintenance effort, upgrade defects, recurringexceptions, and recovery time for critical processes. A smaller custom codeinventory is helpful when the operating process also becomes easier to manage.
Prioritize changes where the business valueand technical risk justify the effort. A phased plan can address a high-riskdependency first while preserving a stable, understood extension until asuitable replacement is ready. Every deferral should have an owner and areason.
Frequently asked questions
Does SAP clean core prohibit customization
No. Clean core allows business-specificextensions while encouraging supported approaches and controlled dependencies.The relevant choice depends on the SAP environment, the requirement, and theavailable extension mechanisms.
Is every SAP BTP extension automatically maintainable
No. A BTP extension still needs reliableinterfaces, appropriate access, tests, monitoring, and support ownership.Separation from the ERP core is useful, but it does not replace lifecyclemanagement.
Where should a clean core assessment begin
Begin with a critical process and thecustomizations that support it. Connect the technical inventory to businesspurpose, then compare standard capabilities and extension options beforecommitting to redevelopment.
Build a clean core plan around real business dependencies
A sustainable SAP clean core strategypreserves useful capabilities while reducing avoidable maintenance risk. Startwith evidence about how the business uses each extension, choose supportedapproaches, and make continued operation part of the decision.
For help evaluating your SAP landscape andmodernization priorities, connect withGBSI to discuss the processes and extensions that deserve attentionfirst.
