Versionshistorie intelligent migrieren: Weniger Speicher, gleiche Nachvollziehbarkeit

SharePoint-Online-Speicher kostet — dauerhaft, pro Gigabyte, jeden Monat. Wer 25 Terabyte migriert (unsere Serie ab Teil 1), sollte vorher eine unbequeme Frage stellen: Wie viele dieser Bytes sind eigentlich identische Kopien voneinander?

Bei uns war die Antwort: erschreckend viele. Und der Grund ist ein Klassiker.

Das Problem: Jede Metadaten-Änderung wird eine „neue Datei”

In der SharePoint-2016-Quellumgebung erzeugte praktisch jede Metadaten-Pflege eine neue Dateiversion — Dokumentklasse nachgetragen: neue Version. Zuständigkeit geändert: neue Version. Workflow-Status aktualisiert: neue Version. Der Dateiinhalt selbst: byte-identisch.

Eine typische Versionskette sah so aus:

v1.0  Upload                    50 MB   ← echter Inhalt
v2.0  Metadaten ergänzt         50 MB   ← identische Bytes
v3.0  Status geändert           50 MB   ← identische Bytes
v4.0  inhaltliche Überarbeitung 52 MB   ← echter neuer Inhalt
v5.0  Metadaten korrigiert      52 MB   ← identische Bytes

Fünf Versionen, 254 MB — aber nur zwei inhaltlich unterschiedliche Dokumente (102 MB). Multipliziert über Millionen Dateien und zehn Jahre Projekthistorie stecken in so einem Bestand Terabytes an redundanten Bytes, die in SharePoint Online für immer bezahlt würden.

Die Lösung: Hash-basierte Versions-Deduplizierung

Unsere Migrations-Pipeline vergleicht beim Extrahieren die Inhalte der Versionskette per Hash und migriert nur Versionen, die sich inhaltlich unterscheiden:

Quelle: v1 ──> v2 ──> v3 ──> v4 ──> v5
Hash:    A      A      A      B      B

Ziel:   v1 (Inhalt A) ──> v2 (Inhalt B)

Konzeptionell:

var toMigrate = new List<SourceVersion>();
string? lastHash = null;

foreach (var version in chain.OrderBy(v => v.VersionNumber))
{
    var hash = await ComputeContentHashAsync(version);
    if (hash != lastHash)          // nur inhaltlich NEUE Versionen
    {
        toMigrate.Add(version);
        lastHash = hash;
    }
}
// Die jeweils letzte Version einer Hash-Gruppe trägt die finalen Metadaten —
// so bleibt der fachlich aktuelle Metadatenstand erhalten.

Wichtig: Die Metadaten der neuesten Version gewinnen. Die Metadaten-Zwischenstände der übersprungenen Versionen sind fast immer Pflege-Rauschen — aber genau das muss man mit der Fachseite explizit vereinbaren, nicht stillschweigend entscheiden.

Was man mit der Fachabteilung klären muss

Deduplizierung ist eine fachliche Entscheidung mit technischer Umsetzung, nicht umgekehrt:

1. Versionsnummern verschieben sich. Aus v5.0 wird am Ziel v2.0. Wer Dokumente in Berichten oder Bescheiden mit „Version 5.0” referenziert hat, braucht eine Kommunikationsregel.
2. Audit-Anforderungen prüfen. Gibt es Dokumentklassen mit regulatorischer Pflicht zur lückenlosen Versionskette? Dann werden diese ausgenommen — Deduplizierung ist eine Regel pro Bibliothek oder Klasse, kein globaler Schalter.
3. Nachweisbarkeit. Jede Dedup-Entscheidung wird protokolliert: welche Quellversionen zu welcher Zielversion zusammengefasst wurden, mit Hashes. Als bei der Abnahme über 2.000 „abweichende Versionslabels” auffielen, konnten wir jede einzelne als absichtliche, hash-belegte Deduplizierung ausweisen — der Unterschied zwischen „Feature” und „Befund” ist das Protokoll.

Die Migration-API-Falle: der Zwei-Versionen-Bug

Ausgerechnet die Deduplizierung triggert einen der ärgerlichsten Service-Bugs der Migration API: Dateien mit genau zwei Versionen verlieren beim Import ihre Historie — beide kommen als v1.0 an. Bei einer und bei drei+ Versionen funktioniert alles.

Und was produziert Hash-Deduplizierung besonders häufig? Ketten mit genau zwei verbleibenden Versionen.

Unsere Antwort ist eine explizite Two-Version-Strategie als konfigurierbare Option: In betroffenen Fällen entscheiden wir bewusst, ob die ältere Version als eigenständige Historie erhalten bleiben muss (dann wird der Import angepasst) oder ob der aktuelle Stand fachlich genügt. Die Entscheidung ist dokumentiert — nicht dem Service-Bug überlassen.

Ergebnis

• Deutlich reduzierte Zielmenge — der Speicher-Business-Case trägt einen relevanten Teil der Projektkosten.
• Schnellere Migration — jede nicht migrierte Version spart Download, Verschlüsselung, Upload und Import-Zeit.
• Saubere Abnahme — Parity-Check auf Datei-Ebene (missing=0), Hash-Protokoll auf Versions-Ebene.

Empfehlungen für Ihr Projekt

1. Versions-Analyse vor der Migration: Wie viel Prozent Ihres Bestands sind byte-identische Versionsduplikate? Die Zahl entscheidet, ob sich der Aufwand lohnt — bei uns war sie zweistellig.
2. Dedup-Regeln fachlich abstimmen und Ausnahmen (Compliance-Klassen) definieren.
3. Protokoll als First-Class-Artefakt bauen — es ist Ihr Abnahme-Beweis.
4. Zwei-Versionen-Ketten explizit behandeln, sonst behandelt sie der Microsoft-Bug für Sie.

---

Sie möchten wissen, wie viel SharePoint-Online-Speicher in Ihrem Migrationsbestand steckt, der nie bezahlt werden müsste? Wir analysieren das gerne — und bringen die Pipeline mit, die es umsetzt. Kontaktieren Sie uns.

Alle Teile der Serie:

1. Warum keine 1:1-Migration
2. 25 TB SharePoint-Migration: Warum Standard-Tools nicht reichen
3. Die SharePoint Migration API in der Praxis
4. Term Store am Limit: Taxonomie-Migration im geteilten Tenant
5. Versionshistorie intelligent migrieren (dieser Beitrag)
6. Provisioning im Großformat: PnP, Throttling, Berechtigungen