Baseline ATC before you migrate — turn the wall into a backlog

The first time a team runs ATC with the ABAP_CLOUD_DEVELOPMENT_DEFAULT variant against years of custom code, the result is demoralizing: thousands of findings. The instinct is to either panic or ignore it. A baseline is the third, correct option — it freezes today’s findings so you can stop the bleeding and burn down the backlog at your own pace.

What a baseline actually does

An ATC baseline marks the current set of findings as “known”. From that moment:

• New findings (in code you touch) are surfaced and can block a transport.
• Existing baselined findings are tracked but don’t fail every check.

So you immediately stop adding new Clean Core debt, then schedule the existing debt down deliberately.

A practical setup

1. Run the right variant. ABAP_CLOUD_DEVELOPMENT_DEFAULT for ABAP Cloud readiness; S4HANA_READINESS_2023 if you’re still getting onto S/4HANA. Run it against your custom packages, not SAP’s.
2. Baseline the result. Snapshot today’s findings as the accepted starting line.
3. Gate new code. Wire ATC into your transport release / CI so a new finding in changed objects is visible before it ships.
4. Burn down worst-first. Sort by category and risk — direct table writes and unreleased APIs before cosmetic ones — and remediate in batches.

Make the backlog legible

Raw ATC output isn’t a plan. Group findings by the pattern behind them (the same five we covered here) so each batch is a single, repeatable fix rather than a thousand unique ones. A quick readiness audit gives you the same worst-first ordering in a few minutes, before you even open ATC.

Where this leads

Baselining is what makes “move to Clean Core” a roadmap instead of a cliff. It’s the first thing we set up in a Lumivara assessment — measure, freeze, then remediate in priority order without halting delivery.