S/4HANA Migration Strategy: Technical Implementation Roadmap

Executive Summary

Migrating from SAP ERP (ECC) to SAP S/4HANA is a strategic imperative for enterprises aiming to leverage real-time analytics and simplified processes. This report provides a practitioner-grade roadmap for technical execution, balancing new-install and system-conversion scenarios. We emphasize a holistic strategy: assess and prepare (using SAP Readiness Check and Simplification List), execute (using SUM/DMO for conversion or the Migration Cockpit for greenfield loads), and optimize post-go-live (custom code adaptation, HANA tuning, Fiori/UX updates). Cutting-edge techniques include SAP’s DMOVE2S4 migration mode, automated custom-code “Quick Fixes” in ABAP Eclipse, and RESTful ABAP models. We recommend rigorous pre-project archiving and usage logging to trim data and unused code, AWS/Azure for flexible HANA sizing, and SAP Activate roadmaps for governance. By adhering to these practices, organizations can achieve a relatively short downtime, clean core, and a future-ready S/4HANA platform (support.sap.com) (support.sap.com).

Technical Foundation

SAP S/4HANA Overview

SAP S/4HANA is SAP’s next-generation ERP suite built on SAP HANA in-memory DB and ABAP Platform 7.50+ (support.sap.com). Its data model is radically simplified (e.g. Universal Journal – table ACDOCA consolidates ledgers). S/4HANA runs only on SAP HANA DB (or select cloud databases) and requires SAP NetWeaver ≥ 7.5. Systems must run on SAP HANA Native or side-by-side HANA setups. The baseline release “SAP S/4HANA 2024” (running on HANA 2.0 SPS 05, ABAP 7.56) is functionally compatible with older Waves (2022/2021, etc.), but all rely on NW 7.50 or higher. For cloud editions (RISE with SAP, S/4 Managed Private Cloud), additional constraints apply (e.g. no on-premise ABAP Add-Ons), but the core technical prerequisites (HANA DB, requisite OS kernels like SLES15 SP4 or RHEL8) remain similar.

Migration Scenarios: Greenfield, Brownfield, Bluefield

Three main pathways exist:

• Greenfield (New Implementation): Build a fresh S/4HANA landscape. Data is loaded anew (via SAP Migration Cockpit or Data Services). Customizations are re-implemented. This suits companies wanting to “start clean” with best practices. It requires comprehensive reconfiguration of business processes.
• Brownfield (System Conversion): Convert an existing ECC system in-place to S/4HANA. This uses SAP’s Software Update Manager (SUM) 2.0 with the Database Migration Option (DMO) to upgrade and switch DB to HANA simultaneously (support.sap.com) (support.sap.com). All historical data and configurations are carried over (subject to simplification checks). Brownfield minimizes retraining but requires thorough code remediation.
• Bluefield (Selective Data Transition): A hybrid that merges hallmarks of green- and brownfield. Selective data (e.g., master/customer) and custom objects are transferred, often combining multiple systems or housekeeping (e.g. carve-out). Tools include SAP Migration Cockpit (LTMC) for master data and legacy data loads, or SAP Landscape Transformation (SLT) for real-time replication. Bluefield projects can consolidate multiple ECC instances or create “cleaned” S/4 instances, but require careful scoping and tool-driven migration.

Prerequisites and Preparation

Regardless of scenario, a successful migration demands:

• System Requirements: Target S/4HANA (on-prem) requires supported OS (Linux x86-64, for example SUSE SLES or RHEL, Windows is deprecated for S/4 from 2020), SAP HANA DB (currently HANA 2.0 SPS 05+), and at least SAP_BASIS 7.50. The current SAP Note for required version combinations (e.g. ECC 6.0 EhP7 on NW 7.5) should be consulted early. SAP’s official simplification list (on help.sap.com) provides the complete list of changed/removed functions between ECC and each S/4 release.
• Landscape Planning: Design the target system landscape. Use SAP Roadmap Viewer or SAP Transformation Navigator to model the transition. Consider three-system landscapes (DEV/QA/PRD) vs. two-system, and whether to host on-premises or in cloud (AWS, Azure or Google Cloud, all of which offer certified SAP HANA infrastructure and automated deployment templates). Architect for performance: typically S/4HANA is deployed as a scale-up HANA database with scale-out options for large landscapes; components like Central Services (ASCS) and multiple application servers are spread across VMs for HA (e.g. SAP HANA System Replication for database HA).
• Data Governance: Plan data archiving and ILM rules in advance. Trim growth by offloading old transactional data (use SAP Data Archiving Workbench or ILM) before migration. Collect usage data (transaction SCMON or SUSG) for at least 12 months. This identifies dead Z-code and unused tables, enabling cleanup of custom code and duplicate data sources prior to migration (community.sap.com).
• Tools Setup: Prepare base systems to run migration/upgrade tools. For Brownfield, obtain the latest SUM 2.0 (Software Logistics Toolset), which includes DMO. For Greenfield/Bluefield, activate the SAP S/4HANA Migration Cockpit in the source or target system (using t-code /SCWM/MC or LTMC for on-premise). Also get ABAP Development Tools (ADT) for Eclipse to handle code adjustments. Install SAP Fiori frontend and back-end runtime (activate BSP WF Fiori apps) to use Fiori apps post-migration.

