SAP ABAP S/4HANA Migration Interview Questions: Custom Code, ATC and Clean Core

SAP ABAP INTERVIEW PREPARATION SERIES • PART 13

This interview-focused guide explains how an ABAP developer prepares custom code for an SAP S/4HANA conversion. You will learn the end-to-end workflow, the purpose of the Simplification Database, ATC migration checks, usage analysis, remediation patterns, testing strategy, clean-core decisions, and the answers expected in real project interviews.

Learning outcome: Explain a practical S/4HANA custom-code migration approach, interpret ATC findings, separate mandatory adaptation from optional optimization, and defend a clean-core remediation decision.

1. What changes for custom ABAP in S/4HANA?

SAP S/4HANA simplifies the data model, replaces or removes selected transactions and APIs, and introduces new extensibility rules. Existing custom code does not automatically become wrong, but every dependency on simplified SAP objects must be evaluated. The developer's job is to identify used custom objects, find incompatible references, adapt the code, and prove that business behaviour remains correct.

2. The interview-ready migration workflow

1. Define scope: identify custom namespaces, add-ons, interfaces and business-critical processes.
2. Collect usage: distinguish actively used code from dead or obsolete objects.
3. Run readiness and ATC checks: use an appropriate central check system and the target S/4HANA simplification information.
4. Classify findings: syntax error, incompatible API, data-model change, performance opportunity or false-positive/approved exemption.
5. Remediate: replace unreleased or obsolete objects, redesign reads and remove duplicate persistence.
6. Test: run unit, integration, authorization, regression and performance tests.
7. Govern: prevent new violations with ATC quality gates and clean-core rules.

3. Simplification Database vs Simplification Item Catalog

A simplification item describes a product change with possible technical or functional impact. For custom-code analysis, the system uses simplification information to detect references to affected objects. A finding is a starting point—not proof that the business process is broken. Read the referenced note or item, understand the successor design, and inspect the actual execution path.

4. Why ATC is central to the project

ABAP Test Cockpit performs static checks across repository objects. In an S/4HANA project, remote ATC can analyse an older checked system using current check logic and target-release simplification content on a central system. Findings provide object, source position, priority and remediation context.

Migration triage example




Priority 1 -> Syntax error or removed object: fix before conversion

Priority 2 -> Behaviour/security risk: analyse and remediate

Priority 3 -> Performance/maintainability: plan with evidence

Exemption -> Only with owner, reason, scope and expiry date

5. High-value remediation patterns

Replace direct access to simplified tables

Do not reproduce the old data model in custom code. Prefer released CDS views, APIs or business objects recommended for the target release. Validate semantics, authorization behaviour, currency/unit handling and cardinality.

"Illustrative pattern — confirm the released entity in your system

SELECT FROM i_businesspartner

  FIELDS businesspartner,

         businesspartnername

  WHERE businesspartner = @customer_id

  INTO @DATA(partner)

  UP TO 1 ROWS.

ENDSELECT.

Remove SELECT * and database access inside loops

Select required columns, filter at the database and use a set-oriented query when it preserves the business rule. Measure with an SQL trace instead of assuming every legacy statement is slow.

Replace obsolete APIs

An API replacement is not a text substitution. Compare input/output contracts, commits, messages, locks, authorizations and error handling. In ABAP Cloud scenarios, use only APIs released for the configured language version.

6. Data-model questions interviewers ask

• Why can a program compile but still be wrong? The underlying semantics may have changed even when a compatibility view preserves the old name.
• Should every compatibility view be replaced immediately? Follow SAP guidance for the target release and business risk; prioritize mandatory adaptations and planned clean-core modernization.
• Why is SELECT * risky? It couples the program to unnecessary fields, increases transfer volume and hides the actual contract.
• What must be checked after changing a join? Cardinality, duplicates, null handling, authorization, client semantics and performance.

7. Usage analysis and deletion candidates

Usage information helps focus remediation on executed code. It does not by itself authorize deletion. Confirm ownership, seasonal processing, background jobs, interfaces, emergency procedures and legal retention needs. Retire code through the project's controlled decommissioning process.

8. Testing strategy after adaptation

Level	What to prove
ABAP Unit	Calculation and mapping rules remain deterministic
Integration	APIs, updates, locks, messages and interfaces still cooperate
Regression	Critical business processes produce expected results
Performance	Trace evidence shows acceptable database and ABAP runtime
Security	Authorizations and data exposure remain correct

9. Clean core decision framework

Before modifying the core, ask whether the requirement can be handled with configuration, released in-app extensibility, a released API/event, a side-by-side extension or a stable enhancement point. Document the chosen extension type, upgrade impact, owner and tests. Clean core is not “no custom code”; it is controlled, upgrade-stable extensibility.

10. Real scenario question

Scenario: ATC reports a direct read of a simplified aggregate table used by 40 reports.

Strong answer: I first confirm which reports are used and which business fields are required. I read the simplification guidance, select the released successor data source, build one tested access abstraction instead of 40 independent fixes, compare results with representative production-like data, measure performance, then migrate consumers in controlled batches. I keep an approved exception only when the successor cannot yet satisfy a documented requirement.

11. Common mistakes

• Running checks without the correct target release or simplification content.
• Fixing only syntax while ignoring changed business semantics.
• Deleting code solely because usage data is incomplete.
• Replacing one obsolete API with another unreleased internal API.
• Using exemptions with no owner or expiry date.
• Combining migration remediation with unrelated feature changes.
• Skipping reconciliation and performance evidence.

12. Hands-on exercise

1. Create a small inventory of five custom objects and assign business owners.
2. Classify sample ATC findings into mandatory, analyse, optimize and exemption.
3. Refactor one direct table read behind a method that uses a released data source available in your system.
4. Add ABAP Unit tests for empty, valid and inconsistent input.
5. Write a one-page remediation decision including rollback and test evidence.

13. Rapid interview revision

Q: What is the Simplification Database?
It contains technical simplification information used to identify custom-code references affected by S/4HANA changes.

Q: Why use a central ATC system?
It can provide current check logic and target-release checks for remotely connected systems.

Q: Is every ATC finding a production defect?
No. It identifies a risk or required analysis; the developer must evaluate reachability, semantics and remediation guidance.

Q: What is the safest remediation sequence?
Scope, usage, check, classify, adapt, test, measure and govern.

Q: What does clean core mean for ABAP?
Use upgrade-stable extension points and released contracts, minimize modifications, and govern unavoidable custom code.

14. Official SAP references

• SAP Help: SAP S/4HANA Conversion and Custom Code
• SAP Custom Code Migration Guide

← Part 12   |   Series Index   |   Part 14 →

Interview tip: Answer migration questions as a risk-controlled workflow. Mention evidence, ownership and testing—not only transaction names.