The roadmap slide has no line items
Most of the clean core presentations I have sat through share a slide. On the left is a box labelled custom code, with a count in the low thousands. On the right is a box labelled SAP BTP. Between them is an arrow. The arrow is the whole plan, and the arrow has no cost attached to it.
Clean core is usually pitched as an architecture principle. Keep the S/4HANA core free of modifications so that upgrades stop hurting, and put the logic that makes your business different into extensions that use released APIs. I agree with the principle. I have stopped believing an architecture team can deliver it alone. The move out of the core is paid for three times, by three different people, and until each of them has signed, the slide describes a wish.
The first payment is the extension platform itself: the BTP subscription, a runtime, connectivity, and a team who can operate all of that when something fails at two in the morning. The second is the rewrite of each object that has to leave the core. The third is the retirement of the objects that should not be rewritten at all. Retirement is a bigger share of the list than anyone expects, and it is the hardest to fund, because nothing new exists when it is finished.
The programs nobody wants to touch carry the most business weight
Run the custom code migration app against a twenty-year-old ECC estate and you get a list. The trouble is the top fifty entries once you sort them by how many people would notice if they broke. Those are the month-end pricing routine somebody wrote in 2009, the user exit that quietly corrects a plant code on every goods receipt, and the report the treasury team runs before every hedging decision. Nobody in IT wants to open them, because the person who understood them left.
Every one of those objects has a business owner, and that owner is almost never in the clean core steering meeting. The finance controller who depends on the pricing routine has never heard the phrase clean core. When the architect proposes rewriting it as a side-by-side extension, the controller hears that a thing that works will be replaced by a thing that might not, on a timeline that collides with year-end close. When the architect proposes retiring it, the controller hears that month-end will get slower. Neither conversation appears on the slide, and neither can be won by an architect.
This is why I push back when clean core is scoped as a technical workstream. Retiring a custom object is a business decision with a technical consequence. Each retirement needs a name against it from the function that uses the thing, a date that function has agreed to, and a fallback they have accepted in writing. We have covered the general pattern in why modernization needs a retirement list. S/4HANA is the sharpest case I know, because the custom objects and the business processes have been maintained together for decades.
Who signs for each of the three costs
When I review a clean core plan, the first thing I ask for is the cost model broken into those three parts, with a named approver on each. The platform cost lands with whoever owns infrastructure and licensing, and it is a run cost, so it needs to survive next year's budget round as well as this one. I have watched a BTP budget approved as a project line and then quietly cut when the project closed, which left side-by-side extensions running on a subscription nobody was tracking. Run our checklist for reading a licensing change against the BTP entitlement before you commit to it.
The rewrite cost lands with the program, and it is where estimates go wrong most often. Moving a modification onto a released API, or turning an in-core enhancement into an ABAP Cloud extension, is a specification exercise before it is a coding one. Somebody has to work out what the old code does, including the three branches that only fire in one company code, and somebody from the business has to say whether those branches still matter. Budget the discovery separately from the build, and expect the discovery to change the build. If nobody has drawn which downstream systems consume each object's output, do the integration map before the roadmap first.
The retirement cost is the one that almost never appears. Retiring a custom report means a period where the old report and its replacement run together, a reconciliation between the two, a message to the people who used the old one, and someone to answer the ticket that arrives three months later asking where it went. Most of that is business time, and it comes out of the function's own capacity. If the function has not agreed to spend it, the object stays in the core, and the clean core count stalls at exactly the objects that matter most.
Write the exception rule before the first exception
The second thing I look for is the decision right. SAP's extensibility guidance lays out tiers, from key user and developer extensibility inside the stack, through side-by-side extensions on BTP, to classic modifications you are meant to avoid. That guidance tells you what is possible. It does not tell you what your organization will accept, and every organization arrives at a different answer, usually one exception at a time under deadline pressure.
So write the rule down before the program starts. Say what counts as an acceptable in-core extension in your estate, with named examples from your own code. Say who can approve a modification that breaks the rule, and keep that group small with at least one business member in it, because the pressure to approve always comes from a business deadline. Then say when an approved exception expires. An exception with no expiry is a permanent modification with better paperwork. The pattern we described for identity exceptions, an owner, an end date, and a review record, transfers directly to custom code.
The exception register then becomes a budget instrument. Every entry on it is an object that will need funding again on the day it expires. Review the register in the same meeting where next year's BTP and program budgets are set and the expiries stop being surprises. Review it in an architecture forum that has no money and the expiries get extended, until the register is a list of things everyone has agreed to ignore.
What I say when the slide comes up
When the box and arrow appear in the steering meeting, I ask four questions. Which named objects are on the retirement list, and which business owner has agreed to each retirement date. Which named objects are being rewritten, and what is the discovery budget for finding out what they do today. What is the BTP run cost in year three, and whose budget line does it sit on. And who approves an exception to the in-core rule, and on what date does that approval lapse.
A plan that can answer those four questions is a plan. I will support it even when the retirement list is short and the rewrite estimates are rough, because the money is attached to people who can spend it. A plan that cannot answer them is a slide, and the right response is to send it back to the sponsor with a request for the line items, before anyone books a BTP subscription against it.
If your clean core program is already running, pull up the object list this week and sort it by business dependency instead of technical complexity. Find the owner of the top entry and ask them, in plain terms, whether they would rather fund a rewrite or a retirement. Their answer is the first real line item your plan has had.
