Code remediation checklist for the S/4HANA move

The remediation phase of an S/4HANA migration is where projects quietly go over budget. Not with a bang — with a thousand small “just one more” fixes that turn six weeks into six months.

This is the checklist we hand to every ABAP team we bring onto a remediation. Twelve categories, ordered by how much pain each will cause if you skip it. Nothing exotic — just the things you’ll actually hit.

Before you write any remediation code

Run the SAP Readiness Check on your production system. Not sandbox. Production. The Simplification Item catalog it produces is the single most useful artefact for scoping. Every SI flagged as “Relevant” is a small project. Every SI flagged as “Not Relevant” is a decision you’ll defend in the audit.

Run the Custom Code Migration app (formerly Custom Code Analyzer). It gives you a bucketed list of every affected custom object with a severity. You’ll disagree with some of its assessments — that’s fine, but you need this as your starting inventory.

Set up ATC with S/4HANA cloud-check variants — even if you’re going Brownfield on-prem. The cloud checks are strictly stricter than any other setting, so they surface the largest number of issues. You can decide to not fix some of them — but you want to see them all first.

Pick a target ABAP language version. For most migrations that’s ABAP 7.5x or 7.9x. Set the CLASS-POOL / package-level version. Anything below that gets remediated up on touch.

The twelve categories, in priority order

1. Business Partner (BP) approach

If you haven’t converted from separate KNA1/LFA1 to the Business Partner model, you cannot go live on S/4HANA. Everything else waits behind this.

• Run the CVI (Customer-Vendor Integration) health checks.
• Reconcile customer master and vendor master into BP master. This is not a coding task — it’s a data quality and business ownership task. Assign it to Finance, not IT.
• Custom code that reads KNA1/LFA1 directly needs to switch to BUT000-based access. Wrapper function modules help but don’t hide the model change.
• Custom fields on the old customer master need to be transitioned to BP with proper number-range configuration.

Rule of thumb: budget 8–12 weeks minimum. If you’re mid-sized and multi-country, add more.

2. New Asset Accounting (New GL / New Asset Accounting)

Mandatory on S/4HANA. If your ECC is still on classic Asset Accounting, this is an activation project that touches every asset ledger you have.

• Depreciation area setup revisits, technical clearing account setup, ledger group mapping.
• Custom asset transactions (Z-BAPIs that post to specific transaction types) need reverification against the new posting logic.
• Reports that reference AFVW-B are almost all broken. Replace with FAGLFLEXA / ACDOCA-based reads.

3. Universal Journal (ACDOCA)

S/4HANA collapses financial data into one big table. Your custom finance reports that joined BSEG / BSAK / BSID / BKPF / KOKR need to be redirected to ACDOCA.

• BSEG is still there for compatibility, but performance is better against ACDOCA and business content flows through it. Redirect on touch.
• Custom line-item extractors need review.
• SELECT SINGLE against BSEG with WHERE BUKRS = ... AND BELNR = ... AND GJAHR = ... is fine. SELECT * FROM BSEG with a filter that’s not the primary key is a slow disaster on ACDOCA-backed reads.

4. Material number extension (MATNR 40 characters)

Optional-but-typical. MATNR is 18 characters on ECC. In S/4HANA it can be extended to 40. Whether you extend or not, custom code needs to handle both cases without truncation.

• Search all Z-code for MATNR TYPE C LENGTH 18 — or C(18) — and replace with the standard MARA-MATNR data element (which is versioned by config).
• Interfaces (IDocs, BAPIs, RFCs) that hardcode 18-char material numbers need remediation.
• Custom search helps that limit input length need updating.

5. Selects that assume classic performance characteristics

S/4HANA runs on HANA. Your ABAP has to be HANA-aware, whether you want it to be or not.

• No SELECT * with implicit conversion into a subset structure. It works, but the optimiser can’t push down. Explicit SELECT f1, f2, f3 is required for pushdown.
• FOR ALL ENTRIES IN itab with a non-key filter is a common performance killer. Replace with a proper JOIN in ABAP SQL or a CDS view.
• Nested SELECTs inside loops — the ECC 6 workhorse — are the number-one source of hypercare tickets. Rewrite as joins or as CDS view consumption.
• AMDP / SQLScript for cases where the pushdown genuinely belongs in HANA. Don’t over-index on this — but do use it where it matters.

The ATC HANA readiness checks will surface most of these. Trust them.

6. Obsolete syntax and removed language features

Trivial to fix but there’s a lot of it.

• TABLES statement in the top of report programs — replace with explicit data declarations.
• Old-style internal tables with HEADER LINE — replace with WORK AREA / structured LOOP INTO.
• MOVE-CORRESPONDING from structure to internal-table line — use appropriate structured MOVE-CORRESPONDING (7.4+ syntax).
• Character-literal comparisons that assumed non-Unicode. Almost all remaining non-Unicode systems are gone, but if yours isn’t, that’s a separate migration you should have finished a decade ago.