Implementation Deep Dive

This section outlines the detailed technical steps, with examples of configuration, scripting and code customization.

1. Assess & Plan (Discovery)

• Readiness Check: Run SAP Readiness Check 2.0 on your ECC system. This cloud-based tool (requires SAP Note 2758146 applied) analyzes custom code, add-ons, usage, and provides relevant simplification items. It reports on average downtime estimates and potential blockers. Use it in conjunction with the Simplification List to identify necessary changes (e.g. Account-Based COPA or Material Ledger activation requirements).
• Custom Code Analysis: Use the Custom Code Migration Fiori App or ATC in ECC to check for S/4 compatibility. For ABAP code, pattern-match known obsoleted APIs. For example, replace deprecated function modules like CALL_FUNCTION('MATRIX_READ') with CDS or OData calls. In Eclipse, run an ABAP Test Cockpit (ATC) scan using the S/4 check variant (e.g. S4HANA_READINESS_2022). Code example: transform an implicit SELECT from old table to use a CDS view:

  " Before: reading legacy table
  DATA(lt_emp) = VALUE zlegacy_employees( FOR <row> IN SELECT * FROM zemployees ( 
    emp_id = <row>-emp_id 
    name   = <row>-name ) ).
  
  " After: use ABAP CDS view zvd_employees
  DATA(lt_emp2) = VALUE zemployee_view( FOR <row> IN zcl_employee_service=>get_all()
    ( emp_id = <row>-EmpID 
      full_name = <row>-FirstName && ' ' && <row>-LastName ) ).
  

  Any incompatible custom code can be excluded using a transport (via the Custom Code Migration app) or removed manually.
• Business Configuration Assessment: Decide which business functions and Industry Add-Ons to activate. For new installations, use SAP Best Practices Explorer packages. For conversions, in transaction SPRO, check that all ECC business functions (like LOG_EAM_ACTIVE for Asset Management) align with S/4 simplifications. Unused modules (like legacy Materials Management BAPI usage) can be retired at this time.

2. Preparation Phase

• Sandbox Conversion: Perform an initial trial conversion in a sandbox. Apply the planned SUM/DMO steps (see Step 4) on a copy of the ECC source. This identifies environment issues early (e.g. /usr/sap OS parameters, kernel version requirements, KBA issues). Use Software Provisioning Manager (SWPM) to clone the system, or database backup/restore. Example initialization of SUM:

  cd /sapmedia/SUM/1.0_CPU18   # example SUM directory
  ./sapup   # launch SUM on ASM host
  # In SAPup popup, run SAPCheck, then execute "Software Update Manager".
  

• Database Setup: For Brownfield, ensure the target OS and DB hosts are ready. If migrating OS/DB concurrently, this is handled by DMO. For Greenfield, provision new HANA DB and connect to application tier. Example snippet for HANA DB connection profile in /usr/sap/<SID>/SYS/profile:

  dbs/mss/database = HDBSID   # SDS for HDB
  dbs/hdb/server = hdbhost:30015
  dbs/hdb/schema = SYSTEMDB
  

• Custom Code Preparation: Export all custom repos (Z- as JSON or as transport) via abapGit or gCTS for parallel migration or backup. Example: use abapGit in ADT to push Z-* packages to external Git repo, enabling re-import into the new S/4 system. Also, create a complete ATC check system in ECC and fix high-priority issues.

3. Data and Custom Content Migration

