Contents
SAP is ending mainstream maintenance for ECC in 2027. This deadline means much more than the closure of an era: every organisation remaining on ECC will lose access to SAP's future innovations — artificial intelligence, embedded analytics, Joule. Migration to S/4HANA is no longer optional; it is a scheduled necessity.
But entering this migration with the expectation of a "simple upgrade" is the most common — and most expensive — mistake. In this guide, drawing on 10+ years of field experience, I walk through the 5 critical phases, explain what happens when a phase is skipped, and show what a well-executed migration looks like.
Why S/4HANA? The Real Motivation
Most organisations frame the S/4HANA move around the end-of-maintenance deadline. That is accurate but insufficient as the sole motivation. Organisations that start the project purely out of deadline anxiety typically do the following: they lift and shift their existing ECC processes unchanged (brownfield), carrying years of accumulated technical debt into the new system.
The real motivators should be:
- Embedded Analytics: Real-time reporting directly on ACDOCA and MATDOC — no separate BW/BI system required.
- Fiori UX: Modern, role-based interfaces users can comfortably operate from mobile devices in the field.
- Simplified Data Model: The removal of aggregate tables delivers a performance boost — but it demands a rethinking of your reporting logic.
- Joule & AI: SAP's future AI layer will run exclusively on S/4HANA.
Realising these benefits requires a clear migration strategy defined at the outset.
Phase 1 — Preparation & Feasibility
The most critical step before the project starts: run the SAP Readiness Check report. This tool scans your live ECC system and gives you answers to the following questions:
- How many custom programmes are affected by changes in the Simplification List?
- Which SAP add-ons or partner products are not yet S/4HANA-certified?
- Are there incompatibilities within Business Functions or Industry Solutions?
Greenfield or Brownfield?
Brownfield (System Conversion): The existing ECC system is converted directly to S/4HANA. All historical data and customisations are retained. Faster and cheaper, but technical debt travels with you.
Greenfield (New Implementation): A clean S/4HANA installation, with processes redesigned from scratch. Longer and more expensive, but it is a genuine transformation.
My recommendation: If your ECC system is heavily customised and you want to redesign your processes, choose Greenfield. If you need to move urgently due to the maintenance deadline, Brownfield is more pragmatic — but be aware that you will likely double your technical debt in the process.
Phase 2 — Custom Code Analysis & Adaptation
The vast majority of SAP installations include hundreds — sometimes thousands — of "Z" programmes written over the years. Ensuring these programmes are compatible with S/4HANA is typically the longest phase of the migration project and the one that consumes the most resources. Switching to modern ABAP syntax during remediation is the most practical way to reduce technical debt with the same effort.
Step 1 — Dead Code Clean-Up (SCMON)
The first step is to exclude programmes that are no longer executed. Using the ABAP Call Monitor (SCMON), you analyse the execution log of the past 12–18 months. In our experience, 25–40% of an organisation's Z code is never actually used. Including these programmes in the migration scope wastes both time and budget.
Step 2 — ATC S/4HANA Readiness Check
The S/4HANA Readiness Check variant of the ABAP Test Cockpit is executed. It produces findings in three categories:
- Red (Blocker): Must be fixed before go-live. For example, direct access to tables that have been removed (BSIS, BSAS).
- Yellow (Warning): The code runs but carries performance or compatibility risk. For example, SELECT *, large table access without INNER JOIN.
- Blue (Info): Notification about changed behaviour. No immediate fix required.
Step 3 — Remediation
Red and yellow findings are addressed in priority order. The Quick Fix features in Eclipse ADT (ABAP Development Tools) allow bulk corrections to be applied efficiently. For complex table migrations (e.g. MSEG → MATDOC), a separate scope analysis is required: in some cases switching to BAPI/FM calls is safer than direct table access.
Phase 3 — Critical Data Model Changes
The biggest architectural difference in S/4HANA is the data model. To leverage the power of the HANA in-memory database, SAP has eliminated most aggregate tables and consolidated data into single, central tables. Writing new reports without understanding these changes leads to serious performance problems.
Finance: ACDOCA (Universal Journal)
In ECC, accounting data was spread across dozens of tables (BKPF, BSEG, BSIS, BSAS, FAGLFLEXA, GLT0…). With S/4HANA, all of these have been unified under ACDOCA. The result: FI, CO, and Segment Reporting data are all accessible in a single SELECT.
The old tables still exist as Compatibility Views, but these views query ACDOCA underneath — meaning there is no performance benefit. New development must be written directly against ACDOCA (or the CDS Views built on top of it). I cover this topic in detail, with code examples, in my financial reporting with ACDOCA guide.
Logistics: MATDOC (Material Document)
The MKPF and MSEG tables have been replaced by MATDOC. For material movement queries, this change delivers a notable performance improvement in bulk reporting scenarios. SAP's recommendation, however, is to use BAPI_GOODSMVT_* and related function modules rather than direct SELECT statements against MATDOC.
Human Resources: SuccessFactors Integration
The HCM module included with S/4HANA on-premise is functionally frozen. The long-term strategy is integration with — or migration to — SuccessFactors. Payroll and social security integrations (in Turkey: SGK) present particular complexity here and must be planned separately.
Phase 4 — Test Strategy
The most frequently neglected dimension of testing in migration projects is regression testing. "We fixed the custom code and it runs" is not enough; end-to-end business process validation is essential.
Recommended Test Layers
- Unit Testing (ABAP Unit): Unit tests for corrected Z code. Especially for reports migrated to ACDOCA or MATDOC, results should be compared against ECC output.
- Integration Testing: Verification that critical business processes (order → shipment → invoice cycle, for example) run end to end on S/4HANA.
- Performance Testing: Execution plan analysis for high-volume queries using HANA Studio or SAP HANA Cockpit. "It works" and "it works with 100k rows in production" are different statements.
- UAT (User Acceptance Testing): Key users test their own business processes. This step is routinely cut under time pressure and is the single biggest source of post-go-live issues.
Phase 5 — Go-Live & Stabilisation
Go-live week is the most critical period. The most common issues encountered in the field:
- Open-period data: Documents in progress at cut-over (open orders, invoices awaiting approval) require dedicated migration objects.
- Old reports still in use: Users habitually run their familiar Z reports. On S/4HANA these may run slowly or produce incorrect results.
- Insufficient hypercare: A minimum of 4–6 weeks of intensive post-go-live support (hypercare) is essential. The technical team must remain available throughout.
Recommended go-live timing: the start of a financial year or a period of low business activity. Going live during a peak retail season (November–January) carries significant risk.
Conclusion: Are You Ready?
When planned correctly, an S/4HANA migration is both an opportunity to clear technical debt and to modernise business processes. When planned poorly, it means budget overruns, extended timelines, and post-go-live crises.
Regardless of where you are in the journey, the first step is clear: run the SAP Readiness Check and have its results reviewed with technical expertise. Any plan made without this report is based on guesswork.
I have been providing SAP development and technical consulting on S/4HANA projects in retail, manufacturing, and energy sectors for over 10 years. Feel free to reach out if you would like to review your Readiness Check results together or plan your Custom Code analysis.
Get technical consulting for your S/4HANA migration project.
Free Initial Assessment