Short answer
An existing SAP archive should not be migrated to the cloud in a Big Bang. A robust migration path starts with an inventory, separates documents, metadata, SAP links and—if applicable—SAP archive files as distinct items, defines a representative pilot, and only permits wave migration and cutover after documented validation. Before decommissioning the legacy system, completeness, retrievability, readability, permissions, analysability and operation in the target state must be demonstrated.
For tax-relevant data, a simple file transfer is not sufficient. The GoBD require that, in the event of a system change, record- and retention-obligated data including metadata, master and transactional data and required links be transferred in a quantitatively and qualitatively equivalent manner. The target system must enable the same analyses; data transformations must not alter content and any changes must be documented.[1]
For overall context see the articles SAP Archiving in the Cloud – Requirements, Risks and Solutions and SAP ArchiveLink vs. CMIS: Why Companies Need to Act Now. This checklist intentionally focuses on operational implementation with pilot, validation and acceptance.
Scope and limits
This checklist describes an approach for migrating an existing SAP-related document or content repository scenario to a cloud target. It is not a migration guide for every SAP release and is not legal or tax advice.
| This page covers | This page does not cover |
|---|---|
| Inventory and controlled migration of existing document and archive stocks | Blanket commitments on GoBD, GDPR, or legal compliance |
| Pilot, validation, cutover and handover to operations | A technical implementation of every ArchiveLink, CMIS, BTP or ILM variant |
| Evidence for documents, metadata, links, accesses and analysability | Assessment of specific retention periods without subject-matter review |
| Decision and acceptance questions for project teams | Commitments regarding functionality, SLA, price or data location of a specific provider |
Before project start: clearly separate archive objects
The term “SAP archive” often refers to different things. These must be inventoried and tested separately before migration.
| Archive object | Typical migration question | Required evidence |
|---|---|---|
| Documents and attachments | Is the original document complete and readable in the target? | Verify retrieval, download, rendering and—if applicable—the original format against the source. |
| Metadata and indexes | Have document type, date, business partner, document number and other search attributes been fully transferred? | Validate field mapping, required fields and samples against the source. |
| SAP links | Does access from the relevant SAP business object lead to the correct document? | Test object and document IDs, link tables or mapping and back-links. |
| Permissions | Do only authorized persons see the content? | Test and log positive and negative permission cases per role. |
| SAP archive files and data archiving | Are these documents, archive files or data managed by separate SAP procedures? | Architecture and process owners define procedures, read paths and retention evidence. |
In ArchiveLink configurations, a content repository, the content repository ID, link tables, retention parameters and user permissions are managed as separate configuration elements.[2] This separation is also important for migration planning: a successfully transferred document is not sufficient if link tables, permissions or retrieval paths do not work afterwards.
Phase 1: Establish governance and the target picture
Before technical implementation, the project needs a shared target picture. This target picture should include not only the future repository but also responsibilities, scope, acceptance criteria and an operations path.
| Decision | Responsible roles | Outcome before Phase 1 |
|---|---|---|
| Which systems, clients and document classes are in scope? | Business unit, SAP architecture, ECM/DMS | Approved scope list including exclusions. |
| Which retention, lock and deletion rules are relevant? | Business unit, Compliance, Tax/Legal owners | Documented business requirements; not a purely technical assumption. |
| Which integration path will be used? | SAP architecture, ECM/DMS, Security | Architectural decision with release and interface status. |
| Who reviews, who approves and who operates? | Project management, Operations, Information security | RACI, escalation path and acceptance signatures. |
| When will the legacy system be shut down? | Project management, Business unit, Operations | Predefined go/no‑go criteria and a fallback plan. |
Phase 2: Perform an inventory
A migration plan based on storage size alone is incomplete. Inventory at least per source system: repository, data volume, document classes, formats, metadata, SAP object reference, permissions, retention status, interfaces and known special cases.
Inventory checklist
- Which SAP systems, releases and clients access the stock?
- Which content repositories, ArchiveLink links or CMIS endpoints are involved?
- Which document types, formats, volumes and growth rates are present?
- Which metadata, indexes, versions and SAP business object links must be preserved?
- Which roles require view, download, archive, administration or audit access?
- Which content has special retention, lock, deletion or data protection requirements?
- Which documents are technically corrupt, duplicate, locked or only retrievable via special processes?
- Which target analyses, exports and audit accesses must be possible after migration?
The result is an inventory protocol with a clear total quantity and traceable subsets. It will later serve as the reference point for pilot and acceptance.
Phase 3: Create migration design and rollback plan
A reliable design specifies how each document class is handled. Good planning answers four questions in particular: How will data be transferred? How will it be logged? How will discrepancies be handled? How does operations remain functional if a wave is aborted?
| Design item | Project decision |
|---|---|
| Migration mode | Migration waves by document class, organization, time range or volume are generally more verifiable than a Big Bang. |
| Data mapping | For each source field there is a documented target rule: keep, transform, discard or handle manually. |
| Links | SAP object, document ID and link are planned as a separate test subject. |
| Error handling | Error classes, retries, duplicate handling, quarantine and responsibilities are defined in advance. |
| Parallel operation | Period, authoritative data source and support path are clearly defined. |
| Rollback | Rollback conditions and restoration paths are tested, not only described. |
Important: For retention-obligated data, content, metadata and required links must remain available in the new system in a quantitatively and qualitatively equivalent manner. Pure data extracts, reports or print files are not sufficient if they cause loss of retention-relevant information.[1]
Phase 4: Run a representative pilot
The pilot is not a mere technical test with a few random files. It must cover typical and risky constellations of the later full stock.
| Pilot dimension | Examples for selection |
|---|---|
| Document class | Invoices, receipts, contracts, attachments, signed or structured formats. |
| Business object | Multiple SAP objects and processes with differing linking and retrieval paths. |
| Data age | Current stocks, long-retention items and older special cases. |
| Volume | Single retrievals, mass documents and large files. |
| Permission | Standard role, restricted role, auditor role and unauthorized access. |
| Exception cases | Missing metadata, duplicate links, corrupted files, locked or deleted objects. |
The pilot ends with an agreed result protocol. Not only successful transfer but also error messages, deviations, retries and timing behavior are recorded.
Phase 5: Validation and acceptance
Validation combines technical tests with business acceptance. It verifies whether the target stock matches the approved inventory and design state.
| Test area | Guiding question | Minimum evidence |
|---|---|---|
| Quantity | Have all planned contents been transferred? | Reconciliation of source and target counts per migration wave. |
| Integrity | Is the content unchanged and readable? | Comparison procedures per project test concept, e.g. hash or file checks where technically feasible. |
| Metadata | Do search and assignment attributes match? | Field-by-field comparison for required and business-critical metadata. |
| SAP link | Does the correct SAP business object open the correct target object? | End-to-end test with documented object and document IDs. |
| Retrievability | Can authorized roles search, display, read and export the content? | Business retrieval and export tests per role. |
| Permissions | Are accesses correctly restricted? | Positive and negative role tests. |
| Operability | Are errors, retries and monitoring under control? | Test protocol for timeouts, errors, retries and support handover. |
| Traceability | Is the process understandable to qualified third parties? | Current procedure, system, user and operations documentation. |
The GoBD require a meaningful and up-to-date procedural documentation. It should make the content, structure, process and results of the procedure comprehensible and also record changes historically.[1]
Phase 6: Go/No‑Go and wave migration
A go-live only makes sense once pilot deviations have been evaluated, owners named and open risks accepted or remediated. Do not define the decision by a blanket percentage value, but by the affected document class, the business transaction, the legal relevance and the rollback risk.
Go-live only with minimum conditions met
- Scope and inventory are approved.
- Pilot and end-to-end tests are documented.
- Critical deviations are fixed or formally accepted.
- Permission, retrieval, export and operational processes are tested.
- The rollback plan is executable and responsibilities are staffed.
- Business unit, IT, operations and required compliance roles have given acceptance.
Afterwards, migrate in controlled waves. Each wave receives its own start, completion and acceptance protocol. An automated wave without quantity, error and completion evidence reduces effort, but not the obligation to provide proof.
Phase 7: Operations after migration
Migration does not end with the last transferred document. The target operation must manage retrieval, monitoring, permissions, changes, incident response, backup/recovery, export and later disposal.
- Conduct regular retrieval and recovery drills.
- Record changes to interfaces, metadata models, roles and operating procedures in a versioned manner.
- Preserve acceptance, test and migration protocols in the evidence archive.
- Decommission the legacy stock only after an approved transition period.
- Re-check relevant retrieval and linking cases when SAP releases or integrations change.
Compact checklist to copy
| Phase | Check question | Status |
|---|---|---|
| Governance | Are scope, roles, target picture and acceptance criteria approved in writing? | ☐ |
| Inventory | Are repositories, document classes, metadata, links, roles and special cases recorded? | ☐ |
| Migration design | Is there mapping, wave plan, error handling, parallel operation and rollback plan? | ☐ |
| Pilot | Does the pilot cover representative and high-risk documents, roles and processes? | ☐ |
| Validation | Have quantity, content, metadata, SAP links, search, export, permissions and operation been tested? | ☐ |
| Acceptance | Have deviations been evaluated and approvals documented? | ☐ |
| Operations | Are monitoring, support, evidence archive, recovery drills and change process in place? | ☐ |
| Legacy system | Is shutdown planned only after the approved transition period? | ☐ |
Next sensible step
Start with a two-hour inventory workshop. The result should not be a general cloud concept but a verifiable list of the affected SAP systems, repositories, document classes, links, roles and acceptance criteria. Based on this, a pilot can be planned that makes actual migration risks visible.
For the SAP transformation project context, RISE with SAP: Consider archiving from the start complements this checklist. For the question of how to distinguish data archiving from document archiving, see ILM and data archiving: How companies can manage their data sustainably.
Sources and professional limits
This page provides technical and organizational guidance. It does not replace tax, legal or data protection advice. Specific retention, deletion, audit and access obligations must be assessed for each company, document class, system landscape and legal domain.
