SAP S/4HANA Data Migration Strategy: Data Scope, Quality, and Legacy System Decommissioning

Explore how data scope, system complexity, and decommissioning decisions shape SAP S/4HANA migration outcomes and long-term data architecture.

An SAP S/4HANA transformation requires organizations to decide not only how data will move to the new environment, but also what happens to the information and systems that remain behind. Even after go-live, organizations may still rely on their former ERP systems to retrieve historical data, produce reports, or support business processes that have not yet been fully transitioned to SAP S/4HANA.

An SAP S/4HANA data migration strategy defines which data will be transferred, how it will be prepared and validated, and how information excluded from the target system will remain accessible. It also establishes the conditions for retiring legacy systems without disrupting business processes or compromising compliance.

Addressing data requirements early helps organizations limit unnecessary data transfers, reduce migration complexity, and avoid maintaining legacy ERP systems longer than required.

Quick answer: An SAP S/4HANA data migration strategy defines which data needs to be cleansed, transferred, archived, or retained outside the target system. These decisions are developed alongside the migration approach and must account for operational requirements, historical reporting, and regulatory obligations. The strategy also establishes how legacy data will remain accessible and when the systems that store it can be safely decommissioned.

Why Do Complex Legacy Landscapes Complicate SAP S/4HANA Data Migration?

Legacy environments often contain dependencies that are not immediately visible in the ERP system itself. Data may be distributed across regional ERP instances, reporting platforms, external applications, and custom integrations, each with its own structures and business rules.

These dependencies create different migration challenges. Duplicate customer and supplier records can complicate Business Partner harmonization, while inconsistent financial data may require additional reconciliation before cutover. Custom interfaces can also depend on legacy tables or data structures that will change in SAP S/4HANA. When data ownership is unclear, resolving these issues becomes more difficult because technical teams cannot independently determine which records or business rules should take precedence.

For example, a manufacturer may rely on a legacy reporting application that retrieves production data directly from custom ERP tables. During the SAP S/4HANA transition, those structures may change, requiring the reporting interface to be redesigned or replaced. Identifying this dependency during landscape assessment allows the project team to include it in the migration plan rather than discovering it after go-live.

Identifying these dependencies early helps define the migration scope, clarify data ownership, and determine which legacy components must be adapted, retained, or decommissioned.

Migration Approach and Its Impact on Data Strategy

Data scope reduction and selective data transition are related but distinct concepts. Scope reduction determines which data and organizational units can be excluded from the target environment, while selective data transition is one of the approaches used to transfer selected business data. Scope decisions apply to brownfield, greenfield, and selective data transition, although each approach offers different levels of flexibility.

The available migration approaches also depend on the target deployment. SAP Cloud ERP supports new implementation, while SAP Cloud ERP Private and SAP S/4HANA on-premises support system conversion, new implementation, and selective data transition, subject to the relevant technical requirements.

Legacy system decommissioning requirements also differ by migration approach. In a standard system conversion, the existing ERP system is converted to SAP S/4HANA rather than retained as a separate legacy application. New implementations and selective data transitions may leave source systems that must be retained temporarily or decommissioned after their dependencies have been resolved.

For organizations with established processes and extensive transaction histories, system conversion offers continuity but provides less flexibility to exclude selected data. New implementation allows greater control over the data entering SAP S/4HANA, although historical reporting may require a separate solution. Selective data transition provides more flexibility to retain relevant history while consolidating or restructuring the landscape, but introduces additional selection and reconciliation requirements.

These differences also affect legacy decommissioning. Organizations need to determine how users will retrieve historical records that remain outside SAP S/4HANA and identify any reporting or operational dependencies that must be resolved before retiring the source system.

Brownfield or Greenfield: Which SAP S/4HANA migration approach fits your business?

Explore the differences between system conversion and new implementation, including their impact on business processes, data migration, and project complexity.

Read the article

How Do You Define the Data Migration Scope for SAP S/4HANA?

