Kurzantwort
Ein SAP-Bestandsarchiv sollte nicht in einem Big Bang in die Cloud übertragen werden. Ein belastbarer Migrationsweg beginnt mit einer Bestandsinventur, trennt Dokumente, Metadaten, SAP-Verknüpfungen und gegebenenfalls SAP-Archivdateien fachlich voneinander, definiert einen repräsentativen Pilot und lässt erst nach dokumentierter Validierung eine Wellenmigration und den Cutover zu. Vor der Abschaltung des Altsystems müssen Vollständigkeit, Wiederauffindbarkeit, Lesbarkeit, Berechtigungen, Auswertbarkeit und der Betrieb im Zielbild nachgewiesen sein.
Für steuerlich relevante Daten reicht ein bloßer Dateitransfer nicht aus. Die GoBD verlangen bei einem Systemwechsel eine quantitativ und qualitativ gleichwertige Überführung der aufzeichnungs- und aufbewahrungspflichtigen Daten einschließlich Metadaten, Stamm- und Bewegungsdaten sowie erforderlicher Verknüpfungen. Das Zielsystem muss die gleichen Auswertungen ermöglichen; bei Datenumwandlungen dürfen Inhalte nicht verändert werden und die Änderungen sind zu dokumentieren.1
Für die übergeordnete Einordnung helfen die Beiträge SAP Archivierung in der Cloud – Anforderungen, Risiken und Lösungen und SAP ArchiveLink vs. CMIS: Warum Unternehmen jetzt handeln sollten. Diese Checkliste konzentriert sich bewusst auf die operative Umsetzung mit Pilot, Validierung und Abnahme.
Geltungsbereich und Grenze
Diese Checkliste beschreibt ein Vorgehen für die Migration eines bestehenden SAP-nahen Dokumenten- oder Content-Repository-Szenarios in ein Cloud-Zielbild. Sie ist kein Migrationsleitfaden für jedes SAP-Release und keine Rechts- oder Steuerberatung.
| Diese Seite behandelt | Diese Seite behandelt nicht |
|---|---|
| Inventur und kontrollierte Migration bestehender Dokument- und Archivbestände | Pauschale Zusagen zur GoBD-, DSGVO- oder Rechtskonformität |
| Pilot, Validierung, Cutover und Betriebsübergabe | Eine technische Implementierung aller ArchiveLink-, CMIS-, BTP- oder ILM-Varianten |
| Nachweis von Dokumenten, Metadaten, Verknüpfungen, Zugriffen und Auswertbarkeit | Eine Bewertung konkreter Aufbewahrungsfristen ohne fachliche Prüfung |
| Entscheidungs- und Abnahmefragen für Projektteams | Zusagen zu Funktionsumfang, SLA, Preis oder Datenstandort eines bestimmten Anbieters |
Vor dem Projektstart: Archivgegenstände sauber trennen
Der Begriff „SAP-Archiv“ bezeichnet oft unterschiedliche Dinge. Diese müssen vor der Migration getrennt inventarisiert und getestet werden.
| Archivgegenstand | Typische Fragestellung in der Migration | Erforderlicher Nachweis |
|---|---|---|
| Dokumente und Anhänge | Ist das Originaldokument im Ziel vollständig und lesbar? | Abruf, Download, Darstellung und gegebenenfalls Originalformat gegen Quellbestand prüfen. |
| Metadaten und Indizes | Sind Dokumenttyp, Datum, Geschäftspartner, Belegnummer und weitere Suchmerkmale vollständig übertragen? | Feldmapping, Pflichtfelder und Stichproben gegen den Quellbestand validieren. |
| SAP-Verknüpfungen | Führt der Zugriff aus dem relevanten SAP-Geschäftsobjekt zum richtigen Dokument? | Objekt- und Dokument-ID, Linktabellen beziehungsweise Mapping und Rückverlinkung testen. |
| Berechtigungen | Sehen nur berechtigte Personen die Inhalte? | Positive und negative Berechtigungsfälle je Rolle testen und protokollieren. |
| SAP-Archivdateien und Datenarchivierung | Handelt es sich um Dokumente, Archivdateien oder Daten, die über eigene SAP-Verfahren verwaltet werden? | Architektur- und Prozessverantwortliche definieren Verfahren, Lesepfade und Aufbewahrungsnachweise. |
Bei ArchiveLink-Konfigurationen werden ein Content Repository, die Content-Repository-ID, Linktabellen, Aufbewahrungsparameter und Benutzerberechtigungen als getrennte Konfigurationselemente geführt.2 Diese Trennung ist auch für die Migrationsplanung wichtig: Ein erfolgreich übertragenes Dokument genügt nicht, wenn Linktabellen, Berechtigungen oder Retrieval-Pfade anschließend nicht funktionieren.
Phase 1: Governance und Zielbild festlegen
Vor der technischen Umsetzung braucht das Projekt ein gemeinsames Zielbild. Dieses Zielbild enthält nicht nur das künftige Repository, sondern auch Verantwortlichkeiten, Scope, Abnahmebedingungen und einen Betriebspfad.
| Entscheidung | Verantwortliche Rollen | Ergebnis vor Phase 1 |
|---|---|---|
| Welche Systeme, Mandanten und Dokumentklassen gehören in den Scope? | Fachbereich, SAP-Architektur, ECM/DMS | Freigegebene Scope-Liste einschließlich Ausschlüssen. |
| Welche Aufbewahrungs-, Sperr- und Löschregeln sind relevant? | Fachbereich, Compliance, Steuer-/Rechtsverantwortliche | Dokumentierte fachliche Anforderungen; keine rein technische Annahme. |
| Welcher Integrationsweg wird verwendet? | SAP-Architektur, ECM/DMS, Security | Architekturentscheidung mit Release- und Schnittstellenstand. |
| Wer prüft, wer gibt frei und wer betreibt? | Projektleitung, Betrieb, Informationssicherheit | RACI, Eskalationsweg und Abnahmesignaturen. |
| Wann wird das Altsystem abgeschaltet? | Projektleitung, Fachbereich, Betrieb | Vorab definierte Go-/No-Go-Kriterien und Rückfallplan. |
Phase 2: Bestandsinventur durchführen
Eine Migrationsplanung auf Basis von Speichergröße allein ist unvollständig. Inventarisieren Sie pro Quellsystem mindestens Repository, Datenvolumen, Dokumentklassen, Formate, Metadaten, SAP-Objektbezug, Berechtigungen, Aufbewahrungsstatus, Schnittstellen und bekannte Sonderfälle.
Inventur-Checkliste
- Welche SAP-Systeme, Releases und Mandanten greifen auf den Bestand zu?
- Welche Content Repositories, ArchiveLink-Verknüpfungen oder CMIS-Endpunkte sind beteiligt?
- Welche Dokumenttypen, Formate, Volumina und Wachstumsraten liegen vor?
- Welche Metadaten, Indizes, Versionen und SAP-Geschäftsobjekt-Links müssen erhalten bleiben?
- Welche Rollen benötigen Anzeige, Download, Archivierung, Administration oder Prüfzugriff?
- Welche Inhalte haben besondere Aufbewahrungs-, Sperr-, Lösch- oder Datenschutzanforderungen?
- Welche Dokumente sind technisch fehlerhaft, doppelt, gesperrt oder nur über Sonderprozesse abrufbar?
- Welche Zielauswertungen, Exporte und Prüfzugriffe müssen nach der Migration möglich sein?
Das Ergebnis ist ein Inventurprotokoll mit einer eindeutigen Gesamtmenge und nachvollziehbaren Teilmengen. Es wird später zum Bezugspunkt für Pilot und Abnahme.
Phase 3: Migrationsdesign und Rückfallplan erstellen
Ein belastbares Design legt die Behandlung jeder Dokumentklasse fest. Gute Planung beantwortet insbesondere vier Fragen: Wie wird übertragen? Wie wird protokolliert? Wie werden Differenzen behandelt? Wie bleibt der Betrieb handlungsfähig, falls eine Welle abgebrochen wird?
| Designpunkt | Entscheidung im Projekt |
|---|---|
| Migrationsmodus | Migrationswellen nach Dokumentklasse, Organisation, Zeitbereich oder Volumen sind in der Regel besser prüfbar als ein Big Bang. |
| Datenmapping | Für jedes Quellfeld gibt es eine dokumentierte Zielregel: übernehmen, transformieren, verwerfen oder manuell behandeln. |
| Verknüpfungen | SAP-Objekt, Dokument-ID und Link werden als separater Testgegenstand geplant. |
| Fehlerbehandlung | Fehlerklassen, Wiederanlauf, Dublettenbehandlung, Quarantäne und Verantwortliche werden vorab festgelegt. |
| Parallelbetrieb | Zeitraum, Datenführerschaft und Supportweg sind klar definiert. |
| Rückfall | Rückfallbedingungen und Wiederherstellungsweg werden getestet, nicht nur beschrieben. |
Wichtig: Bei aufbewahrungspflichtigen Daten müssen Inhalte, Metadaten und erforderliche Verknüpfungen im neuen System quantitativ und qualitativ gleichwertig verfügbar bleiben. Reine Datenextrakte, Reports oder Druckdateien reichen nicht aus, wenn dadurch aufbewahrungspflichtige Informationen verloren gehen.1
Phase 4: Einen repräsentativen Pilot durchführen
Der Pilot ist keine reine technische Probe mit wenigen zufälligen Dateien. Er muss typische und riskante Konstellationen des späteren Gesamtbestands abdecken.
| Pilotdimension | Beispiele für die Auswahl |
|---|---|
| Dokumentklasse | Rechnungen, Belege, Verträge, Anhänge, signierte oder strukturierte Formate. |
| Geschäftsobjekt | Mehrere SAP-Objekte und Prozesse mit abweichenden Verknüpfungs- und Abrufpfaden. |
| Datenalter | Aktuelle Bestände, lange aufzubewahrende Inhalte sowie ältere Sonderfälle. |
| Volumen | Einzelabrufe, Massendokumente und große Dateien. |
| Berechtigung | Standardrolle, eingeschränkte Rolle, Prüferrolle und unberechtigter Zugriff. |
| Ausnahmefälle | Fehlende Metadaten, doppelte Links, beschädigte Dateien, gesperrte oder gelöschte Objekte. |
Der Pilot endet mit einem abgestimmten Ergebnisprotokoll. Nicht nur die erfolgreiche Übertragung, sondern auch Fehlermeldungen, Abweichungen, Wiederanlauf und Zeitverhalten werden erfasst.
Phase 5: Validierung und Abnahme
Die Validierung verbindet technische Tests mit fachlicher Abnahme. Sie prüft, ob der Zielbestand mit dem freigegebenen Inventur- und Designstand übereinstimmt.
| Prüffeld | Leitfrage | Mindestnachweis |
|---|---|---|
| Menge | Sind alle vorgesehenen Inhalte übertragen? | Abgleich von Quell- und Zielmengen je Migrationswelle. |
| Integrität | Ist der Inhalt unverändert und lesbar? | Vergleichsverfahren nach dem projektspezifischen Testkonzept, etwa Hash- oder Dateiprüfung, soweit technisch vorgesehen. |
| Metadaten | Stimmen Such- und Zuordnungsmerkmale? | Feldvergleich für Pflicht- und fachlich kritische Metadaten. |
| SAP-Verknüpfung | Öffnet das richtige SAP-Geschäftsobjekt das richtige Zielobjekt? | End-to-End-Test mit dokumentierten Objekt- und Dokument-IDs. |
| Wiederauffindbarkeit | Können berechtigte Rollen die Inhalte suchen, anzeigen, lesen und exportieren? | Fachliche Abruf- und Exporttests je Rolle. |
| Berechtigung | Sind Zugriffe korrekt begrenzt? | Positive und negative Rollentests. |
| Betriebsfähigkeit | Werden Fehler, Wiederanlauf und Monitoring beherrscht? | Testprotokoll für Timeout, Fehler, Retry und Supportübergabe. |
| Nachvollziehbarkeit | Ist der Ablauf für sachverständige Dritte verständlich? | Aktuelle Verfahrens-, System-, Anwender- und Betriebsdokumentation. |
Die GoBD fordern eine aussagefähige und aktuelle Verfahrensdokumentation. Sie soll Inhalt, Aufbau, Ablauf und Ergebnisse des Verfahrens nachvollziehbar machen und auch Änderungen historisch abbilden.1
Phase 6: Go-/No-Go und Wellenmigration
Ein Go-live ist erst sinnvoll, wenn die Pilotabweichungen bewertet, Verantwortliche benannt und offene Risiken akzeptiert oder behoben sind. Definieren Sie die Entscheidung nicht anhand eines pauschalen Prozentwerts, sondern anhand der betroffenen Dokumentklasse, des Geschäftsvorfalls, der rechtlichen Relevanz und des Rückfallrisikos.
Go-live nur bei erfüllten Mindestbedingungen
- Scope und Inventur sind freigegeben.
- Pilot- und End-to-End-Tests sind dokumentiert.
- Kritische Abweichungen sind behoben oder formal akzeptiert.
- Berechtigungs-, Abruf-, Export- und Betriebsprozesse sind getestet.
- Der Rückfallplan ist ausführbar und Verantwortlichkeiten sind besetzt.
- Fachbereich, IT, Betrieb und erforderliche Compliance-Rollen haben die Abnahme erteilt.
Danach erfolgt die Migration in kontrollierten Wellen. Jede Welle erhält ein eigenes Start-, Abschluss- und Abnahmeprotokoll. Eine automatisierte Welle ohne Mengen-, Fehler- und Abschlussnachweis reduziert zwar Aufwand, aber nicht die Nachweispflicht.
Phase 7: Betrieb nach der Migration
Die Migration endet nicht mit dem letzten übertragenen Dokument. Der Zielbetrieb muss Retrieval, Monitoring, Berechtigungen, Änderungen, Incident Response, Backup/Wiederherstellung, Export und spätere Aussonderung beherrschen.
- Führen Sie regelmäßige Abruf- und Wiederherstellungsproben durch.
- Halten Sie Veränderungen an Schnittstellen, Metadatenmodellen, Rollen und Betriebsverfahren versioniert fest.
- Bewahren Sie Abnahme-, Test- und Migrationsprotokolle im Nachweisarchiv auf.
- Schalten Sie den Altbestand erst nach einer freigegebenen Übergangsphase ab.
- Prüfen Sie bei SAP-Release- oder Integrationsänderungen erneut die relevanten Abruf- und Verknüpfungsfälle.
Kompakte Checkliste zum Kopieren
| Phase | Prüffrage | Status |
|---|---|---|
| Governance | Sind Scope, Rollen, Zielbild und Abnahmekriterien schriftlich freigegeben? | ☐ |
| Inventur | Sind Repositorys, Dokumentklassen, Metadaten, Verknüpfungen, Rollen und Sonderfälle erfasst? | ☐ |
| Migrationsdesign | Gibt es Mapping, Wellenplan, Fehlerbehandlung, Parallelbetrieb und Rückfallplan? | ☐ |
| Pilot | Deckt der Pilot repräsentative und risikoreiche Dokumente, Rollen und Prozesse ab? | ☐ |
| Validierung | Sind Menge, Inhalt, Metadaten, SAP-Links, Suche, Export, Berechtigung und Betrieb getestet? | ☐ |
| Abnahme | Sind Abweichungen bewertet und die Freigaben dokumentiert? | ☐ |
| Betrieb | Sind Monitoring, Support, Nachweisarchiv, Wiederherstellungsproben und Change-Prozess eingerichtet? | ☐ |
| Altsystem | Ist die Abschaltung erst nach der freigegebenen Übergangsphase vorgesehen? | ☐ |
Nächster sinnvoller Schritt
Starten Sie mit einem zweistündigen Inventur-Workshop. Ergebnis sollten kein allgemeines Cloud-Konzept, sondern eine prüfbare Liste der betroffenen SAP-Systeme, Repositorys, Dokumentklassen, Verknüpfungen, Rollen und Abnahmekriterien sein. Auf dieser Basis lässt sich ein Pilot planen, der tatsächliche Migrationsrisiken sichtbar macht.
Für den Projektkontext von SAP-Transformationen ergänzt RISE with SAP: Archivierung von Anfang an mitdenken diese Checkliste. Für die Frage, wie Datenarchivierung und Dokumentenarchivierung voneinander abzugrenzen sind, steht der Beitrag ILM und Datenarchivierung: Wie Unternehmen ihre Daten nachhaltig verwalten können bereit.
Quellen und fachliche Grenzen
Diese Seite bietet technische und organisatorische Orientierung. Sie ersetzt keine Steuer-, Rechts- oder Datenschutzberatung. Die konkreten Aufbewahrungs-, Lösch-, Prüf- und Zugriffspflichten müssen je Unternehmen, Dokumentklasse, Systemlandschaft und Rechtsgebiet bewertet werden.
