SAP data archiving in S/4HANA: ILM, aging, NSE

SAP data archiving: objects and process

Data archiving removes completed business transactions from the database and writes them to archive files. The data only disappears from the database, not from the application: it remains readable, but can no longer be changed.

The basis is the archiving object. It defines which tables belong to a business object and which programs process them. You archive accounting documents, for example, with FI_DOCUMNT, including change documents and texts, and sales documents with SD_VBAK. Transaction DB15 shows which tables an object comprises. Archiving is integrated into the application: for each document, the write program checks whether it may be archived, for example whether it is completed and has reached its minimum residence time.

Everything is controlled in archive administration (transaction SARA). The runs are background jobs and work in separate steps:

Write. The write program writes the archivable objects to new archive files and compresses them in the process, according to SAP by a factor of up to 5. It does not delete anything.
Store. Optionally, the system transfers the files via the Content Management Infrastructure (ArchiveLink) to a content repository in a connected storage system. Whether files are stored before or after deletion is set in the Customizing of the archiving object.
Delete. The delete program reads the archive file and removes from the database only the data that it finds again in the file. A test variant is available for many objects.
Post-processing. Depending on the object, a post-processing program and the filling of the archive indexes follow, so that the data can be found later.

Because writing and deleting are separate, a cancelled run can be restarted, and only data that is safely in the archive is deleted. The sequence ‘store first, then delete’ offers the highest level of security.

Accessing archived data

Archived data remains accessible through the system: as single-record read access, sequentially for evaluations and, where the object provides for it, by reloading it into the database. For targeted searches, there is the Archive Information System (transaction SARI). It uses field catalogues to build archive information structures, a kind of index over the archive files.

How well access works in day-to-day operations depends on these structures. An example from financial accounting: the document display FB03 only shows archived documents if an active information structure based on the field catalogues SAP_FI_DOC_001 or SAP_FI_DOC_002 exists. For line item lists, the runtimes of the secondary indexes determine how long archived documents appear there directly. Before the first run, therefore, clarify with the business departments who still needs to see which data, and by what means.

SAP ILM: rule-based archiving

SAP Information Lifecycle Management (ILM) builds on data archiving. It adds rules for the lifecycle of production and archived data:

ILM rules: Retention rules reflect legal requirements; residence rules define how long data remains in the database at a minimum. They are maintained in ILM policies (transaction IRMPOL).
Legal holds: Data that is needed for legal proceedings can be locked against premature destruction.
Destruction: Data without a legal hold whose retention period has expired can be destroyed, both in the archive and in the database.
ILM store: Archived data resides in an ILM-enabled store which, according to SAP, protects it from modification and premature deletion.

Technically, ILM uses the existing archiving objects. If the business functions for ILM are active, the write program offers additional ILM actions, such as archiving that evaluates the stored retention periods, or data destruction. SAP Note 2122906 lists which archiving objects belong to which ILM object. As a standalone retention warehouse, ILM also takes in data from decommissioned legacy systems. In short: ILM does not replace archiving, it controls it according to rules.

No legal advice. Which retention periods apply to your data is a legal question. Clarify it with your legal department, tax advisers and data protection officer before you store rules in the system.

Data aging and NSE: less RAM, same database

Two related methods reduce main memory requirements without removing data from the database.

Data aging moves data within the database from the current area to a historical area in order to free up main memory. For accounting documents, the aging object FI_DOCUMENT is available for this. SAP explicitly names it as an alternative to archiving with FI_DOCUMNT. Coordination is needed here too: according to SAP, the CDS-based reports in the statutory reporting of SAP Document and Reporting Compliance, for example, only read the current area.

Native Storage Extension (NSE) is a warm data store in SAP HANA. Rarely used tables, partitions or columns are marked as ‘page loadable’ and are loaded into main memory only page by page, on demand, via a buffer cache. The capacity of the database is then the hot part in memory plus the warm part on disk. SAP Note 2816823 describes its use and restrictions in S/4HANA.

What matters for the distinction: with both methods, the data remains part of the database. According to SAP, warm NSE data is included in backup and system replication. So it is still contained in every backup and in every full copy.