Defining the migration scope involves identifying which data the target SAP S/4HANA environment needs for daily operations, financial reporting, and regulatory compliance. The decisions depend on the migration approach, business requirements, and whether historical information must remain available in the new ERP system.

Master data

Customer, supplier, material, and other master records must be assessed for relevance to the target business processes. Organizations need to determine which records remain active, which can be consolidated, and how their attributes and organizational assignments will map to SAP S/4HANA.

For example, subsidiaries may use different supplier identifiers, payment terms, or purchasing assignments for the same business partner. Defining the migration scope requires distinguishing valid organizational differences from redundant records and determining which attributes need to be aligned before migration.

Open transactions and financial balances

Open receivables, payables, sales orders, purchase orders, and financial balances require careful assessment because they directly affect business continuity after cutover.

In a new implementation, selected open transactions and balances are typically migrated as part of the initial data load. However, some partially processed documents or transactions with existing follow-on documents may need to be completed or closed in the source system rather than transferred directly.

The supported scope depends on the available migration objects, the selected migration method, and the processing status of individual transactions.

The scope must therefore distinguish between transactions that can be migrated, those requiring source-system processing, and balances that need to be carried forward. These decisions also establish the requirements for financial reconciliation and cutover planning.

Historical data and closed fiscal years

Historical records require a separate decision about how much information must remain accessible in SAP S/4HANA and how much can be retained elsewhere.

For system conversions, historical transactions generally remain within the converted environment, subject to the applicable data management and transition procedures. New implementations typically exclude closed transactional history from standard initial data loads, while selective data transition can support the transfer of selected historical records.

Finance and compliance teams should define which historical reports must be reproduced, whether transaction-level detail is necessary, and how older records will be retrieved. For example, opening balances can establish the financial position at transition, but they do not replace the transaction-level records needed to investigate historical postings or reproduce detailed audit trails.

These requirements influence both migration complexity and the design of the future retention environment.

Data archiving removes eligible records from active application tables while preserving them in an accessible archive according to applicable business and retention requirements. Legacy system retention addresses a different need: maintaining access to required historical information after the original application has been retired. Neither automatically determines which records will be transferred to SAP S/4HANA.

Potential archiving candidates include completed business documents, closed transactions, and historical application records that are no longer needed for active processing. Their eligibility depends on application-specific archiving rules, document dependencies, retention periods, and legal holds. Records that remain relevant to ongoing transactions or required reporting must be assessed before archiving.

Configuration and organizational structures

Configuration and organizational structures determine how migrated data will be interpreted and processed in the target system.

System conversion largely carries forward the existing configuration, subject to SAP S/4HANA compatibility requirements. New implementation allows organizations to establish new structures and settings, while selective data transition may support targeted organizational and configuration changes.

For example, a group consolidating regional entities may need to revise its company-code structure or reporting assignments. Such decisions affect data mapping, document relationships, and the treatment of historical information.

The scope should reflect the business model the target system will support, rather than reproduce legacy structures without assessment.

A broader migration scope may preserve more existing information but increase the effort required for preparation, validation, and ongoing data management. A narrower scope can reduce the operational data footprint, although it demands clearer decisions about exclusions and future access.

How Does Data Quality Affect SAP S/4HANA Migration Readiness?

Data quality directly affects migration readiness. Incomplete, duplicated, or inconsistent master records can cause data loading errors, disrupt business processes, or require additional corrections during migration testing. The impact depends on the migration approach, the affected business objects, and their role in the target environment.

Master data cleansing typically begins with profiling to identify missing attributes, obsolete records, inconsistent formats, and potential duplicates. Business owners then review overlapping customer, supplier, and material records to determine which should be retained, consolidated, or excluded. Standardization aligns relevant addresses, tax identifiers, units of measure, and classifications with the target data model. These decisions should be documented as transformation and validation rules so they can be applied consistently across migration cycles.