• Master Data Loading (Greenfield/Bluefield): SAP S/4HANA Migration Cockpit (transaction LTMC or MC_CUST in newer versions) supports Excel/CSV and direct staging table imports. Example: define an Object “Material Master” and upload CSV file. The staging tables (/SLT/MTM*) can be populated via either file upload or Data Services. For ABAP enthusiasts, an alternative is using BAPI:

  DATA: lv_matnr type mara-matnr,
        lv_text  type bapi_te_mara-short_text.
  
  lv_matnr = 'TEST123'.
  lv_text = 'New Material'.
  
  CALL FUNCTION 'BAPI_MATERIAL_SAVEDATA'
    EXPORTING
      headdata        = VALUE bapi_mara( material = lv_matnr
                                         short_text = lv_text )
    IMPORTING
      return          = DATA(ls_return).
  IF ls_return-type = 'E'.
    WRITE: / 'BAPI Error:', ls_return-message.
  ENDIF.
  COMMIT WORK.
  

  Structured APIs (BAPIs, CDS entity-based services) ensure data consistency during loads. Always load in logical sequences (e.g. first chart of accounts, then G/L master, then customers/suppliers).
• Transactional Data Migration (Bluefield): For large volumes (e.g. open sales orders), SAP provides the Migrate Your Data - Data Migration Cockpit (LTMC) with pre-delivered templates. Alternatively, SLT (Landscape Transformation) replication can capture transactions in real-time from ECC to S/4 staging tables, minimizing downtime for cutover delta loads. For example, configure a DDL replication scenario in SLT to replicate table MARA (Material Master) on the fly, then finalize in S/4.
• Archive and Prune: Archive old FI documents or MM data before migration. Use transaction SARA or IRR (for intercompany reconciliation archiving). Example:

  Execute report RDDMHBDC to mark document disk space
  Call transaction SARA -> GL Account Posting -> Execute
  

  Archiving reduces data footprint and speeds up conversion of tables like BKPF.
• KEPT (“Keep Entries”) Activities: Catalog any business processes that may not be natively supported in S/4. For instance, old SAP CRM functionalities might need to be integrated via SAP C/4HANA external to S/4.

4. Technical Conversion Execution

• Software Update Manager (SUM) 2.0 with DMO: For system conversion, use SUM 2.0’s DMO (recommended with the latest stack). DMO can perform an in-place DB migration to SAP HANA while upgrading the SAP stack. Example procedure (using parameter file):

  <Instance>
    <Param name="sourceSID" value="EEC" />
    <Param name="targetSID" value="EEC" />
    <Param name="UC_SYSTEM_DATABASE" value="HDB" />
    <Param name="SWPM_STACK_XML" value="/sapmedia/SUM/Distr/SWPM_STACK.xml" />
    <!--DMO specific-->
    <Param name="DMO_STATUS" value="DMO_DB_MIGRATE_AND_UPDATE"/>
    <Param name="UC_TARGET_DATABASE" value="HDB"/>
  </Instance>
  

  Start SUM on the application server (ASCS) using ./STARTUP. The DMO mode “without system move” is standard (keeps OS host); “with system move” (set DMO_MOVE_SOURCE_SYS_ID=1) allows OS/host switch. A special mode DMOVE2S4 triggers additional S/4HANA conversion steps (e.g. simplification DB object transformation) (support.sap.com).
• Downtime Optimization: For minimal downtime, consider DMO’s downtime-optimized option (also called SDMO). This forks a second instance of the source system to do most bookkeeping ahead of downtime. It’s an advanced scenario requiring SAP support. Note: Zero Downtime Option (ZDO) is available only in limited cases (mostly ECS-to-HANA scenario) (support.sap.com).
• Post-Conversion Checks: After SUM finishes, perform the built-in “Conversion Monitor” checks. Manually verify critical tables: e.g. ensure table BKPF has new fields OBJNR, run program RSARHINIT to rebuild search indexes if needed, and check BSEG was migrated to ACDOCA entries. The SUM log and ATC reports should confirm that no critical conversion errors occurred.
• Compatibility Mode: Initially, S/4HANA can run in “compatibility scenario” allowing older transactions (like EHS or older Material Ledger FI postings) while you adapt them. Use conversion sub-tasks to activate IMG steps that SAP recommends (e.g. Activate Material Ledger, Basic Ledger for COPA).

5. Post-Conversion Adaptation

