SAP ILM vs. SAP data archiving: which one you actually need

The records manager and the basis lead are in the same meeting for the first time in two years. The records manager has a binder of retention schedules — seven years on tax records, six on contracts in this jurisdiction, ten in that one, indefinite on certain customer correspondence under an active legal hold.

The basis lead has a list of archive objects, an ADK configuration, and a working archive run. The two artifacts have never spoken to each other.

The records manager is the one who asks the question that breaks the room: so when does an archived document become legally allowed to be destroyed? The basis lead does not have an answer, because archiving in SAP means moving the document out of the database — it does not, on its own, govern whether or when the document is destroyed.

That gap — between moving data and governing what is allowed to happen to it — is the entire reason SAP ILM exists. The two are not synonyms. They are different layers of the same retention discipline, and most programs implement one and assume they have implemented the other.

Step One — The Wrong Assumption

If we're archiving, we're covered.

"We turned on data archiving in ECC last year. The records retention requirement is handled."

— Standard SAP basis position pre-ILM rollout

The assumption equates two activities that are sequential, not equivalent. Archiving moves business documents out of the operational database into an archive store, controlled by an archive object configuration. It does not, by itself, encode the retention period, the legal-hold logic, or the destruction rule. A program that has implemented archiving without ILM has solved data placement; it has not solved retention governance, and an audit that asks for the retention rule will find a configuration file rather than a policy.

Step Two — The Partial Signal

The audit asks for the retention rule, and the program cannot produce it.

The partial signal is usually external. An audit, a regulator review, or a GDPR data-subject request asks the SAP team to demonstrate which retention policy applies to a class of records, how the policy is enforced, and when the records are scheduled for destruction. The team can produce the archive object configuration, but the configuration does not answer the question — it shows where the data went, not what rule controls when it can leave.

The records manager has the policy on paper. The basis team has the data on disk. Neither artifact governs the other.

Step Three — The Failed Fix

Step Three — The Failed Fix

The failed fix is a custom layer. The SAP team writes ABAP that checks document age, applies a retention table, and triggers destruction. The records manager signs off because the logic appears to reflect the policy. Twelve months later, the policy changes — a new jurisdiction, a new product line, a new legal hold — and the custom code becomes the bottleneck. Every retention change becomes a development ticket. Legal holds are applied manually. Audits become a code review.

The fix did not fix anything because it produced an enforcement mechanism the records manager cannot read, the legal team cannot extend, and the platform cannot govern. That is the gap SAP ILM was specifically designed to close.

Fig. 1 — Archiving moves records; ILM governs the rule. Without ILM, the platform cannot tell an auditor what retention policy applies to any given record.

Step Four — The Real Failure

The actual failure is implementing placement without governance.

The real failure is that data archiving and SAP Information Lifecycle Management solve different problems. Archiving is the mechanism — the ADK, the archive objects, the placement of the data into a defined store.[1] ILM is the governance — the policies that bind retention periods to record classes, that enforce legal hold against destruction, that produce the audit trail demonstrating that destruction happened only when policy permitted it.[2] A program that runs archiving without ILM is operating the truck without the dispatcher.

The discipline that works in regulated SAP environments authors retention policy in ILM, binds the policy to the archive objects, and lets the platform — not custom ABAP — apply the rule.

Step Five — The Definition

Now the definition lands.

SAP Information Lifecycle Management (ILM) is the SAP framework that governs when business data can be archived, must be retained, or is permitted to be destroyed — including legal hold and audit-defensible destruction records. SAP data archiving is the mechanism that moves the data, governed by the ILM policy.

The two are designed to work together. Archiving without ILM is movement without a rule. ILM without archiving is a rule without an enforcement path. A program that implements both has a retention regime an auditor can read and a platform can apply.

What Solix Enforces

ILM policy authoring bound to certified SAP archive execution.

What Solix runs here is the joined layer: SAP ILM policy design, retention rules bound to archive objects, BC-ILM-SE certified archive execution, and legal-hold workflow integrated into the platform rather than bolted on after. The records manager has policies the platform applies. The basis team has archive runs governed by those policies. The audit response is an extract from ILM, not a code review of custom ABAP.

Three things to do this week

• Inventory your archive objects and the retention rules they should obey. Pull the list of active archive objects on your SAP system and the records-retention schedule from records management. Match them. The unmatched archive objects are the gap ILM closes.
• Run a legal-hold drill on a single record class. Pick a record class that is plausibly subject to legal hold (customer correspondence under litigation, supplier records under audit) and ask the platform team to demonstrate that destruction can be suspended for that class. If the answer is a manual process, ILM is the answer to that gap.
• Author one ILM policy end to end, in production. Pick one archive object, write the ILM policy, bind it, and let the platform run a destruction cycle under the policy. The exercise produces both the working policy and the audit evidence that the policy was applied — which is the artifact every retention audit eventually asks for.

References

• SAP Help Portal — SAP Information Lifecycle Management (ILM) — Overview. SAP's framework for retention governance, legal hold, and destruction.
• SAP Help Portal — Data Archiving with the Archive Development Kit (ADK). The mechanism layer that ILM governs.
• EUR-Lex (official EU law) — GDPR Article 5(1)(e) — Storage limitation. Storage-limitation principle that ILM is designed to enforce in regulated environments.
U.S. SEC — Rule 17a-4: Records to Be Preserved by Certain Exchange Members, Brokers and Dealers. U.S. broker-dealer recordkeeping rule referenced as a parallel to SAP ILM retention enforcement in financial services.
• Forrester — Forrester Wave: Data Management for Analytics. Forrester's records-management and retention research frames the platform-enforced-policy pattern.