Migration nach SharePoint Online: Umzug ohne Datengrab-Import

Falls du noch einen Grund für den Umzug gesucht hast: Er ist vorbei. Am 14. Juli 2026 endete der erweiterte Support für SharePoint Server 2016 und 2019 — seitdem laufen diese Farmen ohne Sicherheitsupdates, und ein ESU-Rettungsring wie bei Windows Server existiert für SharePoint schlicht nicht. Die Frage ist also nicht mehr ob, sondern wie. Und beim Wie entscheidet sich, ob du in der Cloud neu anfängst oder dein Datengrab mit neuer URL weiterbetreibst. Dieser Artikel zeigt die fünf Phasen einer sauberen Migration, die typischen Stolpersteine — und wie mit CosyTrack.Migrate aus alter Ordnerlogik brauchbare Metadaten werden.

Der Kardinalfehler: Lift-and-Shift

Die verlockendste Migrationsstrategie ist zugleich die teuerste: alles einfach rüberkopieren. „Die Struktur kennen unsere Leute, das Aufräumen machen wir später“ — dieser Satz hat mehr Cloud-Projekte ruiniert als jede technische Panne. Denn erstens räumt „später“ nie jemand auf. Zweitens schlägt die Technik zurück: Vierzehn Ordnerebenen reißen das 400-Zeichen-Pfadlimit, Sonderzeichen und Endungs-Leerzeichen blockieren den Upload, und die liebevoll gepflegte Ordnerlogik ist in einer Welt aus Suche und Metadaten schlicht wertlos. Und drittens zahlst du ab Tag eins Microsoft-365-Lizenzen für dieselbe Unauffindbarkeit wie vorher:

Skizze 1: Oben der Lift-and-Shift ins Datengrab mit neuer URL, unten der saubere Weg in fünf Phasen — mit der Kernzahl: typischerweise wandern nur 30–50 Prozent des Bestands mit.

Die fünf Phasen einer sauberen Migration

Der tragfähige Weg ist unspektakulär und in jeder Größenordnung derselbe — nur die Dauer skaliert. Erst wird gemessen statt geschätzt, dann bereinigt statt gehofft, dann das Ziel gebaut, bevor irgendetwas fließt. Die eigentliche Datenbewegung ist am Ende der langweiligste Teil, und genau so soll es sein:

Zwei Punkte aus der Tabelle verdienen Nachdruck, weil sie in fast jedem Projekt unterschätzt werden. Die Zielarchitektur kommt vor der Migration — flache Sites, Bibliotheken mit Inhaltstypen, das komplette Programm aus diesem Cluster; wer das Ziel erst nach dem Umzug baut, zieht zweimal um. Und die Berechtigungen werden nicht migriert, sondern neu gedacht: Der über Jahre gewucherte NTFS-Flickenteppich lässt sich ohnehin nicht 1:1 abbilden — die Migration ist die einmalige Gelegenheit, mit sauberen Gruppen auf Website- und Bibliotheksebene neu zu starten. Wie das Zielmodell aussieht, behandelt der Berechtigungs-Artikel im Cluster.

Die Werkzeugfrage: SPMT — und wann CosyTrack.Migrate

Für den Standardfall musst du kein Geld ausgeben: Das kostenlose SharePoint Migration Tool und der Migration Manager schaufeln Fileserver- und SharePoint-Server-Inhalte zuverlässig nach SharePoint Online, Versionen und Basis-Metadaten inklusive. Ihre Grenze ist das Regelwerk drumherum: Wenn aus „K:\Projekte\2024\Kunde Müller\Verträge\…“ beim Umzug die Spalten Jahr, Kunde und Dokumentart werden sollen, wenn Namen und Sonderzeichen nach festen Regeln bereinigt, ROT-Daten automatisch ausgefiltert und das Ganze in wiederholbaren Wellen mit Delta-Läufen und Protokoll je Datei laufen soll — dann bist du im Territorium von CosyTrack.Migrate:

Skizze 2: Die Pipeline mit CosyTrack.Migrate — Regelwerk statt Handarbeit: Pfade werden Spalten, Namen werden bereinigt, Wellen und Delta-Läufe laufen wiederholbar mit Protokoll.

