The Z-table nobody in the room can fully explain
I've sat in this meeting more than once. The clean core principle sounds tidy on a slide: keep customization out of the core and put it in an extension so the upgrade path stays open. Then someone pulls up a Z-table that actually drives pricing for a manufacturing client, four hundred entries deep with nine layers of nested condition logic, plus a comment field that reads temp fix, ask Dave next to a change dated 2011. Dave left in 2016.
Nobody currently on the account can say with confidence which of those four hundred entries protect a real business rule and which were bandages for a bug that got patched out of the product a decade ago. That's the actual starting condition for most clean core decisions, not the two-box diagram in a methodology deck. A framework that only works when the person who wrote the logic is still around to explain it doesn't hold up as a framework.
What the fit-to-standard workshop actually found
On one project I worked, the fit-to-standard workshop for pricing ran three sessions longer than scheduled, because every exception needed someone to reconstruct the original problem before the room could agree whether S/4HANA still had it. We walked the condition types against the new pricing procedures and the improved scale and formula handling that shipped since this client's ECC system went live back in 2009.
About sixty percent of the custom logic turned out to be a workaround for gaps that S/4HANA's standard pricing engine now actually closes, mostly around scale break calculations and multi-tier rebate handling that used to need a custom user exit and now live in configuration. Another piece was a genuine business rule, a contractual pricing tier for one distributor that standard condition technique still can't express cleanly. The rest was neither, dead code nobody had the nerve to delete, still firing on every pricing call for orders that stopped existing years ago.
Three different answers, not one clean core rule
The decision framework earns its keep right here, because clean core actually breaks into three separate answers, and mixing them up is how a project loses months. Logic that standard S/4HANA now covers gets rebuilt clean, configured in the core through the standard extensibility points, or dropped outright once someone confirms the business rule behind it no longer applies.
That contractual pricing tier for the one distributor, the genuine business rule, is the kind of thing that belongs in a side-by-side extension on BTP. It has no clean path inside the core, so it gets built once as a proper extension with its own lifecycle and its own test cycle, talking back to the core through an API contract rather than a direct table write.
The third answer is the one everyone avoids saying out loud during planning. Some logic can't be resolved cleanly before the go-live date a steering committee already promised to a customer, a board, or a regulator. That's where a temporary classic extension earns its place: a deliberate, named exception that keeps the core clean enough to pass certification while buying time for the real rebuild later. The mistake is treating this third bucket as an embarrassment and hiding it inside the second one, calling a stopgap a side-by-side extension because that sounds better in the steering committee deck.
Why temporary classic extensions rarely stay temporary
None of this shows up in the pitch about the move from customization to capability that every transformation kickoff makes. Once a system goes live and pricing runs correctly through the first month end close, the appetite to touch it again drops close to zero. The team that built the classic extension moves to the next project. The budget line that funded the rebuild gets reallocated to whatever fire is burning that quarter.
I've watched this happen on three separate SAP programs now. A temporary classic extension from go-live shows up unchanged in the scope for the next major upgrade three or four years later, and by then the person who remembers why it was supposed to be temporary has also left. The extension meant to buy six months buys a decade instead, and it becomes exactly the kind of undocumented, unowned logic the next clean core initiative will eventually trip over. Clean core is, when you follow the money, a budget decision, and a temporary extension with no funded return date is a budget decision made by default, in the direction of doing nothing.
Put the decommission date in the charter, not in someone's head
The fix has to happen before go-live, not after it. Every temporary classic extension needs a named owner and a target release or fiscal quarter for the rebuild. That commitment belongs in the migration risk register, reviewed on a schedule instead of waiting for the next major transformation to rediscover it. If the business case for the rebuild doesn't survive being written down next to the go-live decision, that's useful information too. It means the temporary fix was actually the right permanent answer, and the honest move is to reclassify it instead of pretending otherwise.
What doesn't work is a verbal agreement in a steering committee meeting that someone will circle back after go-live. Support work after go-live comes with its own backlog of tickets and its own pressure to keep systems running instead of revisiting decisions everyone thought were settled, exactly the dynamic behind why support gets harder right after go-live. If a piece of custom logic is going on a retirement clock, treat it the way you would treat any item on a modernization retirement list, with an owner named and a follow-up date attached, not left for whoever opens that Z-table next to sort out.
Before your next fit-to-standard workshop wraps, ask the room to name, out loud, which of the three buckets every open exception actually falls into, and who owns the date on the ones that land in the temporary pile. That's the sentence that either gets written down or gets forgotten, and only one of those still looks defensible in three years.
