Ankur C. Das, SAP Cloud ERP Practice
Clean core — keeping custom logic out of the SAP core and building extensions on BTP instead — isn’t technically difficult; the patterns involved, side-by-side extensions, API-first integration, custom Fiori interfaces, the BTP ABAP Environment, are mature and well documented. Estates drift anyway because clean core is really a constraint on how an organization behaves under pressure, not a technical pattern. When a plant is down and an in-core fix takes two days versus three weeks for the clean approach, nobody in the room usually has the authority to choose the slower option — and doing that a dozen times a year is enough for non-compliance to compound on its own.
Making the policy hold requires three things in writing before go-live: a specific decision rule for what gets built where that a developer can apply without escalating, a named owner with real authority to say no even when the business is under pressure, and a documented exception path — because a rule with no sanctioned exception doesn’t produce compliance, it just produces undocumented workarounds nobody can see.
The trade-offs are real and worth stating plainly: side-by-side extensions are slower to build, add network latency, and need BTP operations skills many teams haven’t budgeted for. The right posture applies the discipline rigorously wherever SAP will touch the object in an upgrade, and pragmatically everywhere else — and the best time to make these calls is during migration itself, since that’s typically the only point anyone funds a real audit of custom code.
Curious what your own custom code would score? Get in touch with our team.