Use the ABAP cleaner / Formatter integrated with Eclipse ADT for a lot of this. Don’t do it by hand.

7. Removed or replaced function modules

The Simplification database (SDB / SNOTE) catalogs replacements. Common examples:

• Pricing / rebate FMs replaced by BRF+ or new pricing structures.
• MRP-related FMs replaced by S/4HANA aMRP or DDMRP.
• Old settlement rules FMs.

For every one flagged, decide: rewrite against the replacement, or wrap and accept the code smell for now. Wrapping is fine as a bridge — but track it, budget a follow-up to un-wrap in the optimisation phase.

8. Enhancements — BAdIs / SPDD / SPAU / user exits

Everything with source-code modification (SPDD / SPAU objects) needs a decision:

• SPDD (data dictionary modifications): usually simple, mostly automatic in SUM.
• SPAU (program modifications): each one needs a human review. If the modification is because standard didn’t do what you needed and standard still doesn’t in S/4HANA — keep it. If S/4HANA now does what you needed natively — retire the modification.

User exits and classical customer exits should be reviewed for continued applicability. Many of them exist because standard SAP didn’t have a BAdI at the time. If a BAdI now exists, migrate.

9. Interfaces — IDocs, RFCs, PI/PO/BTP Integration Suite

• Standard IDocs sometimes change structure. Check every custom IDoc extension and every partner-profile change.
• RFC-enabled BAPIs occasionally get replaced by newer signatures. Adjust custom RFC calls.
• PI / PO scenarios that map ECC IDocs to external systems are affected wherever the source IDoc structure changes. Plan integration testing accordingly.
• Consider whether this migration is also the moment to move point-to-point RFCs to event-driven eventing via the SAP Integration Suite. Sometimes yes, sometimes no. Don’t scope-creep, but know the choice is available.

10. Custom Fiori launchpad content and old UI technologies

• Web Dynpro ABAP applications — no longer strategic. Assess for retirement or Fiori rebuild.
• BSP applications — same. Usually retire.
• SAP GUI screens (module pools, dynpros) — supported, but consider selective Fiori rebuild for high-frequency user journeys. If a warehouse operator uses a Z-transaction 300 times a shift, that’s a Fiori app that will pay for itself in six months.
• Custom Fiori tiles / apps on ECC UI5 — need review for S/4HANA target UI5 version compatibility. Usually straightforward.

11. Roles, authorizations, and CDS access controls

Not strictly ABAP but hits developers early.

• New authorization objects for CDS views (S_ANLA and friends).
• Fiori catalog / group assignments per role.
• If you were doing back-office finance via GUI, that user is now clicking Fiori tiles. Make sure the authorization design reflects the new access surface.

12. Test coverage as remediation happens

The overlooked category. Every remediation ticket should also add or update an ABAP Unit test if none exists. You will re-remediate 20% of everything you fix here before go-live. Without unit tests, that re-remediation regresses randomly.

Set a policy: no remediation transport released without ABAP Unit tests updated. It slows things down 15%. It saves twice that in the hypercare phase.

The delivery model that works

We run remediation with three roles, in this ratio:

• 1 architect / lead who owns the ATC exception policy, the “keep it / retire it” calls, and the master customisation inventory.
• 3–5 remediation developers who take the ATC / Custom Code Analyzer output as their backlog and grind through it.
• 1 test / build engineer who owns the ATC pipeline, the regression suite, and the transport landscape.

For a 30,000 custom object landscape, that team runs 4–6 months. Add capacity linearly for larger landscapes, sub-linearly for smaller.

What to hand off, and to whom

At the end of remediation, produce three artefacts:

• The as-remediated inventory — every custom object, its status (retired / rewritten / kept), and its owner going forward.
• The standing exceptions register — every ATC finding you consciously decided not to fix, with reason.
• The hypercare watchlist — the 20–30 custom objects most likely to cause production issues in the first month.

Give all three to the sustainment team. If you’re the sustainment team, give the third one to whoever’s on-call at cutover, laminated if necessary.

One last thing

Remediation is boring, high-leverage work. It’s also where junior ABAP developers become senior ABAP developers, because there’s no way to do it well without genuinely understanding both classical and modern ABAP.

If you’re staffing one of these, make sure your team knows they’re doing career-making work, not busywork. If you’re on one of these, you are.

Related: our take on ABAP to S/4HANA — a practical migration playbook and on S/4HANA or SuccessFactors first?.

If your team is about to start remediation and you’d like a second pair of eyes on scope, we’re happy to help.