Der entscheidende Gedanke dahinter: Die Ordnerstruktur deines Fileservers ist nicht wertlos — sie ist eine Datenquelle. Zwanzig Jahre Ablagedisziplin stecken in diesen Pfaden, und mit dem richtigen Mapping wird daraus das Metadaten-Fundament, das du im Ziel ohnehin brauchst. Genau deshalb gehört das Mapping in Phase drei entworfen und am Pilotbereich verprobt — nicht während der Umzug schon läuft.

FAQ zur Migration nach SharePoint Online

Muss ich nach dem Support-Ende von SharePoint 2016/2019 sofort migrieren?

„Sofort abgeschaltet“ wird nichts — die Farm läuft weiter. Aber sie läuft ohne Sicherheitsupdates, ohne Herstellersupport und ohne ESU-Option, und das fällt in Sicherheitsaudits, Compliance-Rahmenwerken und zunehmend bei Cyberversicherungen durch. Wer on-premises bleiben muss, wechselt auf die Subscription Edition; für alle anderen ist SharePoint Online der Weg — und der Projektstart gehört auf diese Woche, nicht auf nächstes Quartal.

Wie lange dauert eine Fileserver-Migration realistisch?

Die Datenbewegung selbst ist selten der Engpass — Analyse, Bereinigung und Zielarchitektur bestimmen den Takt. Als Größenordnung für den Mittelstand: wenige Wochen für Inventur und Konzept, danach Wellen über einen bis wenige Monate, je nach Umfang und Abstimmungsbedarf. Der größte Zeithebel ist die Bereinigung: Wer nur 40 Prozent migriert, ist schlicht mehr als doppelt so schnell fertig.

Was passiert mit unseren NTFS-Berechtigungen?

Sie werden nicht mitgenommen — und das ist ein Feature, kein Mangel. Gewachsene NTFS-Strukturen mit Einzelrechten und Vererbungsbrüchen lassen sich in SharePoint weder sauber abbilden noch sinnvoll warten. Stattdessen wird das Zielmodell neu entworfen: Gruppen auf Website- und Bibliotheksebene, so wenige Ausnahmen wie möglich. Die Analyse der Alt-Berechtigungen dient dabei als Landkarte, nicht als Bauplan.

Können wir die Ordnerstruktur behalten?

In Resten ja, als Prinzip nein. Ein bis zwei flache Ebenen mit klarem Job — etwa für Standardspaltenwerte — sind in Ordnung; die tiefen Äste dagegen sind es, die Pfadlimits reißen und Inhalte verstecken. Die klügere Übersetzung: Die Ordnerlogik wird per Mapping zu Metadatenspalten, damit die vertraute Sortierung als Filter und Ansicht weiterlebt. Die Grundsatzfrage dazu klärt der Ordner-vs.-Metadaten-Artikel im Cluster.

Reicht das kostenlose SharePoint Migration Tool von Microsoft?

Für geradlinige Umzüge: ja, unbedingt nutzen. SPMT und Migration Manager übertragen Inhalte, Versionen und Basis-Metadaten zuverlässig. Zusätzliche Werkzeuge wie CosyTrack.Migrate lohnen sich, sobald Regelwerk ins Spiel kommt — Pfad-zu-Spalten-Mapping, automatische Namensbereinigung, ROT-Filter, wiederholbare Wellen mit Delta-Läufen und ein Protokoll, das jede Datei nachvollziehbar macht. Kurz: SPMT bewegt Daten, Migrate setzt Regeln durch.

Wie verhindern wir, dass nach dem Umzug alle im alten System weiterarbeiten?

Mit drei Maßnahmen in fester Reihenfolge: Delta-Lauf, dann Quelle read-only, dann sichtbare Umleitung — und zwar am Cutover-Tag, nicht „irgendwann“. Dazu gehören Kurzschulungen am neuen Ort und zwei Hypercare-Wochen mit erreichbaren Ansprechpartnern. Eine Migration ist erst fertig, wenn die Quelle zu ist — nicht, wenn die Daten drüben sind.