An SAP S/4HANA transition does not answer every historical-data question by itself. Operational migration, data archiving and historical preservation solve different problems: one establishes the target system, one controls data volume in a live system, and one keeps required business history usable when it is not moved into the new environment.

Three workstreams that should not be confused

A sound SAP S/4HANA data strategy begins by separating three related but distinct outcomes.

  • Operational migration moves or converts the configuration, master data, balances and transactions needed for the target SAP S/4HANA system. Its scope depends on the chosen transition path.
  • Data archiving removes eligible mass data that is no longer required in the live database while retaining it in an analyzable format. SAP’s standard concept is primarily based on Archive Development Kit (ADK) archiving objects.
  • Historical preservation keeps agreed records, documents, context and relationships available after they are excluded from migration or after the source application is retired.

These workstreams can support one another, but they are not substitutes. Archiving before a transition can reduce the active database footprint, yet it does not automatically create a complete historical-access service. Likewise, migrating an opening balance does not preserve the documents and business context behind that balance.

How the SAP S/4HANA transition path changes the data question

SAP documents three principal transition options for suitable SAP ERP landscapes: system conversion, new implementation and selective data transition. The available routes depend on the source system and target offering, so the final approach should be validated for the specific landscape and release.

System conversion

A system conversion replaces the SAP ERP application with SAP S/4HANA, migrates the database to SAP HANA where required and converts the data model. SAP’s transition guidance characterizes this path as retaining all historical data. That continuity can be attractive, but it also means that data quality, volume, custom code and existing information-lifecycle practices travel into the conversion program.

Pre-conversion archiving may reduce the database volume to be handled, where supported by the relevant archiving objects and business rules. Treat it as a governed initiative: confirm residence criteria, dependencies, archive accessibility, reconciliation and retention obligations before deletion from the database.

New implementation

A new implementation creates a clean SAP S/4HANA target. For SAP S/4HANA Cloud, SAP states that the migration cockpit loads the initial data needed to start operations, including master data, open transactional data and balances; historical transactional data from completed processes cannot be migrated through that scope. Exact migration objects and limitations vary by target release and deployment.

This makes the historical strategy explicit. Decide which history the business must consult, how users will retrieve it, which source system can be switched off, and what evidence is needed before retirement. Leaving the old ERP online “for reference” postpones rather than resolves those decisions.

Selective data transition

Selective data transition sits between the other paths. SAP describes it as selectively migrating and transforming configuration, master and transactional data, typically through a consulting or service engagement. SAP also notes that selected historical data can be retained and harmonized.

Selection is therefore an information-design exercise, not only a technical filter. Define cut-off dates and organizational scope alongside document flow, master-data dependencies, attachments, audit evidence and reporting needs. Information excluded from the target still needs an approved disposition: preserve it elsewhere for a defined purpose or destroy it when policy and law permit.

What SAP data archiving does in S/4HANA

SAP defines data archiving as removing mass data from the database when it is no longer required in the system but must remain analyzable. ADK archiving objects describe the structure and business context of eligible data. The standard flow writes data to archive files, can store those files externally, and deletes database records using the successfully created archive files.

Eligibility is application-specific. A completed business process, applicable residence period and other checks may be prerequisites. Available archiving objects, read programs and ILM integration also vary. Test each required business object and access route rather than assuming that every table or custom relationship will be covered.

Data aging is different again. SAP describes it as moving data within the database from a current area to a historical area to reduce working-memory consumption. The data remains in the operational system; it has not been exported through the ADK write-and-delete process. Data aging can be useful for supported scenarios, but it should not be labeled application retirement or external historical preservation.

Design historical preservation around business use

Historical preservation becomes critical when records will not reside in the target SAP S/4HANA system or when a source system will be decommissioned. Define the requirement at business-object level, including:

  • transactions, line items, status history and relevant master data;
  • custom fields, custom tables, code lists and configuration needed for interpretation;
  • attachments, print outputs and linked documents;
  • relationships across orders, deliveries, invoices, payments and other process chains;
  • authorized search, reporting, export and audit use cases; and
  • retention, legal hold, audit logging and defensible destruction.

SAP ILM Retention Warehouse is one SAP-documented option for decommissioning. SAP describes transferring archived or extracted legacy data to a stand-alone RW system, applying ILM rules, enabling defined retrieval, and destroying eligible data after retention periods expire when no legal hold applies. SAP’s process also calls for context data and metadata required to interpret the retained records.

Other architectures may preserve agreed history in a separate enterprise platform. The right choice depends on source diversity, required user experience, compliance controls, reporting depth, operating skills and total lifecycle cost. For ArchiveHub’s approach to decoupling usable history from legacy applications, see application retirement and the SAP S/4HANA migration solution.

A practical migration and archiving sequence

  1. Inventory the landscape. Map source systems, interfaces, volumes, archiving status, custom data and document stores.
  2. Choose the transition path. Confirm what system conversion, new implementation or selective transition means for the actual target.
  3. Classify information. Separate operational target data, retained history and records eligible for destruction.
  4. Reduce volume where justified. Use supported archiving or other SAP data-management functions with tested access and reconciliation.
  5. Design historical access. Specify users, questions, reports, relationships, documents, controls and service levels.
  6. Validate before cutover. Reconcile counts and values, test representative business processes and capture stakeholder approval.
  7. Retire deliberately. Remove interfaces and source-system dependencies only after migration and historical-access acceptance criteria are met.

Use the ArchiveHub assessment to structure the discovery, and consult the SAP data archiving guide for a broader treatment of governance, execution and access.

Questions to settle before design approval

  • Which data is required to operate on day one, and which is reference history?
  • Which historical processes must remain navigable end to end?
  • Can users retrieve archived information without keeping the source system running?
  • How will custom data and attachments retain their business meaning?
  • Who owns retention decisions, legal holds, access reviews and final destruction?
  • What reconciliation evidence will authorize cutover and decommissioning?

Official SAP references

Important: Supported transition paths, migration objects, archiving objects, lifecycle functions, prerequisites and licensing vary by product, deployment and release. Validate the design against the applicable SAP documentation and your organization’s legal and contractual requirements. This article is not legal advice.