Das größte Risiko einer SharePoint-Migration ist nicht der Datenverlust. Es ist die erfolgreiche Migration von jahrelangen Fehlentscheidungen.
Wer seinen Migrationsplan auf Kopieren → Einfügen → Go-Live reduziert, trägt die Probleme von gestern in den Arbeitsplatz von morgen. Wir begleiten gerade eine der größten SharePoint-Migrationen Österreichs — über 25 Terabyte, mehr als 130 Großprojekte, Millionen von Dokumenten und Versionen — von SharePoint 2016 On-Premises nach SharePoint Online. Und die wichtigste Entscheidung fiel ganz am Anfang: Das wird keine 1:1-Migration.
In diesem Beitrag — dem Auftakt unserer Serie über Enterprise-SharePoint-Migrationen — erklären wir, wann Lift-and-Shift funktioniert, wann nicht, und welche fachlichen und technischen Kriterien die Entscheidung treiben.
Wann eine 1:1-Migration völlig in Ordnung ist
Vorweg: 1:1-Migration ist kein Schimpfwort. Sie ist die richtige Wahl, wenn:
- die Informationsarchitektur aktuell und akzeptiert ist — Benutzer finden, was sie suchen,
- Berechtigungen nachvollziehbar sind und dem heutigen Organigramm entsprechen,
- die genutzten Features 1:1 in SharePoint Online existieren (keine Farm-Solutions, keine serverseitigen Anpassungen),
- die Datenmenge und Strukturgröße innerhalb der SharePoint-Online-Grenzwerte liegen.
In diesem Fall gilt: Standard-Tools nehmen, migrieren, fertig. Jeder zusätzliche Umbau ist Projektrisiko ohne Nutzen.
Wann Lift-and-Shift scheitert — die fachliche Sicht
In gewachsenen On-Premises-Umgebungen sehen wir immer wieder dieselben Muster:
1. Jedes Projekt hat sein eigenes Universum. Über Jahre entstehen pro Großprojekt eigene Websitesammlungen, eigene Inhaltstypen, eigene Terminologie, eigene Ablagelogik. Was damals pragmatisch war, ist heute ein Wildwuchs, den niemand mehr konsolidiert durchsuchen oder auswerten kann.
2. Metadaten, die keiner mehr pflegt. Felder, die vor zehn Jahren eingeführt wurden, sind halb befüllt, inkonsistent benannt oder bedeuten in Projekt A etwas anderes als in Projekt B. Eine 1:1-Migration konserviert diesen Zustand — inklusive der Suchergebnisse, die daraus resultieren.
3. Berechtigungs-Archäologie. Individuelle Berechtigungen auf Ordner- und Item-Ebene, verwaiste Gruppen, Benutzer, die das Unternehmen längst verlassen haben. Wer das mitmigriert, migriert ein Audit-Problem.
4. Dokumentklassen ohne gemeinsames Vokabular. Wenn dieselbe Dokumentart in 130 Projekten unter 15 verschiedenen Bezeichnungen läuft, ist die Migration der einzige Zeitpunkt, an dem eine Konsolidierung realistisch bezahlbar ist. Danach fasst diese Datenbestände nie wieder jemand an.
Der fachliche Kernsatz: Eine Migration ist der beste (und oft letzte) Zeitpunkt, Ihre Informationsarchitektur zu reparieren. Nicht, weil es technisch nötig wäre — sondern weil Budget, Aufmerksamkeit und Management-Rückhalt genau dann vorhanden sind.
Wann Lift-and-Shift scheitert — die technische Sicht
Noch häufiger übersehen: Es gibt Konstellationen, in denen eine 1:1-Migration technisch gar nicht möglich ist, weil SharePoint Online andere Grenzwerte hat als Ihre On-Premises-Farm. Ein paar Beispiele aus unserem Projekt:
Term Store: Der geteilte Tenant ändert die Spielregeln. On-Premises hatte jedes Großprojekt eigene, riesige Termsets — räumliche Verortung, Baustoffkataloge, Anlagenstrukturen. In Summe: Millionen von Terms. Der SharePoint-Online-Term-Store ist aber pro Tenant auf 1 Million Terms begrenzt — und dieser Tenant wird im Konzern geteilt. Die alte Architektur „jedes Projekt bringt seine eigene Taxonomie mit” ist in der Cloud schlicht nicht abbildbar. (Details in Teil 4 unserer Serie.)
Lookup-Listen und Spalten-Limits. Viele Taxonomiefelder wurden historisch über Lookup-Listen gelöst — und SharePoint Online begrenzt Lookup-Spalten pro Abfrage. Große Strukturen laufen hier gegen eine Wand, die es on-premises so nicht gab.
List View Threshold, URL-Längen, Strukturtiefe. 5.000er-Schwellwert, 400-Zeichen-Pfadgrenzen, Ordnerhierarchien aus einer Zeit, in der Metadaten-Navigation noch keine Option war.
Speicherkosten. On-Premises war Speicher ein einmaliger Hardware-Posten. In SharePoint Online zahlen Sie pro Gigabyte — dauerhaft. Wer 25 TB migriert, in denen unzählige Dokumentversionen stecken, die sich nur in Metadaten unterscheiden, bezahlt jahrelang für redundante Bytes. Versionskonsolidierung ist bei dieser Größenordnung kein Nice-to-have, sondern ein Business Case. (Teil 5 der Serie.)
Die Entscheidungsmatrix
| Kriterium | 1:1 möglich | Restrukturierung nötig |
|---|---|---|
| Informationsarchitektur | aktuell, akzeptiert | historisch gewachsen, inkonsistent |
| Metadaten/Inhaltstypen | einheitlich, gepflegt | projektspezifischer Wildwuchs |
| Taxonomie | innerhalb Term-Store-Limits | eigene Termsets pro Projekt, geteilter Tenant |
| Berechtigungen | gruppenbasiert, dokumentiert | item-level, verwaist, unklar |
| Versionsbestand | schlank | aufgebläht durch Metadaten-only-Versionen |
| Datenmenge | Standard-Tool-tauglich | mehrere TB mit Transformationsbedarf |
Sobald zwei oder mehr Zeilen rechts landen, ist „Copy → Paste → Go-Live” keine Migrationsstrategie mehr, sondern Problemverschiebung.
Was stattdessen? Migration als Transformation
Bei unserem 25-TB-Projekt bedeutet das konkret:
- Neue Site- und Bibliotheksstruktur nach einheitlichem Schema statt gewachsener Einzellösungen
- Neue, konsolidierte Inhaltstypen und Metadatenfelder — zentral provisioniert statt pro Projekt gebastelt
- Taxonomie-Transformation: projektspezifische Termsets werden zu Text-, Choice- und Lookup-Feldern mit sauberem Mapping
- Konsolidierung der Dokumentklassen („Unterlagenarten”) mit definierten Fallback-Regeln für historische Sonderfälle
- Versions-Deduplizierung: byte-identische Versionsketten werden erkannt und nicht redundant migriert
- Verifizierbare Vollständigkeit: jede Quelldatei wird gegen das Ziel geprüft — Abnahme mit Beweis statt Bauchgefühl
Dass Standard-Migrationstools (ShareGate, SPMT & Co.) bei diesen Anforderungen aussteigen und warum wir direkt auf der SharePoint Migration API aufgesetzt haben, lesen Sie in den nächsten Teilen dieser Serie.
Fazit
Die Frage ist nicht „Wie bekommen wir alles nach SharePoint Online?”, sondern: „Was davon soll die nächsten zehn Jahre unser Arbeitsplatz sein?” Eine Migration, die nur kopiert, beantwortet die falsche Frage.
Sie stehen vor einer großen SharePoint-Migration, die mit klassischen Tools nicht abbildbar ist — sei es wegen Datenmenge, Restrukturierung oder Grenzwerten in SharePoint Online? Wir haben genau das gebaut und unterstützen Sie gerne: von der Migrationsstrategie bis zur eigenen Migrations-Pipeline. Kontaktieren Sie uns.
Alle Teile der Serie:
- Warum keine 1:1-Migration (dieser Beitrag)
- 25 TB SharePoint-Migration: Warum Standard-Tools nicht reichen
- Die SharePoint Migration API in der Praxis
- Term Store am Limit: Taxonomie-Migration im geteilten Tenant
- Versionshistorie intelligent migrieren
- Provisioning im Großformat: PnP, Throttling, Berechtigungen
- SharePoint Migration
- SharePoint Online
- Informationsarchitektur
- Digital Workplace
- Governance