A manufacturer running SAP S/4HANA has about 300 custom enhancements written against standard objects. SAP's published clean core guidance separates on-stack ABAP Cloud extensions built on released APIs from classic modifications of the core, with the stated aim that upgrades stop being an event for custom code. The team is planning the move and has a two-year window. Which sequencing rule should govern it?

The deciding property

The boundary being drawn is between logic the vendor owns and logic the business owns, and most organisations do not know which of their 300 enhancements is still on the business's side of it. In a fifteen-year-old ERP core, a large share of enhancements serve a process that changed, a report nobody opens, or a country the group exited. Classifying code you are going to delete is the most expensive way to spend the first quarter of a two-year programme.

Usage instrumentation is cheap in this setting, because the platform can record which custom objects are called in production. Run it over a period long enough to catch the business cycle, which for a manufacturer means at least one quarter-end and ideally one year-end, since the enhancements that only fire at year-end are both invisible in a month of data and the ones that break loudly.

The sequence

1. Instrument and wait. Collect execution counts per custom object across a full cycle. Publish the list of zero-execution objects with their owners.
2. Delete, with a reversible switch. Retire the unused set behind a flag before touching anything else. Expect a material reduction; it reprices the whole programme.
3. Classify the survivors by whether a released API exists. Those with one become on-stack extensions on the released interface. Those without are the real boundary problem: either request the interface from the vendor, or wrap the gap deliberately and record it as a known exception with a review date.
4. Move the high-change-rate logic off the core first, because the benefit of a stable boundary is proportional to how often the logic changes. Pricing and tax rules before a once-a-year statutory report.
5. Upgrade. By this point the regression surface is the exceptions list, which is small and documented.

Why the other options fail

Rewrite all enhancements as side-by-side services before upgrading. This is the sophistication answer, and it pays the full rewrite cost for code that should have been deleted. It also moves logic off-stack that would run perfectly well on-stack against a released API, adding a network hop and a second deployment surface to every call. Side-by-side is right when the extension has its own lifecycle, its own data or non-ABAP dependencies, not as a default.

Freeze enhancement work until the upgrade completes. Over a two-year window the freeze costs more than the upgrade. It also does not hold: urgent changes get made anyway, outside the programme's visibility, which is worse than making them inside it.

Upgrade first and repair whatever breaks in regression testing. The modifications are precisely what makes the upgrade expensive. Discovering their cost inside the regression window leaves no time to redesign anything, so every finding is fixed by the cheapest local patch, which recreates the problem the clean core boundary exists to remove.

When not to sequence it this way

If the enhancement count is small, say under 30, the measurement step is overhead and you should simply classify all of them in a week. The instrument-and-delete sequence earns its time at volume, where the first useful output is a smaller problem rather than a better plan.