Method	Where the data resides afterwards	Main memory	Backups and copies
Archiving	In archive files outside the database	decreases	become smaller
Deletion (housekeeping)	Nowhere; the data has been removed	decreases	become smaller
Data aging	In the historical area of the database	decreases	unchanged
Native Storage Extension	In the warm area of the database, on disk	decreases	unchanged

What can be deleted in logs, IDocs and other technical data is shown in the article Cleaning up technical tables.

What archiving delivers in S/4HANA and where it ends

Apart from deletion, archiving is the only one of these methods that reduces the size of the database itself. This has an effect in several places:

Main memory: Less data in SAP HANA means less RAM, and RAM is currently expensive: What RAM prices mean for S/4HANA.
Backups: A smaller database means smaller backups and shorter backup and restore times.
Runtimes: SAP explicitly names the recovered storage space as a lever for the performance of application programs.
Copies: Every system or client copy from production becomes smaller and faster. The basics article explains why the data volume determines the runtime of a client copy.

A peculiarity of S/4HANA shows why you should plan the effect per object: according to SAP documentation, FI_DOCUMNT archives the entries in the Universal Journal (table ACDOCA) but does not delete them, because the table also provides balances. How much space is freed up there depends on the interplay with the archiving objects for transaction figures.

The limits lie less in the technology than in the organisation:

A project with the business departments: Finance, logistics, internal audit and data protection have a say in what is archived, not Basis alone.
Residence times: Data remains in the database for a minimum period, defined in the Customizing of the application, in FI for example via account type life and document type life, and with ILM via residence rules.
Dependencies: Some objects can only be archived once their predecessors have been archived. Archive administration shows this in a network graphic.
Retention: Archive files must remain readable for the entire retention period. You may only destroy them after that.
Not everything can be archived: Open transactions and everything that operations, reporting and audits need on an ongoing basis remain in the database. Custom Z tables need their own archiving object.

Approach in an archiving project

Analyse. Identify the largest tables and their growth, for example with the space analysis in DB02. The table analysis TAANA shows how the entries are distributed across organisational units and periods, and helps you choose the archiving object and selection.
Prioritise. Clean up technical data first, then tackle business objects with large volumes and clear rules.
Agree. Define residence times, access paths and retention periods with the business departments, internal audit and data protection, and document them in an archiving concept.
Set up. Configure logical file names and paths (transaction FILE), the content repository, archive information structures and, if applicable, ILM.
Test. Run through the first cycle in a production-like test system: write, delete in test mode, then delete for real and check access from the users’ perspective.
Routine operation. Schedule and monitor archiving runs regularly. Archiving is not a one-off project.

In routine operation, the runs are part of day-to-day business, like backups and housekeeping. How we support this is shown on the page SAP Basis, AMS and managed services.

Archiving and test systems

Archiving reduces the size of production and therefore of every full copy. But it ends where data has to remain online for business or legal reasons, and that is often several fiscal years. A full copy brings these years into QA, test and sandbox, although the last few months are usually sufficient there.

This is where time slices come in. The Data Refresh Operator copies a time frame, for example the last 90 days, and adds all dependent objects from earlier years. Dependencies are resolved up to the fixpoint – the verifiable point at which no new objects are added. Nothing is missing, and production remains unchanged. Archiving and time slices complement each other: one reduces the source, the other the part of it that ends up in non-production systems.

–75%: HANA RAM in non-production
–60%: Storage & backup

Guideline values from reference scenarios. The actual effects depend on system size, history and refresh cycles.

DRO runs on SAP S/4HANA from release 2023 and replaces the client copy, not the system copy. What this means for the memory in your landscape is shown on the page Reducing HANA memory in QA, test and sandbox.

Sources

SAP Help (SAP S/4HANA): Properties and features of data archiving
SAP Help (SAP S/4HANA 2025): Archiving financial accounting documents (FI-GL, FI-AR, FI-AP) with FI_DOCUMNT
SAP Help (SAP S/4HANA 2025): Displaying archived accounting documents (FI)
SAP Help (SAP S/4HANA 2025): SAP Information Lifecycle Management
SAP Help (SAP S/4HANA 2025): Data aging for accounting documents
SAP Help (SAP HANA 2.0 SPS 08): SAP HANA Native Storage Extension

SAP archiving in S/4HANA: reducing data volume for good