25 TB SharePoint-Migration: Warum ShareGate & SPMT hier nicht mehr reichen

Im ersten Teil dieser Serie haben wir argumentiert, warum große Migrationen selten 1:1 laufen sollten. Heute wird es konkret: Warum haben wir für eine 25-TB-Migration von SharePoint 2016 nach SharePoint Online eine eigene Migrations-Pipeline gebaut, statt ShareGate oder das Microsoft SharePoint Migration Tool (SPMT) zu verwenden?

Spoiler: Nicht, weil diese Tools schlecht wären. Sondern weil unsere Anforderungen keine Kopier-Anforderungen waren, sondern Transformations-Anforderungen.

Die Ausgangslage

• Über 25 Terabyte Dokumentbestand in SharePoint 2016 On-Premises
• Mehr als 130 Großprojekte, jedes mit eigener Websitesammlung, eigenen Strukturen, teils hunderten Bibliotheken
• Millionen Dateien — und noch mehr Versionen
• Ziel: ein konzernweit geteilter SharePoint-Online-Tenant mit einheitlicher, neu designter Informationsarchitektur

Und die eigentliche Anforderung: Die Inhalte sollen nicht am alten Ort ankommen, sondern in einer neuen Struktur, mit neuen Inhaltstypen, neuen Metadaten und konsolidierten Dokumentklassen.

Was Standard-Tools sehr gut können

ShareGate, SPMT und vergleichbare Produkte sind exzellent, wenn das Mapping im Wesentlichen lautet: Quelle → Ziel, gleiche Struktur, gleiche Felder. Sie bringen fertige Oberflächen, Scheduling, Berichte und solide Fehlerbehandlung mit. Für die Mehrheit aller Migrationen sind sie die richtige Wahl — das sagen wir auch unseren Kunden.

Wo es bei uns gebrochen ist

1. Feldweise Transformation mit Fallback-Logik

Unsere Dokumentklassen („Unterlagenarten”) existierten in der Quelle in dutzenden Varianten — historische Schreibweisen, projektspezifische Sonderformen, umbenannte Terms. Am Ziel gibt es ein konsolidiertes, globales Vokabular. Das Mapping ist keine simple Tabelle, sondern eine Regelkette mit Fallbacks:

1. Exakter Match auf konsolidierten Zielwert        → nehmen
2. Match über historische Synonym-Tabelle           → mappen + protokollieren
3. Match über Normalisierung (Casing, Sonderzeichen) → mappen + protokollieren
4. Kein Match                                        → definierter Fallback-Wert
                                                       + Eintrag ins Nacharbeits-Register

Entscheidend ist Punkt 4: Kein Dokument darf am Mapping scheitern, aber jeder Fallback muss auditierbar sein, damit die Fachabteilung gezielt nacharbeiten kann. Diese Anforderung — lückenloses Mapping-Protokoll als Abnahme-Artefakt — bietet kein Standard-Tool.

2. Taxonomie wird zu Text, Choice und Lookup

Millionen projektspezifischer Terms passen nicht in den geteilten Term Store (Details in Teil 4). Also müssen Managed-Metadata-Felder beim Migrieren den Feldtyp wechseln — inklusive der Bereinigung von Wire-Format-Artefakten wie ;#-Präfixen und |guid-Suffixen, die sonst als Textmüll am Ziel landen. Feldtyp-Transformation dieser Art ist in Standard-Tools bestenfalls rudimentär.

3. Versions-Deduplizierung als Business Case

In der Quelle erzeugte jede Metadaten-Änderung eine neue Dateiversion — bei identischem Inhalt. Über 25 TB gerechnet stecken darin Terabytes an byte-identischen Duplikaten, die in SharePoint Online dauerhaft Speicherkosten verursachen würden. Unsere Pipeline erkennt identische Versionsketten per Hash-Vergleich und migriert nur inhaltlich unterschiedliche Versionen (Teil 5). Kein uns bekanntes Standard-Tool dedupliziert Versionen inhaltbasiert.

4. Durchsatz und Kontrolle bei 25 TB

Bei dieser Datenmenge zählt jede Stufe der Pipeline: parallelisierte Quell-Downloads mit Verbindungs-Gating, gebatchte Migrationspakete mit Budget-Steuerung (Items, Versionen, Bytes pro Paket), paralleler Blob-Upload, Throttling-Telemetrie. Wir brauchten die Stellschrauben im Code, nicht hinter einer UI.

5. Abnahme mit Beweis

Die Frage „Ist wirklich alles drüben?” beantworten wir nicht mit einem Tool-Report, sondern mit einem eigenen Parity-Check: Jede Quelldatei wird gegen das Ziel abgeglichen — Ergebnis missing=0 und SizeMismatch=0 pro Projekt, bei Verdachtsfällen SHA256-Forensik. Diese Nachweise sind Teil der formalen Projektabnahme. Ein Migrationsjob, der „grün” meldet, ist noch kein Beweis — das haben uns string-codierte Zähler in Job-Reports und stille Teilfehler mehrfach gezeigt.

Die Architektur unserer Pipeline

Ein paar Design-Entscheidungen, die sich bewährt haben:

• Staging als Wahrheit: Alles wird zuerst vollständig aus der Quelle extrahiert und lokal versioniert abgelegt. Transformation und Paketierung arbeiten gegen das Staging — die Quelle wird nur lesend berührt, und jeder Schritt ist wiederholbar.
• Resume überall: Bei 25 TB wird etwas abbrechen. Jede Phase muss idempotent wiederaufsetzbar sein — inklusive Re-Attach an laufende Migration-Jobs nach einem Prozess-Neustart.
• Fail-fast bei Authentifizierung: Wiederholte Auth-Retries gegen On-Prem-Systeme können Accounts sperren. Ein Auth-Fehler bricht sofort ab, statt in einer Retry-Schleife zu landen.
• Verifikation als erzwungenes Gate: Der Abnahme-Check ist kein optionales Skript, sondern in die Pipeline eingebaut — ohne bestandene Pflicht-Checks gibt es kein „fertig”.

Wann lohnt sich der Eigenbau?

Ehrliche Antwort: selten. Eine eigene Pipeline lohnt sich, wenn mindestens zwei dieser Punkte zutreffen:

1. Transformation statt Kopie (Struktur, Feldtypen, Vokabular)
2. Datenmenge, bei der Speicher- oder Laufzeitoptimierung echtes Geld spart
3. Compliance-Anforderungen an beweisbare Vollständigkeit
4. Grenzwert-Konflikte, die Umbauten erzwingen (Term Store, Lookups, Thresholds)

Trifft nur einer zu, prüfen Sie zuerst, ob ein Standard-Tool plus Pre-/Post-Processing-Skripte reicht. Der Eigenbau ist mächtig — aber er bedeutet, dass Sie auch die Fehlerbilder der Migration API selbst beherrschen müssen. Genau darum geht es im nächsten Teil.

---

Ihre Migration sprengt den Rahmen klassischer Tools? Wir haben eine komplette Migrations-Pipeline für den Enterprise-Maßstab gebaut und teilen unsere Erfahrung gerne — von der Machbarkeitsanalyse bis zur Umsetzung. Sprechen Sie mit uns.

Alle Teile der Serie:

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