For system conversion, Customer/Vendor Integration (CVI) readiness is a prerequisite. Customer and vendor master records must be synchronized with the Business Partner model before technical conversion. Preparation includes checking mandatory fields, Business Partner assignments, account group mappings, and synchronization errors. Similar requirements may apply to supported selective transition scenarios, depending on the approach and tools used.

Cleansing results should be assessed against agreed quality criteria, including mandatory-field completeness, duplicate resolution, and the successful validation of critical business objects. Migration rehearsals can reveal further issues that require correction. Not every inactive or low-impact record needs the same level of attention, but defects affecting critical processes or data integrity must be resolved before the relevant migration milestone.

Which Tools Support SAP S/4HANA Data Migration?

SAP S/4HANA data migration tools support different activities, including data extraction, transformation, loading, and validation. Their selection depends on the migration approach, source systems, and complexity of the data landscape.

Tool selection also depends on the migration approach. System conversions use SAP Software Update Manager (SUM), with its Database Migration Option (DMO) where applicable. New implementations typically use supported SAP S/4HANA Migration Cockpit methods, while selective data transitions may require specialized data transfer and transformation tools.

SAP S/4HANA Migration Cockpit

SAP S/4HANA Migration Cockpit supports transferring selected business data into SAP S/4HANA using predefined migration objects, primarily in supported new implementation scenarios. Depending on the deployment and migration method, data can be loaded through staging tables or transferred directly from supported SAP source systems. The cockpit does not replace the technical system conversion process.

The cockpit provides capabilities for mapping, simulation, migration execution, and monitoring. In supported SAP S/4HANA on-premises and SAP Cloud ERP Private scenarios, SAP S/4HANA Migration Object Modeler (transaction LTMOM) allows teams to adapt migration objects to specific requirements. SAP Cloud ERP provides the Model Your Migration Objects application, with available functions depending on the migration method and supported migration objects.

Complex source data inconsistencies may still require additional cleansing and transformation before data is loaded into SAP S/4HANA.

SAP's data migration documentation describes the supported approaches, including staging-table migration and direct transfer from SAP source systems.

For direct transfer, SAP S/4HANA Migration Cockpit supports specified source systems. An existing SAP S/4HANA system cannot be used as the source for this migration method.

SAP Data Services

SAP Data Services supports data extraction, integration, cleansing, and transformation across different source systems. It can be used to harmonize data structures, apply reusable transformation rules, and prepare datasets for migration.

For example, when several ERP systems use different material classifications, SAP Data Services can apply approved mappings to produce a consistent target structure. Business teams must still determine which classifications are valid and how exceptions should be handled.

In staging-based migration scenarios, SAP Data Services can also populate the staging tables used by SAP S/4HANA Migration Cockpit.

Reconciliation and validation tools

Automated validation helps identify missing records, duplicate entries, incorrect mappings, and discrepancies between source and target data. Depending on the migration approach, these checks may compare record counts, financial balances, transaction values, or other business-critical attributes.

Automation makes repeated checks more efficient across migration rehearsals, but discrepancies still require investigation and business approval. A matching record count, for instance, does not demonstrate that transferred accounting data produces the correct financial results.

The appropriate toolchain should therefore reflect the selected migration approach and provide traceability from source data through transformation and validation, with clear responsibility for resolving exceptions.

What Are the Main Risks in SAP S/4HANA Data Migration?

SAP S/4HANA data migration risks extend beyond unsuccessful data transfers. Financial discrepancies, undocumented system dependencies, and inconsistent updates across environments can disrupt business processes even when the technical migration succeeds. Identifying these risks during preparation allows teams to establish appropriate controls before cutover.

Financial reconciliation discrepancies

Financial data may contain differences caused by posting timelines, local adjustments, or inconsistent accounting practices across source systems. These discrepancies can affect opening balances, general ledger and subledger reconciliation, and the reliability of financial reporting after migration.

