Analytics Legends The knowledge platform for SAP Analytics
Academy module

Custom Code Refactoring

Custom Code Refactoring classification flow: ATC scan feeds four remediation buckets that converge into a sequenced backlog — architecture diagram for Custom Code Refactoring, Analytics Legends Academy module M073

As of 2026-08-16

Edited by , sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

Custom code refactoring is the hidden scope risk on every S/4 analytics migration. Clients routinely underestimate the refactoring backlog by 2–3× because they conflate 'it works today' with 'it will work after the upgrade'. The ATC scan is the only defensible method to quantify scope before estimation. Three categories dominate refactoring effort: SAPI extractors (3–8 days each), Z-table staging layers (5–15 days), and ABAP transformation routines (2–10 days). Getting these estimates right in the architecture phase prevents emergency rework in the go-live sprint.

What you will learn

  • Execute an ABAP Test Cockpit (ATC) Clean Core compatibility scan on an analytics extraction scope and classify all findings into Critical / High / Medium severity buckets, producing a programme-ready remediation backlog
  • Apply the four-bucket refactoring classification framework (Retire / Keep-as-is / Lift-and-shift to ODP-CDS / Redesign as BTP side-car) to every custom analytics object in a migration inventory
  • Estimate the refactoring effort for the three highest-effort categories (SAPI extractors, Z-table staging layers, BW ABAP transformation routines) — including effort range, assumptions, and risk of non-remediation
  • Produce an architecture decision brief for a custom code refactoring scope: recommended remediation path per object, sequencing logic, go/no-go criteria, and client sign-off requirements

Custom code refactoring is the most consistently underestimated scope item on any S/4HANA or BDC migration programme that touches analytics, because it sits in the gap between two teams who each assume it belongs to the other. The basis and ABAP development team sees it as an architecture decision that should come from the analytics side; the analytics architecture team sees it as implementation detail that belongs to the developers. Left unowned, it surfaces mid-programme as a wave of unplanned change requests, at exactly the point in the timeline when they are most expensive to absorb. Clients routinely carry hundreds of Z-programs, legacy ABAP extractors, and custom BW transformations that were never designed for a CDS-first, ODP-compliant, Clean Core world, and refactoring them is not a task you hand to a developer with a vague instruction to "make it compatible" — it is an architecture decision with real cost, real risk, and real timeline consequences that a consultant needs to actively own.

What custom code refactoring actually means in an analytics context

Prerequisites

  • Intermediate hands-on experience on SAP analytics projects
  • Review core concepts first: C023, C067, C035

Outcomes

  • Run an ATC Clean Core compatibility scan on analytics custom objects and interpret the severity output
  • Classify any custom analytics object into the four-bucket refactoring framework
  • Produce effort estimates for SAPI extractor, Z-table staging layer, and ABAP transformation routine refactoring categories
  • Deliver an architecture decision brief for a refactoring scope that survives programme scrutiny

Full module available to members. The full module adds: the decision framework · the end-to-end scenario walkthrough · the KPI scorecard · the anti-patterns · the code blocks · the knowledge check · the diagrams.

Open in the app →

Next in this track