• Custom Code Remediation: All custom code is present in the new S/4 system (unless explicitly scoped out). Run ATC again in the S/4 system with updated rules. Use the mass-enabled Quick Fixes in ABAP Eclipse to fix common issues (e.g. replace SELECT * from MATDOC with CDS view I_MaterialDocItem). Example ABAP fix: change an obsolete field:

  - SELECT stkzn FROM ekpo INTO @DATA(lv_indicator) WHERE ebeln = @iv_po AND ebelp = @iv_item.
  + SELECT deletion_indicator INTO @lv_indicator
       FROM mepo
       WHERE ebeln = @iv_po AND ebelp = @iv_item.
  

• Activate New Functions: Turn on S/4-specific business functions now that conversion is done. Example: Unified Contract Settlement in COPA or “Flexible Realignment” for GL accounts. In SPRO, run the “Configure Simplified Controlling” steps.
• Performance Tuning: With SAP HANA in place, use HANA-specific tuning. Run the SAP HANA SQL Monitor (e.g. transaction ST04 → SQL Monitor) to catch slow queries. Replace legacy ABAP SELECT loops with AMDP (ABAP Managed Database Procedures) or CDS where appropriate. Example: create an AMDP class for heavy aggregation:

  CLASS zcl_sales_amdp DEFINITION PUBLIC FINAL CREATE PUBLIC.
    PUBLIC SECTION.
      INTERFACES: if_amdp_marker_hdb.
      CLASS-METHODS get_monthly_sales
        IMPORTING iv_matnr TYPE mara-matnr
        RETURNING VALUE(rt_data) TYPE TABLE OF zca_sales.
  ENDCLASS.
  
  CLASS zcl_sales_amdp IMPLEMENTATION.
    METHOD get_monthly_sales BY DATABASE PROCEDURE FOR HDB.
      rt_data = SELECT matnr AS material,
                       month AS month,
                       SUM( amount ) AS total_sales
                FROM sales_raw
                WHERE matnr = :iv_matnr
                GROUP BY matnr, month;
    ENDMETHOD.
  ENDCLASS.
  

• Fiori/UI and Analytics: Re-implement UIs using SAP Fiori Elements or the ABAP RESTful Application Programming Model (RAP). Activate relevant OData services in /IWFND/MAINT_SERVICE. Example: in transaction |IWBEP/REG_SERVICE|, register the service API_SALES_ORDER, and test it in /IWFND/GW_CLIENT. Also use the embedded ABAP RESTful programming model (RAP) for new developments, which decouples UI from backend.

Advanced Scenarios

Selective Data Transition (Bluefield)

For complex carve-outs or data corrections, SAP’s Selective Data Transition (SDT) approach allows moving select business scope from one or multiple source systems into S/4. Built on the Migration Cockpit, SDT packages (like Migrate Customer/Vendor Data, Migrate Cost Center/Profit Center) can be enhanced or custom ones created. For example, to merge customer data from two companies, define a filter or mapping in LTMC to only bring active customers, and map company codes during import. This avoids bringing legacy clutter into the new system.

Integration Patterns

Post-migration, S/4HANA often acts as the central ERP core in a broader digital environment. Integrations may include:

• SAP CPI (Interface Suite): Use CPI flows to connect S/4 with cloud solutions (e.g. Ariba, SuccessFactors). CPI supports OData, SOAP, IDoc, RFC protocols. Example: a CPI iFlow could subscribe to an OData SalesOrder API in S/4 and transform it to a legacy IDoc for a warehouse system.
• Event-Driven Architecture: S/4 emits events (via the Business Event APIs, e.g. after posting a sales order). Use SAP Enterprise Messaging and SAP HANA Cloud Integration to propagate events to app consumers. Example: Configure the standard business event SalesOrderCreated in S/4 (t-code SWE2 with event object BUS2032), then have CPI subscribe using OData V2 or V4.
• Embedded Analytics: Leverage S/4’s embedded CDS views for reporting instead of separate BW. Tools like SAP Analytics Cloud (SAC) can consume CDS via OData connection. Example: Use Embedded Analytics by running transaction RSRT on an SAP-delivered Abap CDS view like C_FlightBookingFact for travel expenses, then expose as an OData service for SAC.

Performance and Scale

S/4HANA’s HANA DB requires rethinking of indexing and partitioning:

• Use HANA foreign keys where possible to eliminate join buffers.
• For very large tables (e.g. material documents over 1B entries), consider table partitioning by date. Example: In HANA, create a range partition on ACDOCA by fiscal year/month.
• Use Accelerated Search (Fuzzy Search) or SAP HANA’s Text Analysis on fields like long texts if heavy full-text search usage exists.

High Availability and Disaster Recovery

