What Retention Warehouse is designed to do

SAP documents ILM Retention Warehouse as a stand-alone environment for managing legacy information from systems being decommissioned. The standard process transfers archived or extracted legacy data, applies Retention Management, supports relevant reporting and eventually destroys information whose retention has expired and that is not protected by a legal hold.

Step 1: establish the retirement scope and shutdown gates

Inventory the legacy system, clients, company codes, modules, interfaces, custom developments, documents, archive files, output repositories, users and legal obligations. Define what information must be preserved and which reports and searches must work after shutdown. Name the technical, business, legal and records-management approvers.

Shutdown principleDo not schedule source-system shutdown merely because data transfer completed. Require reconciliation, retrieval acceptance, dependency closure, operating ownership and formal authorization.

Step 2: assess existing archives and extraction requirements

Determine which information already resides in ADK archive files and which remains in the database. Identify master data, transaction data, context, attachments and custom information required to create an adequate historical representation. SAP’s prerequisite is that the necessary data has been archived or extracted from the legacy system.

Step 3: prepare archive administration metadata

Retention Warehouse needs the administrative and structural information required to interpret transferred archives. SAP documentation describes transferring archive administration data in the SN_META metadata file. Validate completeness, version compatibility and traceability to the originating system before progressing.

Step 4: design audit areas and ILM policies

In the Retention Warehouse environment, define the audit areas and ILM policies that will govern the transferred legacy information. Confirm time references, retention rules, legal-hold procedures and policy ownership. Test the policy against representative data and boundary conditions.

Step 5: transfer archive files, database extracts and context

Execute the supported transfer process for archived transaction data, master data and context. Maintain provenance: source system, client, extraction run, archive session, file identifiers, checksums, counts and transformation history. Store the converted resources in the ILM store according to the applicable rules.

Completeness warning: A technically successful file transfer does not prove that all required business information, documents or relationships were captured.

Step 6: reconcile the transferred population

Compare source inventories, archive administration data, transferred files, record counts, control totals and exceptions. Reconcile by meaningful business dimensions such as company code, fiscal period, document type and organizational unit. Investigate every unexplained difference and retain the evidence.

Step 7: configure and validate reporting

Enable the reporting functions required by the approved use cases. SAP documentation describes local reporting and SAP BW-based evaluation for scenarios such as tax audit or product-liability analysis. Test representative business questions, not only technical record retrieval.

Acceptance should cover searches, document display, relationships, currency and date semantics, attachments, exports, authorizations and reproducibility. Test users should include finance, audit, legal or operational roles as applicable.

Step 8: prove lifecycle controls and legal holds

Demonstrate that policy dates are applied as designed, held information is protected and expired information is not destroyed without the required authorization. Test hold creation, review and release using non-production data. Document exception-handling and policy-change procedures.

Step 9: close dependencies and authorize shutdown

Confirm that integrations, scheduled jobs, identity dependencies, outbound reports, document repositories, operational support and user access no longer require the source. Assemble the evidence pack and obtain explicit authorization before switch-off.

Step 10: confirm shutdown and operate retained history

Record the shutdown execution, infrastructure disposition, credential closure, support ownership and recovery decision. Continue monitoring reporting, access, policy operations, legal holds, backups and destruction. A retired application creates a long-lived historical-information service that still needs ownership.

Retention Warehouse versus ArchiveHub

Retention Warehouse is an SAP-defined decommissioning approach centered on SAP ILM constructs and the RW environment. ArchiveHub supports SAP and non-SAP retirement with application-independent historical access, business-oriented reporting, documents and relationships. The appropriate architecture depends on the landscape, required experience, supported content, governance model and target operating costs. They should be compared through explicit requirements rather than treated as interchangeable labels.

Official SAP references