An SAP S/4HANA transformation needs two connected data plans: one for what the new system requires to operate, and one for history that will remain outside it. A historical data strategy decides what to migrate, archive, preserve or destroy—and how authorized users will access required records after cutover and legacy-system retirement.
Why historical data belongs in the transformation design
Historical scope affects migration volume, cutover risk, testing, business access, retention and the date on which an SAP ERP or ECC source can actually be switched off. If the program treats history as a post-go-live problem, the legacy system often remains online as an expensive reference application.
A stronger design starts with the decisions users will face after go-live: which old invoices must finance retrieve, which purchase orders auditors may sample, which asset records engineering needs, which documents must remain connected, and which data should no longer be retained.
Separate four outcomes
| Outcome | Purpose | Typical question |
|---|---|---|
| Operational migration | Establish the master data, open transactions, balances and other approved information needed in the target. | What must be available to run the business at go-live? |
| Data archiving | Remove eligible mass data from a live database while retaining supported access to the archive. | What can leave the operational database under applicable rules and object checks? |
| Historical preservation | Keep required records, documents and meaning usable outside the operational target or after source retirement. | What history must users still search, understand and report on? |
| Defensible disposition | Destroy information whose approved retention period has ended and that is not subject to a legal hold or other requirement. | What should no longer be kept, and who authorizes destruction? |
These outcomes can support one another, but none is a substitute for the others. A migrated opening balance does not preserve the documents behind it. An archive file does not by itself deliver a complete business-user experience. A backup is not a governed historical reporting platform.
How the SAP S/4HANA transition path changes the data decision
SAP documents new implementation, system conversion and selective data transition as principal paths for supported landscapes. Available routes and tools depend on the actual source and target products, deployment model and release.
System conversion
System conversion replaces SAP ERP application code with SAP S/4HANA, converts the data model and includes a database migration where required. SAP’s transition comparison describes this route as keeping all historical data. The consequence is continuity, but also the need to address volume, quality, custom code and existing lifecycle practices inside the conversion scope.
Pre-conversion archiving can reduce data volume where supported and justified. Confirm residence periods, business completion, dependencies, archive accessibility, reconciliation and retention obligations before deleting data from the source database.
New implementation
A new implementation creates a clean target. For SAP S/4HANA Cloud, SAP states that the migration cockpit loads the initial data needed to begin operations, such as master data, open transactional data and balances; SAP also states that closed-process historical transactional data cannot be migrated through that scope. Exact migration objects and constraints vary.
The historical strategy is therefore explicit: determine which closed history must remain usable, provide an approved access environment, validate it and retire the old system rather than leaving it online indefinitely “for reference.”
Selective data transition
SAP describes selective data transition as selectively migrating and transforming configuration, master and transactional data, typically through a consulting or service engagement. The path can retain and harmonize selected history.
Selection should be governed at business-object level. Cut-off dates and organizational scope are not sufficient if document flow, attachments, custom fields, master-data dependencies or audit evidence are left behind. Every excluded information category needs an approved destination or disposition.
Use a decision framework—not a single date cutoff
| Decision | Consider | Likely treatment |
|---|---|---|
| Needed to continue an open process | Open orders, items, balances, active master data and target migration support. | Migrate according to the approved transition design. |
| Closed but regularly referenced | Customer, supplier, finance, asset, maintenance or operational inquiries. | Preserve with searchable business context and supporting documents. |
| Required mainly for audit, tax or legal response | Retention periods, legal holds, evidentiary needs, access frequency and export controls. | Preserve in a governed environment with retrieval and lifecycle controls. |
| Eligible for live-system archiving | Supported archiving object, process completion, residence criteria and tested read access. | Archive before or during the program where risk and economics justify it. |
| No continuing purpose or requirement | Approved policy, applicable law, contractual duties, investigations and holds. | Destroy through the authorized disposition process. |
Scope note: This framework supports program discovery; it is not legal advice. Retention, privacy, tax and sector requirements must be determined by qualified organizational stakeholders and counsel.
Design the historical record as a business object
Useful history consists of more than transaction tables. Define preservation requirements for:
- Transactions: headers, line items, status, values and relevant change history.
- Master and reference data: suppliers, customers, materials, accounts, organizational structures and code descriptions.
- Configuration and metadata: custom fields, custom tables, value mappings and context needed to interpret historical values.
- Relationships: document flow across orders, deliveries, receipts, invoices, payments, assets and other business chains.
- Documents: attachments, print outputs, ArchiveLink content and other linked evidence.
- User journeys: the searches, reports, exports and inquiry paths authorized users must perform.
SAP’s ILM Retention Warehouse guidance illustrates the same principle in its own architecture: retrieval for decommissioning includes transaction and master data as well as context data such as Customizing and metadata needed for interpretation.
Time archiving deliberately
Archiving before transformation can reduce the data volume handled during conversion or migration, but timing depends on the transition path, available archiving objects, business close schedules and the target historical-access design.
- Establish policy and ownership. Confirm residence, retention, hold and approval responsibilities.
- Assess archiving-object coverage. Include custom data, dependencies, documents and required viewers.
- Prove retrieval. Test representative searches and reports before removing records from the database.
- Reconcile each cycle. Compare agreed counts, values and exception results.
- Coordinate with conversion cycles. Freeze rules and data-volume assumptions so scope does not move unexpectedly.
Do not use archiving as an uncontrolled cleanup exercise immediately before cutover. The program must still demonstrate that required information remains complete, accessible and governed.
Choose the post-cutover access model
| Model | Strength | Key limitation to test |
|---|---|---|
| History retained in SAP S/4HANA | Continuity within the operational application. | Volume, conversion complexity, data quality and whether all retained history still has a business purpose. |
| Native SAP archive access | Supported access to eligible archived SAP objects. | Required indexes, viewers, relationships and continued SAP-environment dependency. |
| SAP ILM Retention Warehouse | SAP-documented decommissioning, retention and retrieval scenario. | Product prerequisites, licensing, skills, source coverage, user experience and operating model. |
| Independent historical data platform | Source-independent access across SAP and non-SAP history after retirement. | Fidelity, reconciliation, lifecycle controls, security and platform-specific extraction coverage. |
The models are not mutually exclusive. Select them against defined user journeys, lifecycle controls, source diversity, expected volumes, operating skills and total lifecycle cost.
Validate migration and preservation as one control framework
Validation should prove both sides of the scope: what arrived in SAP S/4HANA and what remains available outside it.
- Scope reconciliation: applications, organizations, periods, object types and cut-off rules.
- Control totals: agreed record counts, quantities, values and balances.
- Referential integrity: orphaned records and missing master, transaction or document links.
- Transformation checks: mappings, code conversions, derived values and currency handling.
- Document validation: file integrity, metadata, retrieval and business-object linkage.
- Business-use testing: representative reports, searches, exports and process history.
- Exception governance: ownership, materiality, remediation and approval evidence.
Define retirement acceptance before cutover
Technical migration completion is not the same as legacy retirement readiness. A practical retirement gate should confirm that:
- the target operational data is accepted;
- required history and documents are preserved and reconciled;
- business users have validated priority historical scenarios;
- identity, authorization, audit and lifecycle controls are operating;
- interfaces, reports, batch jobs and downstream dependencies have an approved disposition;
- support, ownership and incident procedures are assigned; and
- shutdown evidence and final approvals are recorded.
A 10-step historical data workstream
- Inventory: map ERP instances, archives, documents, interfaces, custom data and volumes.
- Segment: group systems and information by business use, risk and retirement objective.
- Choose the transition path: validate the SAP-supported route for each source and target.
- Collect user journeys: document the historical questions that must remain answerable.
- Classify information: migrate, archive, preserve or propose for approved destruction.
- Design access: specify objects, relationships, documents, search, reporting and export.
- Design controls: define identity, authorization, audit, retention, holds and disposition.
- Extract and reconcile: validate scope, values, documents, transformations and exceptions.
- Prove readiness: run business acceptance and retirement-gate evidence.
- Operate and improve: review access, lifecycle events, service performance and new use cases.
Frequently asked questions
Should all SAP ECC history be migrated to SAP S/4HANA?
Not automatically. The answer depends on transition path, operational need, supported tools, data quality, retention requirements, target design and cost. Classify information by business purpose and ensure required history excluded from migration has an approved access or disposition plan.
What historical data can the SAP S/4HANA migration cockpit migrate?
SAP’s current cloud documentation describes migration of the initial information needed to start operations, including master data, open transactional data and balances, while stating that historical transactional data from closed or long-running past processes cannot be migrated through that scope. Validate the migration objects and limitations for the specific target release.
Should SAP data archiving happen before an S/4HANA transition?
It can reduce the live database footprint where supported and justified, but it should follow policy, object eligibility, tested retrieval and reconciliation. Timing must be coordinated with conversion cycles and the historical-access design.
Can we switch off SAP ECC after go-live?
Only when operational migration, historical access, documents, interfaces, downstream dependencies, security, lifecycle controls and business acceptance satisfy the approved retirement criteria. Go-live by itself is not sufficient evidence.
Is a data warehouse enough for legacy retirement?
It may serve analytical needs, but retirement can also require record-level fidelity, source context, linked documents, auditability, security and lifecycle controls. Test the proposed platform against every required historical user journey and obligation.
How does ArchiveHub fit an S/4HANA program?
ArchiveHub is designed to preserve agreed SAP and non-SAP history in an independent platform, including structured data, documents, metadata and business relationships. It supports modern reporting and governed access so the S/4HANA target can focus on continuing operations while eligible legacy applications move toward retirement.
Next steps
Begin historical-data discovery before migration scope and retirement economics are fixed. Use the ArchiveHub application assessment to structure source discovery, review historical data reporting requirements with business users, and consult the SAP data archiving guide for archiving governance and execution.
Official SAP references
- SAP Help: Transition Paths
- SAP Help: What Data Can Be Migrated?
- SAP Help: Lean Selective Data Transition Best Practices
- SAP Help: Data Archiving with Archive Development Kit
- SAP Help: Preparing and Executing Retrieval of Legacy Data
- SAP Help: Using ILM Retention Warehouse for System Decommissioning