SAP S/4HANA Migration Checklist 2026: Clean Core, ATC and Custom Code Guide

An SAP S/4HANA migration is not complete when the technical conversion finishes. The real result depends on business readiness, custom-code remediation, integration testing, security, data quality, cutover execution, and a sustainable clean-core operating model.

This 2026 checklist is designed for enterprise architects, ABAP developers, technical leads, and project managers who need a practical sequence from assessment through stabilization.

Executive checklist

Phase	Critical outcome	Evidence
1. Strategy	Migration approach and scope approved	Business case, architecture decision, roadmap
2. Readiness	Technical and functional risks identified	SAP Readiness Check analysis
3. Custom code	Used code classified and remediated	Usage data, ATC results, remediation backlog
4. Clean core	Extension patterns and APIs governed	Three-tier rules, API inventory, ATC gates
5. Data and integration	Data quality and interfaces validated	Reconciliation and interface test results
6. Testing	Business processes proven end to end	Regression, performance, security evidence
7. Cutover	Go-live can be executed and reversed safely	Runbook, rehearsal results, rollback criteria
8. Stabilization	Operations and clean-core governance active	Hypercare dashboard and ownership model

Step 1: Select the migration approach

Start with the business transformation goal, not with a tool. The most common approaches are:

System conversion (brownfield): convert an existing SAP ERP system while retaining much of its configuration and history.
New implementation (greenfield): redesign processes and implement a new SAP S/4HANA system.
Selective data transition: combine selected historical data and processes with a redesigned target landscape.

Document why the selected option fits business transformation, data-retention, downtime, compliance, integration, and change-management requirements. Do not allow “we have always done upgrades this way” to become the architecture decision.

Step 2: Run SAP Readiness Check early

SAP Readiness Check provides a structured view of areas such as simplification items, add-on compatibility, active business functions, sizing, custom-code analysis, integrations, financial data quality, recommended SAP Fiori apps, and planned downtime.

Convert the findings into owned work packages:

Assign every red or high-impact finding to a business or technical owner.
Record the affected process, system, interface, and data domain.
Separate mandatory remediation from optional optimization.
Estimate test scope and business downtime impact.
Track closure evidence, not only status labels.

Step 3: Build a fact-based custom-code inventory

A code count is not a remediation plan. Combine repository inventory with production usage data so the team can distinguish business-critical code from unused objects.

Classify each custom object

Retire: unused or obsolete functionality.
Replace: standard SAP capability or released API now covers the requirement.
Remediate: code is required but has S/4HANA or HANA findings.
Redesign: the process or extension needs a clean-core architecture.
Retain temporarily: a controlled exception with an owner and target retirement date.

SAP's Custom Code Migration tools support analysis for SAP HANA and SAP S/4HANA transitions. Use the Analyze Custom Code/Custom Code Migration capabilities and ATC rather than maintaining a spreadsheet as the only source of truth.

Step 4: Configure ATC as a project quality gate

ABAP Test Cockpit findings should be prioritized by business impact and migration risk. Typical categories include:

References affected by SAP S/4HANA simplifications.
Database access that is incompatible or inefficient on SAP HANA.
Use of unreleased or internal SAP objects.
Security and authorization issues.
Obsolete statements and maintainability problems.

A useful governance rule is: no new priority-one finding, no unexplained exemption, and no transport to the production path without an approved ATC result.

" Example: prefer an explicit field list and a pushed-down filter
SELECT salesorder,
       salesorderitem,
       material,
       netamount,
       transactioncurrency
  FROM i_salesorderitem
  WHERE salesorder = @sales_order
  INTO TABLE @DATA(items).

IF items IS INITIAL.
  RAISE EXCEPTION TYPE zcx_order_not_found
    EXPORTING sales_order = sales_order.
ENDIF.

The exact remediation depends on the released data model and API available in the target release. Never replace one unsupported dependency with another merely to silence a check.

Step 5: Establish the clean-core architecture

Clean core means keeping the ERP system as close to standard as practical while using stable, supported extension points. It is a governance model, not a promise that all custom development disappears.

Use the ABAP Cloud three-tier model

Tier 1 — released APIs: preferred. Develop with ABAP Cloud and released SAP APIs or extension points.
Tier 2 — controlled wrappers: isolate a required classic dependency behind a stable custom interface when no released API is available.
Tier 3 — classic ABAP: use only when required, with clear governance, ATC checks, ownership, and a modernization plan.

