SharePoint-Projekte archivieren: Abnahme und Rollout

Eine technische Archivfunktion löst noch keinen Projektabschluss. Bevor eine SharePoint-Site in das kundenkontrollierte Azure-Archiv wechselt, müssen Fachbereich und IT gemeinsam festlegen, was übernommen wird, wer das Ergebnis abnimmt und wie später auf die Dateien zugegriffen wird.

Für unseren Kunden entstand daraus ein Betriebsmodell mit klaren Kontrollpunkten. Keepit bleibt für operative Wiederherstellungen zuständig. Der Archive Workspace übernimmt abgeschlossene Projektdaten zusätzlich in die vom Kunden administrierte Azure-Subscription.

1. Verantwortlichkeiten vor dem Start klären

Drei Rollen tragen unterschiedliche Entscheidungen:

• Projektverantwortliche bestätigen, dass das Projekt abgeschlossen ist und welche Dokumentation zum finalen Stand gehört.
• Informationsverantwortliche oder Compliance prüfen Legal Holds, Retention-Vorgaben und offene Verfahren.
• IT-Administratoren konfigurieren Scope, Zugriffe, Betriebsmodus und die technische Abnahme.

Vor dem ersten Lauf müssen mindestens diese Fragen beantwortet sein:

• Welche Site und welche Bibliotheken gehören zum Projekt?
• Welche Inhalte sind ausdrücklich ausgeschlossen?
• Wer darf das Archiv später durchsuchen und Dateien herunterladen?
• Wie lange sollen die Archivdaten aufbewahrt werden?
• Welche Kriterien müssen erfüllt sein, bevor SharePoint verändert werden darf?

Die Archivierung repariert keine ungeklärte Datenverantwortung. Sie macht einen abgestimmten Projektabschluss nachvollziehbar.

2. Mit Copy-only beginnen

Der Administrator nimmt die freigegebene Site in den Archive Workspace auf und konfiguriert:

• Site-URL und Anzeigename,
• gewünschte Bibliotheksfilter,
• Priorität und Aktivierung,
• den Betriebsmodus,
• optionales Read-only nach erfolgreichem Abschluss.

Für den Pilot wählen wir Copy-only. SharePoint bleibt dabei vollständig unverändert. Der Kunde kann Archivumfang, Reports, Suche und Downloads prüfen, ohne den bestehenden Arbeitsbereich zu beeinflussen.

Kontrolliertes Löschen und verifizierte Ersatzlinks bleiben bewusste spätere Optionen. Sie werden weder durch einen erfolgreichen Upload noch automatisch nach einer Frist aktiviert.

3. Auftrag starten, Browser schließen

Mit Archivieren legt die Webanwendung einen dauerhaften Vorgang mit eigener Request-ID an. Danach laufen Preflight, Übertragung und technische Prüfung im Hintergrund. Das Browserfenster kann geschlossen werden.

Diese Entkopplung ist besonders für große Sites wichtig. Discovery und Übertragung dürfen nicht von der Lebensdauer einer HTTP-Anfrage abhängen. Auch ein verlorener Response erzeugt bei einem erneuten Klick nicht automatisch einen zweiten Lauf.

Der automatische Preflight ermittelt Bibliotheken, Dateien, Ausschlüsse und Datenvolumen. Kann eine Bibliothek nicht zuverlässig gelesen werden, wird sie nicht als leer gewertet. Der Vorgang stoppt mit einem sichtbaren Befund, bevor eine scheinbar vollständige Archivierung entsteht.

4. Status als Handlungsanweisung lesen

Administratoren benötigen mehr als einen Fortschrittsbalken. Der Status muss zeigen, ob ein Lauf nur aktiv, vollständig abgeschlossen oder fachlich ungeklärt ist.

Statusgruppe	Bedeutung	Nächster Schritt
Pending / Running / Finalizing	Der Hintergrundprozess arbeitet oder prüft den Abschluss.	Warten; keinen parallelen Lauf derselben Site starten.
Succeeded	Alle geplanten Dateien und Pflichtnachweise stimmen überein.	Technische und fachliche Abnahme durchführen.
Partial / Failed	Mindestens ein klar zuordenbarer Teil ist fehlgeschlagen.	Report auf betroffene Bibliothek, Datei und Phase prüfen.
Stalled / Unknown	Zustände oder Nachweise sind unvollständig oder widersprüchlich.	Nicht blind neu starten; Reconciliation und Ursache prüfen.

Ein Worker, der keine Exception mehr wirft, ist noch kein erfolgreicher Archivlauf. Der endgültige Status entsteht erst, wenn Plan, Dateinachweise, Blob-Objekte, Report und Registry zusammenpassen. Die technischen Hintergründe dazu erklären wir in Teil 2.

5. Technische und fachliche Abnahme verbinden

Die technische Prüfung beantwortet, ob der geplante Scope vollständig und bytegenau übernommen wurde. Die fachliche Abnahme beantwortet, ob das Archiv für den späteren Zweck nutzbar ist.

Unsere Abnahme-Checkliste umfasst daher beides:

