SAP ECC to S/4HANA: What Data Should Be Migrated?

Author: Satya Prasad, Senior SAP ILM Delivery Lead at TJC Group

Moving every record from SAP ECC to S/4HANA can increase HANA sizing requirements, migration effort, and long-term operating costs. A structured data assessment helps organisations decide what should be migrated, archived, deleted, or retained outside the core ERP. This article explains how those decisions can create a leaner S/4HANA environment while preserving the historical information needed for compliance, reporting, analytics, and future AI use cases.

Introduction

Moving from SAP ECC to SAP S/4HANA is not simply a technical transfer of data from one system to another. It is an opportunity to decide what data, processes and historical information the future SAP landscape should contain.

Migrating every historical record may appear to be the safest option. However, it can increase HANA sizing requirements, extend migration and testing windows, and carry old data problems into the new environment. On the other hand, deleting too much data poses a different risk. Historical information may still be needed for audits, reporting, litigation, tax compliance, or future analytics. The objective is therefore not to move everything or remove everything. It is to place each category of data in the environment where it can deliver value at an appropriate cost and risk level.

Before migrating to S/4HANA, review the business reporting requirements. Ask yourself the following question: If I archive my financial accounting data prior to migration/conversion, will I be able to reconcile my accounts after the migration/conversion?

Here is an illustrative example: at TJC Group, we have seen cases where SAP customers switch from an accounts-based solution in their legacy environment to a ledger-based solution in their S/4HANA environment. The issue arises when the customer wants to display all the documents for a given time period, including the “Old world (ERP)” and the “New world (sFin)” before and after the migration (including leading and non-leading/extension ledgers), and the organisation also wants to include archived and online items within ONE transaction. SAP does not provide a standard out-of-the-box solution for such cases.

For most companies, this means dividing SAP ECC data into four groups:

The final scope should always be defined for the organisation’s own SAP landscape. A greenfield implementation, brownfield conversion, and Selective Data Transition will each create different options and constraints for what can be migrated, archived, deleted, or retained outside the core ERP. The right decision also depends on business reporting needs, compliance obligations, system dependencies, data quality, and how much historical information must remain available after go-live.

Making these decisions early can create a leaner S/4HANA system while preserving the historical information that future business, compliance, analytics, and AI use cases may require.

Why migrating all ECC data can create unnecessary complexity

Migrating from SAP ECC to SAP S/4HANA is more than a technical upgrade. It is an opportunity to simplify the system and improve long-term performance. A common misconception is that every piece of data from the ECC system must be migrated. In reality, migrating all historical data often increases cost, complexity, and project risk without providing significant business value.

HANA memory needs and associated costs

Data volume influences HANA memory and storage requirements, system copy durations, backup and recovery times, disaster recovery planning, testing effort, migration runtimes, and the cost of maintaining development, quality assurance, and production environments.

The financial closing becomes cumbersome

Large data volumes can also increase the complexity of day-to-day system administration. Financial reports and period-end closing activities may need to process years of historical records that are no longer relevant to current business operations. Backups take longer, system refreshes require more time and resources, and future upgrades must process a larger database.

The impact becomes even greater when multiple SAP ECC systems are consolidated into a single SAP S/4HANA environment. For example, different systems may contain:

• Duplicate customer and supplier master records
• Different charts of accounts
• Inactive company codes
• Historical data from acquired or divested businesses
• Custom tables and custom objects that are no longer used
• Legacy records with unclear business ownership
• Data that has exceeded its required retention period

Moving all of this information does not automatically create a more complete or useful S/4HANA system. It may simply transfer existing complexity into a more expensive environment.

BT Group experienced the practical impact of high SAP data volumes during its transformation. At one point, its data volume had reached 12.5 TB and was affecting system performance. Through data archiving and tiering, this was reduced to 8 TB while supporting the organisation’s transition from multiple SAP ECC databases to SAP S/4HANA.

Carlsberg Group followed a long-term data volume management programme while consolidating multiple ERP systems and preparing for cloud migration. Its programme reduced the database size by 62.5% and introduced ongoing controls to prevent unchecked growth from returning.

These examples illustrate why data preparation should begin before migration execution. Archiving should not be treated as a clean-up exercise added at the end of an S/4HANA programme. It should be part of the migration design.

How to decide what data should be migrated to S/4HANA?

Migrating to SAP S/4HANA provides an opportunity to review existing data and determine whether it continues to support business operations. Rather than moving all data from the SAP ECC system, organizations should classify information based on its business value, legal obligations, and operational needs.

The following questions can help guide the decision:

• Is the data required for ongoing business processes? Data needed for daily operations, planning, reporting, or customer service should normally be migrated.
• Is the data still actively used? Frequently accessed transactional and master data generally belongs in SAP S/4HANA, while rarely accessed historical data may be better suited for archiving.
• Is the data required for legal, regulatory, or audit purposes? If historical information must be retained but is no longer operationally relevant, it can often be archived or stored in a compliant retention solution instead of being migrated.
• Does the data support future business needs? Consider whether the information will provide value for analytics, trend analysis, or future business decisions.
• Is the data accurate and relevant? Obsolete, duplicate, inconsistent, or low-quality data should be cleansed or removed before migration.
• Has the data exceeded its retention period? Information that no longer has a business, legal, or regulatory purpose should be securely deleted in accordance with organizational policies.

A practical decision framework

A simple approach is to classify data into four categories:

The objective is not to migrate the maximum amount of data, but to migrate the right data. A well-planned data selection strategy reduces migration effort, lowers infrastructure and maintenance costs, improves system performance, and results in a cleaner, more manageable SAP S/4HANA landscape.

There is no universal number of years of historical data that every organisation should migrate. The correct scope depends on the migration method, current processes, reporting needs, regulatory obligations, data dependencies, and the technical feasibility of separating records consistently.

A useful starting point is to ask three questions:

• Is the data required to complete an active business process?
• Does it need to be available directly within S/4HANA for frequent operational use?
• Would retaining it outside the live ERP still meet the business and compliance requirement?

These questions should not be applied as a fixed template. The answer will vary depending on the organisation’s migration approach. In a greenfield project, the business may have more freedom to redesign processes and bring across only selected data. In a brownfield conversion, more existing structures and dependencies may remain in place. In a Selective Data Transition, the organisation may define a more tailored scope by company code, fiscal year, process, or organisational unit. This is why migration scope should be agreed by business, IT, data, compliance, and audit stakeholders before execution begins.

Data required for active business processes

Open and active business data usually needs to move to S/4HANA. This may include:

• Open customer and supplier items
• Active purchase and sales orders
• Current contracts
• Open production orders
• Active projects and assets
• Unsettled financial documents
• Current inventory and stock positions
• Ongoing service, warranty, or maintenance records

The selection must account for dependencies between objects. An open sales order, for example, may depend on related customer master data, pricing conditions, material records, deliveries, invoices, and accounting documents. Migrating only some parts of that chain can affect process continuity or make the information difficult to interpret.

For this reason, migration scope should be agreed jointly by business process owners, data specialists, compliance teams, and the migration programme. It should not be decided solely according to record age.

Recent historical data needed for reporting

Some completed transactions may still be used frequently for comparison and reporting. For example:

• Finance teams may need prior-year figures during closing.
• Procurement teams may compare current supplier performance with recent periods.
• Sales teams may need access to customer order history, returns, and pricing trends.

This does not mean every historical transaction must remain in S/4HANA. The decision-makers should define how much recent history is required inside the live system for year-on-year comparisons, financial reporting, operational analysis, customer service, warranty claims, planning and forecasting, regulatory reporting, and long-running projects.

A selective data transition may use fiscal years, organisational units, or a combination of both to define which records move. The right period should reflect actual usage rather than the assumption that more history is always better.

Master and custom data still used by the business

Relevant master data must move with the processes that depend on it. This may include active business partners, customers and suppliers, materials, assets, cost and profit centres, plants and storage locations, charts of accounts, organisational structures, and classification data.

S/4HANA migration is also an opportunity to address duplicate, incomplete, or inactive master records. Data quality work should establish which version of a record is authoritative, whether it has a valid owner, and whether it still supports an active process. Carrying duplicate master data into S/4HANA can weaken reporting and create problems for future automation.

Custom data needs a separate assessment. A custom table should not be migrated simply because it exists in SAP ECC. The organisation should confirm that the related process, report, interface, or application will continue in S/4HANA. Where custom functionality is being retired, its data may be more suitable for archiving or retention outside the core system.

What data should be archived before migration

SAP data archiving removes eligible information from live database tables and writes it to archive files while preserving controlled access. It can reduce the volume carried into S/4HANA without treating retained information as disposable.

However, data archiving in SAP requires more than selecting the oldest records. The data must meet the relevant business and technical prerequisites, including dependencies on related objects and open processes.

Completed transactional data

Closed transactions that are no longer required for daily operations are often strong archiving candidates. Examples may include:

• Cleared financial documents
• Completed sales and purchase documents
• Closed production orders
• Historical material documents
• Completed maintenance records
• Old application logs and technical data
• Fully settled projects

Eligibility depends on the SAP archiving object and the organisation’s rules. A document cannot be archived safely if it remains connected to an incomplete process. Archiving assessments should therefore identify open items, dependencies, residence periods, and access requirements before execution begins.

Data from inactive organisational units