Architecture decision questions

Can standard configuration meet the requirement?
Is a released local API or extension point available?
Should the extension run on-stack or side-by-side on SAP BTP?
What is the lifecycle and upgrade impact?
How will the interface be tested and monitored?
Who owns the exception if an internal dependency is unavoidable?

Step 6: Prepare data, business partners, and finance

Migration defects are often data defects exposed late. Build reconciliation rules before mock conversions. Areas commonly requiring focused ownership include:

Customer/vendor integration and Business Partner conversion.
Material, customer, vendor, and chart-of-accounts quality.
Universal Journal implications and financial reconciliation.
Open transactions, historical data, and retention requirements.
Duplicate, obsolete, or inconsistent master data.

For every migrated object, define record counts, financial totals, exception tolerances, and an accountable business approver.

Step 7: Inventory every integration

Create a catalog of synchronous and asynchronous interfaces, including IDocs, RFCs, BAPIs, OData services, APIs, files, middleware flows, events, and external applications.

For each interface record:

Business owner and technical owner.
Direction, volume, frequency, and service level.
Authentication, certificates, endpoints, and firewall dependencies.
Changed fields, data types, codes, and error behavior.
Test case, test data, monitoring method, and rollback plan.

Step 8: Design an end-to-end test strategy

Unit tests and technical conversion checks are necessary but not sufficient. The test portfolio should include:

Business-process regression across organizational boundaries.
Interface and batch-schedule testing.
Role and authorization validation.
Performance and volume tests using representative workloads.
Financial and data reconciliation.
Fiori launchpad, device, browser, printing, and output checks.
Disaster recovery and operational monitoring exercises.

Automate stable, repeatable scenarios. Keep exploratory testing for changed processes and high-risk exceptions.

Step 9: Rehearse cutover like a production event

A credible cutover plan contains exact tasks, dependencies, start and finish criteria, named owners, communication paths, and evidence requirements.

Minimum cutover controls

Confirmed business freeze and final data-extraction timing.
Measured conversion and migration durations from rehearsals.
Clear go/no-go checkpoints with decision owners.
Rollback criteria and a technically achievable fallback plan.
Reconciliation completed before releasing users.
Command-center contacts across SAP, infrastructure, integration, security, and business teams.

Step 10: Stabilize and keep the core clean

Hypercare should transition into a permanent operating model. Track incident trends, performance, failed interfaces, background jobs, security findings, adoption, and business outcomes.

Clean-core governance after go-live should include:

Architecture review for every new extension.
Released-API and extension-point checks.
ATC gates in the transport process.
Exception records with owners and expiry dates.
Periodic unused-code and modification reviews.
A roadmap to move tier-3 dependencies toward better-supported patterns.

Common migration mistakes

Starting remediation before collecting usage data.
Treating every ATC finding as equal instead of prioritizing business risk.
Assuming technical conversion equals business readiness.
Testing individual transactions but not end-to-end processes.
Discovering integration owners during cutover week.
Calling a design “clean core” without checking released APIs and upgrade impact.
Using permanent exemptions for temporary project pressure.

Project interview questions

How would you decide whether to retire, remediate, or redesign a custom program?
How do SAP Readiness Check and ATC serve different purposes?
What evidence shows that an extension is clean-core compliant?
How would you handle an unreleased SAP object when no released API meets the requirement?
Which reconciliation controls are required before go-live?
What would make you recommend a no-go decision during cutover?
How do you prevent the new system from accumulating the same technical debt?

Frequently asked questions

Does clean core mean zero custom code?

No. It means using standard capabilities where practical and building extensions through stable, supported patterns with clear lifecycle governance.

Should all unused code be deleted before conversion?

Unused code should be reviewed and retired through controlled change management. Usage data, business ownership, legal retention, and rollback needs must be considered before deletion.

Can ATC automatically fix every S/4HANA issue?

No. ATC identifies findings and may offer guidance or quick fixes for some cases. Business semantics, target APIs, performance, and regression impact still require engineering judgment and testing.

When should side-by-side extensibility be used?

It is useful for loosely coupled extensions, independent scalability, external user groups, multi-system integration, or applications that should have a lifecycle separate from the ERP core.

Official SAP references

Final recommendation: keep one integrated backlog that connects readiness findings, custom-code work, business testing, cutover tasks, and clean-core decisions. Migration success depends on traceability from risk to owner to tested evidence.