Blog Details

SAP data archiving moves completed business records out of the live database into compressed archive files that stay readable. Data deletion removes those records permanently. Most SAP teams treat data archiving and data deletion as two routes to the same outcome, a smaller database. They are different decisions, with different owners, different tooling, and different consequences if you get them the wrong way round.

Here is the part that changes how the work gets planned. In standard SAP, archiving is how deletion happens. The Archive Development Kit runs a write program that copies records into archive files, and a separate delete program then reads those files back and removes the rows from the database.

So the real question is never archive or delete. It is which records stay retrievable, for how long, and who signs off when they are finally destroyed.

What SAP data archiving actually does

SAP data archiving is a controlled, three-phase removal of closed business data from the database. It runs through transaction SARA against a predefined archiving object, and each object knows which tables belong to one business document.

1. Write: The write program selects records that have passed their residence period and copies them sequentially into archive files. Nothing is deleted yet.
2. Store: The archive files move to an ILM-certified store, an SAP content server, or an OpenText archive. Configuration can force this step to finish before deletion runs.
3. Delete: The delete program reads the archive file back, confirms the records were written correctly, then removes them from the database tables.

Two controls sit underneath all of it. The residence period is how long a completed record stays in the live database before it becomes eligible for archiving. The retention period is how long it must be kept anywhere at all, database or archive, before it can be destroyed. Teams that confuse the two either archive data they still need daily, or hold archives forever because nobody set an end date.

SAP data archiving keeps history accessible. Archive information structures, built through transaction SARI, index the archive files so standard display transactions and reports read records back without reloading them. Users still see the document. The database no longer carries it.

What data deletion actually means in SAP

Deletion in SAP means one of two very different things, and that ambiguity derails scoping conversations.

Deletion as part of SAP data archiving. This is the delete phase above. The record leaves the database and continues to exist in the archive.

Deletion as destruction. This is permanent removal from both the database and the archive, once the retention period has expired. It runs through SAP Information Lifecycle Management, using transaction ILM_DESTRUCTION against retention policies maintained in IRMPOL. Nothing survives, and that is the point.

Direct table deletion outside archiving objects is a third, narrow category. It suits technical residue: application logs, spool requests, job logs, IDoc status records, workflow items. Standard SAP housekeeping reports cover most of it. Applying the same approach to transactional data breaks document flow, orphans line items, and leaves reconciliation gaps that surface during audit.

The working rule: if a record has a business document number, it goes through an archiving object. If it does not, a housekeeping job is usually enough.

SAP data archiving and data deletion compared

Why SAP data archiving is a licensing decision

SAP HANA licensing is sized on memory, and memory is bought in steps. A landscape sitting at 1.4 TB does not pay for 1.4 TB. It pays for the next step above it. So the commercial value of archiving is not linear. Removing 200 GB from a database sitting just under a threshold changes nothing. Removing the 400 GB that takes you back below the previous step changes the annual bill.

That is why SAP data archiving belongs in a cost conversation with the CFO rather than a maintenance window conversation with Basis. The questions that matter are which tables grow fastest, where the next licensing step sits, and how much of that growth closed business three years ago.

The second argument is migration. Every terabyte carried into S/4HANA has to be converted, validated, and tested, then paid for again in target sizing and cloud subscription. SAP data archiving before a brownfield conversion shortens the downtime window, cuts the volume in scope for validation, and lowers target sizing. Doing it after go-live still helps. Doing it before compounds.

The third is the one organizations find late. After a successful go-live, the old ECC system often stays running because someone needs reference access to history. That duplicate landscape carries licensing, hosting, Basis effort, patching, and audit scope for as long as it stays on. Moving archived content into a retention store and shutting the legacy system down ends all of it. TechOrbit’s Migration Cockpit exists for this step, moving archived content on the SAP ADK framework so reference access survives the system that created it.

Why deletion is a compliance decision under DPDP

SAP data archiving reduces cost. Destruction is what closes legal exposure, and that distinction is now enforceable in India.

Section 8(7) of the Digital Personal Data Protection Act places a positive obligation on a data fiduciary to erase personal data once consent is withdrawn or the specified purpose is no longer being served, unless another law requires it to be kept. It is not a right an individual has to invoke. It runs on its own.

An archive does not satisfy that. Personal data held in an archive file is still held. If a programme has only moved records out of the database, the obligation has been relocated rather than discharged. That is the gap SAP ILM closes.

The sequence SAP supports is specific. An end-of-purpose check determines whether a record still serves a business activity. Once residence time expires, personal data can be blocked, restricting it to users with additional authorization who cannot create, change, or copy business objects using it. When the retention period ends, the data is destroyed so it cannot be retrieved. Retention rules live in IRMPOL, and legal holds suspend destruction where litigation or assessment is open.

The tension worth naming: DPDP pushes toward erasure, while GST, income tax, the Companies Act, and sector regulators push toward retention. One customer record can sit under both. Reconciling them object by object is the actual deliverable. It is a governance exercise that runs on SAP tooling, not a configuration task that happens to touch policy.

Where data aging and system decommissioning fit

Two adjacent options get folded into SAP data archiving conversations and should not be.

Data aging partitions data inside S/4HANA into current and historical areas, moving the historical partition out of memory while leaving it in the database. It relieves memory pressure and preserves direct table access, but total database size is unchanged and the retention clock keeps running. It is a performance lever, not a retention answer.

System decommissioning applies when a legacy system has outlived its purpose but its data has not. Data is extracted into an ILM Retention Warehouse, reporting and audit access is preserved, retention rules are applied centrally, and the source system is switched off. For any organization running a parallel ECC landscape after go-live, this is the highest-value move available.

Deciding which objects to archive, which to delete, and in what order is usually a two-week exercise against your retention rules.