How ILM differs from classic archiving
Classic ADK archiving controls write, delete, storage and access for supported archiving objects. SAP Information Lifecycle Management adds lifecycle rules and governance: residence and retention policies, legal holds, compliant storage and destruction after applicable conditions are satisfied. SAP describes ILM as enhanced data archiving, not a replacement for understanding the underlying application object.
Step 1: confirm the ILM use case and prerequisites
State whether the objective is database-volume management, privacy-driven blocking and deletion, records retention, legal hold, or a combination. Confirm the applicable SAP product and release, required business functions or activation, supported archiving and ILM objects, authorizations, storage capability and organizational policy owners.
Step 2: map the archiving object to its ILM object
An ILM object provides the policy framework and available time references and condition fields for related data. Confirm the delivered assignment for the application and release. Review which policy categories and conditions are supported; do not assume every business attribute is available in a rule.
Step 3: define audit areas and policy ownership
Audit areas group ILM objects for a defined legal or business context. Design them around accountable policy domains rather than technical convenience. Document the jurisdiction, record purpose, owning function, review cycle and escalation path. Keep rules understandable enough that legal and business reviewers can validate them.
Step 4: design residence and retention rules
Residence normally influences how long data remains in the database before it becomes eligible for archiving. Retention controls how long the information must be retained before destruction can be considered. Define the time reference, offset and supported conditions. Resolve gaps, conflicts and fallback behavior before configuration.
Use a decision table outside the system first: ILM object, policy category, condition fields, time reference, minimum period, source of authority, owner and approval. This becomes both design evidence and a review aid.
Step 5: configure and activate policies
Use the applicable ILM customizing and policy tools, including transaction IRMPOL where documented for the product. Create policies in a non-production environment, enter rules using only supported fields and time references, and perform the available consistency checks. Apply controlled transport and change-management practices.
Step 6: design legal-hold handling
Legal holds protect relevant information from premature destruction. Define who can create, approve, review and release a hold; how custodians, cases and affected objects are identified; and how the hold is evidenced. Test that a held object is protected in both the database and the ILM store where applicable.
Step 7: validate ILM-aware archiving
Run the supported preprocessing or archivability checks for a small representative population. Use the relevant archiving action—such as archiving, snapshot or data destruction—only where the object and release provide it. Inspect calculated dates, selected rules, ineligible objects and logs. Then execute the controlled write path and verify that policy information accompanies the stored resources as designed.
Step 8: validate the ILM store and access path
Confirm the selected storage system meets the required BC-ILM interface and operational controls. Test resource storage, retention protection, authorizations, encryption, backup, recovery and retrieval. SAP documents ILM Store as one option using a WebDAV interface; supported storage choices and deployment details depend on the environment.
Step 9: test destruction without destroying production data
Create representative non-production cases: retention not expired, retention expired, active legal hold, released hold, missing rule and conflicting policy. Verify which records the system selects and rejects. Destruction should occur only when the applicable retention conditions are satisfied, no blocking hold applies and authorized procedure permits it.
Step 10: establish policy operations and evidence
Define rule-review cadence, change approval, transport control, exception monitoring, hold review, destruction authorization, access testing and evidence retention. Monitor both technical execution and governance outcomes. A policy is not complete merely because it is active in the system; it must remain aligned with approved requirements.
Minimum evidence pack
- Approved policy decision table and source authority
- ILM-object and audit-area scope
- Rule configuration and consistency-check results
- Matched, unmatched and boundary-condition test results
- Legal-hold protection and release tests
- Storage and retrieval validation
- Destruction simulation, authorization and execution logs
- Business, legal and technical acceptance