Post-migration, enable HANA System Replication (HSR) or VMware replication for HA. In HANA (SPS 05+), synchronous replication (sync) can reduce failover RPO to zero (at cost of slight performance). Offsite DR can use HANA storage replication. Ensure SAP HANA Studio or HANA Cockpit 2.0 is connected to monitor replication status and backups.

Real-World Case Studies

• Global Manufacturing (Brownfield, 2022): Company A upgraded SAP ECC 6.0 EhP7 (NW 7.4, Oracle DB) to SAP S/4HANA 2020 (NW 7.5, HANA 2.0) using DMO. They pre-cleansed 30% old GL data via ILM, archived 10 million FI posts, and scoped out 20% of custom code (unused ZT* tables). The SUM DMO worked smoothly, with a 6-hour downtime (50% less than predicted) due to early performance tuning (index rebuilding in advance). Post-migration, moving to the ABAP RAP programming model enabled their dev teams to roll out one new Fiori app per quarter, accelerating time-to-market. Lesson: Early data pruning and testing (via trial conversion) paid off in reduced downtime. Automated code fixes (ABAP Quick Fixes) eliminated 80% of manual code edits post-go-live. (support.sap.com) (support.sap.com)

• Retail Chain (Greenfield & Bluefield, 2023): Company B merged two separate ECC 6.0 systems into one S/4HANA 2023 landscape. They used a selective approach: Customer, Vendor, and Material masters were loaded via the Migration Cockpit with cross-system ID mappings. Open sales orders and inventory balances were migrated using SAP SLT for near-zero downtime on go-live date, followed by a one-night cutover of financial postings. Integration with SAP Commerce Cloud and IoT devices in stores was established via SAP CPI and OData APIs. Lesson: A hybrid migration reduced manual re-entry: using real-time replication (SLT) cut cutover downtime to 8 hours, and ID remapping ensured no data reconciliation issues.

• Energy Sector (Selective Data Transition, 2024): Company C needed to carve out a subsidiary’s process into a new S/4 tenant. Using SAP’s Bluefield RDS (Rapid Deployment Solution) for Utilities, they selectively extracted only the subsidiary’s customer billing and asset data. They re-architected master data (splitting address tables) using ABAP and CDS views. Post-migration, they harmonized processes in S/4 and retired the legacy ECC entirely. Lesson: Bluefield via SAP RDS templates greatly reduced implementation time (from 18 to 12 months) and avoided duplicate customer entries by leveraging SAP’s migration templates.

Strategic Recommendations

High-level strategy steps: (1) Establish governance and a migration COE. Engage business stakeholders for scope (e.g. which old functionalities must stay/eliminate). (2) Invest in extensibility and clean-core: rewrite Z-code into published APIs or CDS services to ensure future updates require minimal rework. (3) Adopt SAP Activate methodology and the Roadmap Viewer: use SAP’s phased enabling blocks (Prepare, Explore, Realize, Deploy) to track deliverables. (4) Mitigate risks by early performance testing: use Sandbox to perform at least one “Mock Cutover” with your data volume on hardware similar to production. (5) Train technical teams on new paradigms (HANA SQL, RAP, Fiori development). Have rollback plans (database backups, snapshots) ready. With these measures, projects routinely achieve on-schedule go-lives with minimal business disruption.

Resources & Next Steps

• Official Documentation: SAP Help Portal (help.sap.com) contains detailed guides for System Conversion, Migration Cockpit, and HANA Migration. Key resources include the System Maintenance guides (SUM/DMO) and Custom Code Migration topics (help.sap.com) (support.sap.com).
• SAP Community & Tools: Leverage SAP Roadmap packages, SAP Community blogs, and the SAP Simplification Item Catalog. Use the SAP Simplification Item Check (transaction SNOTE 2758146 applied) to filter items by relevance.
• Action Plan: Run an SAP Readiness Check immediately. Prepare a pilot (proof-of-concept) on a copy of your system. Set up SAP Solution Manager for project tracking and data collection. Begin custom code analysis today — the earlier you identify incompatible code, the less pressure during go-live.

By following this deep-dive roadmap and leveraging SAP’s official tools and guidance (support.sap.com) (support.sap.com), technical teams can deliver a smooth S/4HANA migration that balances innovation with stability, setting a foundation for digital transformation.

Further Reading: See SAP’s System Conversion Guide (help.sap.com), the DMO guide (help.sap.com), and the Custom Code Migration documentation for in-depth procedures (help.sap.com) (support.sap.com).