Historical data may relate to company codes, plants, sales organisations, or business units that are no longer active. This can happen after corporate restructuring, mergers and acquisitions, divestments, market exits, plant closures, or legal entity consolidation.

Where the data must still be retained, archiving or legacy-system decommissioning may be more appropriate than moving it into the active S/4HANA environment. The assessment must also consider ownership. Historical data connected to a divested company may be subject to contractual, legal, or regulatory rules defining which organisation can retain it and for how long.

Data that must be retained for legal or fiscal purposes

Information that is no longer operational may still need to be preserved for tax, audit, product liability, or other regulatory reasons. Archiving can help separate this data from the live transactional workload while maintaining access for authorised users.

Retention periods may differ by country, legal entity, document type, business process, industry, and regulatory authority. A multinational organisation therefore cannot rely on one retention period for its entire SAP landscape.

Carlsberg Group’s data management programme, for example, had to account for tax, audit, and GDPR requirements across several European jurisdictions. The programme combined data archiving, retention policies, data blocking, and controlled data destruction instead of treating data volume reduction and compliance as separate projects.

What data can be deleted before migration

Archiving and deletion serve different purposes. Archived data is retained and remains accessible. Deleted data is permanently destroyed.

Deletion should therefore take place only after the organisation has validated the decision against legal retention requirements, tax and audit obligations, contractual duties, active legal holds, disputes, and operational dependencies. Even where data appears obsolete, destruction should only proceed when the relevant approvals and evidence requirements have been reviewed and documented.

As a rule of thumb, check that:

• The required retention period has expired
• No legal hold applies
• The information is not required for an active process
• The data has no continuing tax, audit, contractual, or regulatory value
• The original processing purpose no longer applies
• Dependencies with other records have been addressed
• Destruction is authorised and documented

Data that must be deleted for privacy compliance

Data privacy rules may require organisations to remove personal data when there is no longer a lawful reason to retain it. Keeping information indefinitely because it may be useful one day is not a defensible data management policy.

At the same time, privacy obligations must be balanced against statutory retention, litigation, tax, and audit requirements. Personal data should not be destroyed if another valid legal obligation requires it to remain available. SAP Information Lifecycle Management can support this balance through retention rules, blocking, legal holds, and controlled destruction.

Find more information on data privacy requirements in different countries and regions in the TJC Group Data Privacy Series.

Data that no longer serves a valid purpose

Obsolete, irrelevant, and duplicate records can weaken data governance and increase the amount of information that must be protected, managed, and reviewed. Typical examples include outdated technical data, duplicate master records, test data, or information relating to organisational structures that no longer exist.

Corporate carve-out: An organisation sells a subsidiary. Following the relevant contractual and statutory retention periods, some data relating to the former entity may no longer serve a business purpose. The organisation should determine which records must transfer to the buyer, which it is authorised or required to retain, and which can eventually be destroyed.

Product discontinuation: A telecommunications company has stopped selling several phone models. The related article numbers, specifications, inventory records, and transaction history may still need to be retained for warranties, tax, product liability, or reporting. Once those requirements expire, records with no remaining purpose may become eligible for destruction.

In both scenarios, age alone is not sufficient. The organisation needs a policy-based decision supported by business ownership, retention rules, and documented approval.

What data should remain accessible outside S/4HANA

Not all useful historical data needs to sit inside the live S/4HANA database. Some information may be accessed rarely but still carry significant business or legal value. Retaining it outside the core ERP can preserve that value while avoiding the cost of keeping the complete legacy environment operational.

Historical information needed for audits and reporting

Finance, tax, internal audit, and business teams may need access to historical invoices and accounting entries, original financial reports, supporting documents, past transactions, customer and supplier records, data from closed legal entities, information from acquired businesses, and records from non-SAP applications.

Access requirements should be defined before the source system is switched off. The retained information must remain understandable. A raw database extract may not provide enough context for an auditor or business user to interpret the records several years later. A suitable retention approach should preserve relevant relationships, reports, documents, metadata, and traceability.

Data subject to a legal hold

A legal hold is different from an ordinary retention period. A retention rule defines how long a category of data should normally be kept. A legal hold suspends planned deletion or destruction for information connected to litigation, an investigation, an audit, or another legal matter.

In SAP ILM, a legal hold can prevent relevant data from being destroyed even when the normal retention period has expired. It can apply to information still held in the database as well as information stored in an ILM store. This means legal holds must be checked before any pre-migration deletion programme begins.

The process should establish which matter requires the hold, which records and data objects are affected, who authorised it, when it was applied, whether it covers archived as well as live information, who can release the hold, and how destruction resumes once the hold ends. A legal hold should preserve the relevant evidence without becoming a reason to retain unrelated data indefinitely.

Data from decommissioned SAP and non-SAP systems

