The full Custom Code Migration loop

Custom Code Migration is not a one-shot scan; it is a loop, and running it in order is what keeps the effort proportionate to the value. It starts with scope by usage: enable SCMON on the productive system for a representative period so you know which custom objects are actually executed, and combine it with SUSG when you need a landscape-wide, multi-system roll-up. There is no point spending a sprint fixing a report nobody has run since 2014.

With scope in hand you run the quality scan — ATC with the `S4HANA_READINESS_<year>` variant for your target release (e.g. `S4HANA_READINESS_2025`), remotely from the central system against the source — and export the findings (to Excel, or via the results API into a spreadsheet or BI tool) so you can plan rather than firefight. Then you prioritise on three axes at once: is the object actually used, does it touch a standard object that the Simplification items are changing, and what is the cost to fix. High-usage, standard-impacting, low-cost items go first; unused or trivially isolated ones can wait or be retired.

Adaptation means rewriting to released APIs wherever feasible; you grant an exemption only where the rewrite cost is genuinely unjustified this cycle (a legacy interface you will retire next year, say), so exemptions stay the rare exception, not the habit. Finally you re-baseline each sprint, which both records the debt you actually paid down and resets the 'new debt' line for the next iteration — turning migration into a steady, measurable cadence instead of a heroic push.

Source notes: clean-core-curriculum §8.5