For example, consolidated account balances may appear correct while individual customer or supplier balances do not match. Reconciliation must therefore cover the relevant levels of financial detail, with agreed tolerances and documented procedures for investigating exceptions. Critical discrepancies should be resolved before financial data is accepted for production use.

Undocumented legacy dependencies

Unresolved dependencies can cause reporting failures, interrupted data exchanges, and disruptions to business processes after go-live, even when the data migration itself is successful.

To reduce these risks, teams should validate interface inventories against actual system usage, test critical end-to-end processes, and confirm that affected integrations have been adapted, replaced, or retired. Any dependencies that cannot be resolved before cutover should have documented mitigation measures and accountable owners.

Data divergence during system coexistence

When legacy and SAP S/4HANA environments operate simultaneously, changes to business data can create inconsistencies between systems. This risk is particularly relevant to phased transitions and scenarios involving ongoing data replication or parallel operations.

For example, a supplier's payment details may be updated in one environment but not synchronized with the other, leading to conflicting information across procurement and finance processes.

Organizations should define the authoritative source for each dataset, establish synchronization rules, and monitor exceptions throughout the coexistence period.

Insufficient reconciliation and cutover validation

Successful data loading does not guarantee that the migrated information is accurate or suitable for business use. Undetected discrepancies in financial balances, document relationships, or transaction statuses can disrupt operations and reporting after go-live.

The main risk is approving production cutover based on technical completion rather than validated business results. Organizations should define which unresolved discrepancies prevent go-live, document any accepted exceptions, and require approval from the responsible business owners before proceeding.

How Can Organizations Decommission Legacy SAP Systems After Migration?

Legacy system decommissioning involves retiring applications and infrastructure while preserving access to the business information that must remain available. An SAP S/4HANA go-live does not automatically make the previous ERP environment redundant. Historical reporting, audit requirements, and dependencies on other applications may still require access to legacy data.

Organizations may keep legacy applications temporarily in read-only mode, transfer historical information to a dedicated retention environment, or combine both approaches during a phased transition. The choice depends on reporting and access requirements, remaining system dependencies, and long-term operating costs.

Keeping legacy systems in read-only mode

Read-only access allows authorized users to retrieve historical information without processing new transactions in the legacy system. This can be useful during post-migration stabilization, particularly when finance and compliance teams need to verify historical records or complete outstanding reporting activities.

However, read-only access does not eliminate the cost of maintaining the original environment. Infrastructure, application administration, security updates, and technical support may still be required. Organizations should therefore establish how long this arrangement is needed and what conditions must be met before the system can be retired.

Moving historical data to a retention environment

A dedicated retention environment allows organizations to preserve historical information without maintaining the entire legacy ERP application.

For SAP landscapes, SAP Information Lifecycle Management provides capabilities for managing data retention and supporting legacy system decommissioning. Its ILM Retention Warehouse scenario enables organizations to transfer archived or extracted legacy data, apply retention rules, and retrieve relevant information independently of the original system.

The transition requires careful preparation. Organizations must preserve historical records together with the metadata, document relationships, and configuration context needed to interpret them, establish appropriate access permissions, and validate retrieval procedures before shutting down the source system. Retention periods and legal holds must also be respected, including requirements for deleting information when continued storage is no longer justified.

SAP's ILM Retention Warehouse documentation describes the transfer, retention management, and retrieval processes involved in system decommissioning.

When is a legacy system ready for shutdown?

A legacy SAP system can be retired once its remaining business and technical dependencies have been resolved. Before shutdown, organizations should verify that:

• Required historical records can be retrieved without accessing the original application.
• Financial reporting and audit processes have been validated against the retained information.
• Interfaces, background jobs, and downstream applications no longer depend on the legacy system.
• Retention rules, access controls, and responsibilities for long-term data management are documented and tested.

The decision should be supported by business, IT, and compliance stakeholders rather than based solely on the SAP S/4HANA go-live date.