After S/4HANA goes live, some organisations continue paying for old systems because users occasionally need historical information. This creates a second ERP estate that must still be hosted, secured, patched, supported, and monitored.

Legacy system decommissioning provides another option. The required data, documents, reports, and context can be extracted into a governed environment. The original application can then be retired while authorised users retain access to the information they need. This is particularly important when the wider landscape includes several SAP and non-SAP systems.

How better data decisions support future AI use cases

An AI-ready S/4HANA environment does not need every historical record in the live database. It needs reliable, well-governed, traceable, and accessible data that can support a defined business purpose. For many future AI use cases, data quality, data governance, data lineage, and context will matter more than the total volume of data available.

Data readiness concerns the quality and relevance of the information used in the active environment. Archiving completed and inactive records can reduce unnecessary volume while improving the focus of the live data set.

Data availability concerns whether useful historical information can still be found, understood, and provided to analytics or AI platforms when needed.

Historical data may support future use cases such as supplier risk analysis, payment-delay prediction, customer behaviour analysis, demand forecasting, fraud detection, anomaly detection, and maintenance planning. However, retaining more history does not automatically make a system more AI-ready. The data must remain understandable, traceable, governed, and accessible under the right permissions. Otherwise, large volumes of historical data may simply add noise, risk, and complexity.

The organisation must still apply retention and deletion rules, data privacy controls, user authorisations, data masking, purpose-based access, traceability, quality checks, and legal holds.

AI readiness is therefore not only a question of data quantity. It depends on whether the organisation knows what data it holds, why it is retained, where it came from, who can access it, and whether it is reliable enough for the intended purpose.

How TJC Group supports data assessment, archiving, and legacy access

TJC Group helps organisations decide what should move into S/4HANA, what can be archived, what should be deleted, and what needs to remain accessible after legacy systems are retired.

Data archiving and legacy system decommissioning are important parts of S/4HANA preparation, but they are not the whole transformation programme. Organisations also need to address data cleansing, harmonisation, master data governance, process redesign, and ownership of critical data objects. Data Archiving in SAP helps reduce unnecessary live data volume and preserve access to completed records, while cleansing and governance help ensure that the data moving into S/4HANA is accurate, consistent, and fit for future business and AI use cases.

The process begins with an assessment of the existing SAP landscape. This can include:

• Analysing current database size
• Identifying large and fast-growing tables
• Reviewing open items and data dependencies
• Estimating future data growth
• Mapping business and regulatory retention requirements
• Identifying inactive organisational units
• Quantifying potential archiving opportunities
• Prioritising quick wins
• Planning ongoing data volume management

In one project for a global provider of commercial cleaning, hygiene, and infection prevention solutions, an initial archiving phase removed 27.6 TB of data. The organisation then moved from one-off clean-up work to ongoing automated archiving to keep future growth under control.

Automating SAP data archiving with Archiving Sessions Cockpit

The Archiving Sessions Cockpit, or ASC, is SAP-certified software developed by TJC Group to automate SAP data archiving and ILM processes. It supports the complete archiving workflow, including the creation and management of archiving files, deletion from live tables, session monitoring, and recurring execution. ASC is available in two versions: ASC Standard and ASC for ILM.

ASC Standard for classical data archiving

This edition focuses on traditional SAP data archiving and data volume reduction. It helps organisations automate recurring archiving jobs and maintain control of database growth before and after S/4HANA migration.

ASC for ILM for data deletion

This edition combines archiving automation with SAP ILM processes. It supports retention management and controlled data destruction in line with policies such as GDPR requirements.

Automation is essential because the benefits of an initial archiving project can disappear if data growth is allowed to resume. Regular execution helps maintain the database reduction achieved during migration preparation. However, archiving automation should sit within a wider data-management strategy that also includes data quality, master data governance, retention policies, and clear ownership of future data growth.

Retaining access to legacy information with ELSA

Where historical information needs to remain accessible outside S/4HANA, TJC Group’s Enterprise Legacy System Application, or ELSA, supports the decommissioning of SAP and non-SAP systems. ELSA is built on SAP Business Technology Platform and can preserve access to legacy data, documents, reports, and transactions after the original application has been retired.

It also supports capabilities such as centralised access to several legacy systems, user and security management, traceability, data masking, predefined and custom queries, access from current applications, and data privacy and compliance controls.

Together, ASC and ELSA address different parts of the migration decision. ASC helps maintain a lean, controlled SAP environment through archiving and ILM automation. ELSA helps organisations retire legacy systems while preserving governed access to the historical information that remains valuable.

The result is not an empty S/4HANA system, nor one carrying decades of unnecessary data. It is an ERP environment containing the information needed for current operations, supported by a governed historical data layer for reporting, compliance, analytics, and future AI use cases.