1. Der Report enthält die erwartete Site und die freigegebenen Bibliotheken.
2. Es bestehen keine fehlgeschlagenen oder ungeklärten Dateien.
3. Datei- und Byteanzahlen sind für den Fachbereich plausibel.
4. Ausgewählte Dateien lassen sich über Suche oder Pfad finden.
5. Einzeldatei- und ZIP-Downloads liefern die erwarteten Inhalte.
6. Die vorgesehenen Administratoren besitzen Zugriff; andere Benutzer nicht.
7. Der fachlich Verantwortliche dokumentiert die Abnahme des Projektarchivs.

Eine Stichprobe ersetzt den technischen Integritätsnachweis nicht. Umgekehrt beweist ein korrekter Hash nicht, dass der richtige fachliche Scope ausgewählt wurde. Erst beide Perspektiven ergeben eine belastbare Übergabe.

6. Das Archiv im Alltag nutzen

Der Archive Workspace zeigt archivierte Sites mit Status, Dateimenge, Datei- und Ordneranzahl sowie Links zu Reports und Inhalten.

Der Archivbrowser stellt aus den technisch eindeutigen, laufbezogenen Objekten wieder eine lesbare Site- und Ordnerstruktur her. Berechtigte Administratoren können:

• nach Dateiname oder Pfad suchen,
• durch Bibliotheken und Ordner navigieren,
• einzelne Dateien herunterladen,
• Ordner als ZIP exportieren,
• vom Archivobjekt zum zugehörigen Report wechseln.

Der Report bleibt die Quelle für den verifizierten Abschlussstatus. Die Browseransicht dient dem operativen Zugriff und ersetzt diese Abnahme nicht.

7. Typische Störungen ohne falschen Erfolg behandeln

Die Entwicklung hat mehrere Fälle sichtbar gemacht, die im Betrieb klare Regeln brauchen:

Situation	Verhalten der Lösung
Der Browser wird nach dem Start geschlossen.	Der persistierte Hintergrundvorgang läuft weiter.
SharePoint oder Azure antwortet vorübergehend nicht.	Begrenzte Retries behandeln technische Fehler; fachliche Konflikte werden nicht weggeretryt.
Ein Zielobjekt existiert bereits.	Create-only verhindert stilles Überschreiben; der Konflikt bleibt sichtbar.
Eine Bibliothek kann nicht vollständig gelesen werden.	Der Preflight scheitert, statt einen leeren Scope zu melden.
Eine Quelldatei ändert sich vor einer geplanten Löschung.	Die destruktive Finalisierung wird blockiert oder der bedingte Löschvorgang erhält die geänderte Datei.
Pflichtnachweise widersprechen einander.	Der Lauf erhält keinen Erfolgsstatus und muss reconciliert werden.

Diese Transparenz ist kein technisches Detail am Rand. Sie entscheidet, ob Projektleitung und IT einem Archivreport vertrauen können.

8. Erst nach der Abnahme über die Quelle entscheiden

Nach einem erfolgreichen Copy-only-Pilot stehen drei Möglichkeiten offen:

1. SharePoint unverändert lassen: Die Azure-Kopie dient als zusätzliche, kundenkontrollierte Archivinstanz.
2. Site auf Read-only setzen: Inhalte bleiben in SharePoint sichtbar, können aber nicht mehr verändert werden.
3. Originale kontrolliert löschen oder durch Links ersetzen: Diese Option benötigt eine separate Freigabe und aktivierte Sicherheitsgrenzen.

SharePoint bietet keine Transaktion über eine gesamte Site. Deshalb bleibt Quellbereinigung eine eigene Risikoklasse. Sie darf erst nach technischer Verifikation, fachlicher Abnahme und dokumentierter Entscheidung erfolgen.

9. In kleinen Wellen ausrollen

Ein sinnvoller Rollout beginnt nicht mit den größten oder kritischsten Sites:

1. eine abgeschlossene, überschaubare Test-Site auswählen,
2. Verantwortliche und Abnahmekriterien festlegen,
3. Copy-only ausführen,
4. Report, Stichprobe, Suche und Downloads gemeinsam prüfen,
5. Erkenntnisse in Bibliotheksfiltern und Betriebsablauf nachziehen,
6. erst danach die nächste Welle freigeben.

Pro Welle sollten Site-Anzahl, Datenvolumen und verantwortliche Personen dokumentiert sein. So bleibt der Betrieb lernfähig, ohne dass einzelne Problemfälle in einer großen Massenmigration verschwinden.

Fazit

Ein kundenkontrolliertes Archiv entsteht nicht allein durch Azure Blob Storage. Es braucht einen fachlich bestätigten Scope, einen browserunabhängigen Prozess, nachvollziehbare Fehlerzustände, technische Evidence und eine dokumentierte Abnahme.

Erst danach besitzt der Kunde nicht nur eine zusätzliche Kopie, sondern einen belastbaren Prozess für die Datenhoheit über abgeschlossene SharePoint-Projekte.

Teil 1 erklärt die Kundenanforderung und die Rolle von Keepit und Microsoft 365 Backup. Teil 2 beschreibt die wichtigsten Engineering-Learnings.

Sie möchten den Ablauf mit einer abgeschlossenen SharePoint-Site testen? Sprechen wir über einen klar abgegrenzten Pilot.