In complex landscapes, decommissioning may proceed in phases, with individual applications retired as their dependencies are eliminated. This allows organizations to reduce legacy operating costs while maintaining access to information required for ongoing business and regulatory purposes.

How Do You Build an SAP S/4HANA Data Migration Roadmap?

An SAP S/4HANA data migration roadmap connects decisions about data scope, quality, technical execution, and legacy system retirement with specific project milestones. Although activities vary by migration approach, key milestones should have defined deliverables, accountable owners, and agreed acceptance criteria. This allows teams to assess unresolved data issues and system dependencies before progressing to the next stage.

1. Assess the existing landscape and dependencies

Inventory the source systems, business-critical datasets, interfaces, reporting dependencies, and existing data quality issues. Involve business and IT stakeholders to identify undocumented dependencies and confirm how data is currently used.

Deliverable: A validated data inventory and dependency map identifying critical systems, data owners, and areas requiring further investigation.

2. Define the target model and data disposition

Evaluate the migration approach, target data structures, and data disposition requirements together. Agree on which records will be migrated, archived, retained in legacy systems, or excluded according to approved retention rules. Confirm historical reporting requirements with finance, compliance, and other affected business functions.

Deliverable: An approved migration scope and data disposition plan, including the intended treatment of historical information and remaining legacy dependencies.

3. Prepare data and establish validation criteria

Define mapping and transformation rules, establish reconciliation procedures, and set quality thresholds for critical datasets. Assign responsibility for reviewing discrepancies and approving migration results.

Deliverable: Approved data preparation rules, quality thresholds, and validation criteria for migration testing.

4. Complete migration rehearsals and execute cutover

Run migration rehearsals to verify execution times, data completeness, financial reconciliation, and critical business scenarios. Use the results to finalize cutover procedures, confirm contingency arrangements, and authorize production migration. Execute the approved cutover plan and perform the required technical and business checks before releasing the target environment for normal operations.

Deliverable: Approved rehearsal results, completed production cutover, and documented initial validation and handover results.

5. Validate the target environment and prepare legacy system retirement

Confirm that migrated data supports critical business processes, reporting, and integrations after go-live. Resolve outstanding discrepancies, verify historical data access, and assess whether remaining legacy applications meet the agreed shutdown criteria.

Deliverable: Business-approved post-migration validation results and a phased decommissioning plan identifying systems ready for retirement and those requiring further action.

How LeverX Supports SAP S/4HANA Data Migration

LeverX helps organizations plan and execute SAP S/4HANA data migrations across complex SAP and non-SAP landscapes. Our services cover data readiness assessments, migration scope definition, master data harmonization, data transformation, reconciliation, and post-migration validation.

For organizations consolidating multiple ERP systems, LeverX supports the alignment of data structures, the resolution of conflicting master records, and the development of migration rules that account for local business and regulatory requirements. We also help plan selective data transitions and address legacy dependencies that could affect reporting, integrations, or future system decommissioning.

To support migration execution, LeverX uses its proprietary Data Management Platform alongside SAP tools. The platform supports data extraction from SAP and non-SAP sources, automated profiling and cleansing, mapping, transformation, and validation. Reusable connectors and transformation workflows help prepare consistent datasets for subsequent migration steps and reduce manual effort across test cycles.

LeverX experience: Eurasia Group

In an SAP S/4HANA migration project for Eurasia Group, LeverX reviewed outdated business processes and existing custom code, contributing to a 15% improvement in data consistency. The project also reduced system maintenance costs by 10%.

LeverX also supports cutover and post-go-live stabilization, including data reconciliation, exception resolution, and validation of business-critical processes.

Conclusion

An SAP S/4HANA data migration strategy should establish what moves to the target environment, how data integrity will be validated, and where historical information will remain accessible. These decisions also determine when legacy applications can be retired without disrupting business operations.

Contact LeverX to assess your current landscape and define a migration strategy aligned with your business requirements.

FAQ