SharePoint-Migration: Der praktische Leitfaden für 2026

Im Jahr 2025 haben wir zwölf Mittelständler von SharePoint zu einem dedizierten DMS migriert. Vom 25-Personen-Steuerbüro mit 800 GB Daten bis zum 600-Personen-Maschinenbauer mit 14 TB und 47 PowerApps. Dieser Leitfaden fasst die wichtigsten Lehren zusammen — was funktioniert, was schiefläuft, und wie lange es realistisch dauert.

Das Dokument ist eine kondensierte Version unseres Blog-Artikels und ergänzt ihn um konkrete Checklisten für die einzelnen Projektphasen.

Phase 1: Wann ist eine Migration wirklich nötig?

Nicht jeder SharePoint-Schmerz rechtfertigt eine Migration. Klare Migrations-Trigger sind:

• Souveränitäts- oder DSGVO-Probleme — z.B. NIS-2-Pflicht, §203 StGB für Berufsgeheimnisträger, OZG-Vergabe-Anforderungen
• Performance-Probleme bei großen Bibliotheken (>50.000 Dokumente)
• Kosten-Eskalation durch Microsoft-365-Tarif-Änderungen
• Komplexität so groß, dass niemand intern mehr den Überblick hat
• Vendor-Lock-in-Sorgen mit Blick auf 5-10 Jahre

Schwache Migrations-Trigger:

• "Uns gefällt die UI nicht so" — Schulungs-Problem, nicht System-Problem
• "Wir wollen weg von Microsoft" — emotional verständlich, aber alleine kein ROI

Wenn die Migration kommt, sollte sie als strategisches Projekt aufgesetzt sein, nicht als IT-Operation.

Phase 2: Bestandsaufnahme (Wochen 1-3)

Die teuersten Migrations-Fehler entstehen durch unvollständige Bestandsaufnahme. Bevor Sie irgendeine technische Entscheidung treffen, brauchen Sie:

Site Collection Discovery

Listen Sie alle Sites, Subsites, Bibliotheken und Listen auf. Mit ShareGate, AvePoint, Microsoft 365 Admin Center oder eigenen PowerShell-Skripten. Bei mittleren Setups sind das 30-100 Sites; bei großen 200-500.

Permission Audit

Wer hat wo Zugriff? Bei SharePoint sind Permissions oft auf Item-Level — das lässt sich im Ziel-System meist nicht 1:1 abbilden. Konsolidieren Sie auf rollenbasierte Rechte (Sachbearbeiter, Manager, Geschäftsführung).

Workflow-Bestandsaufnahme

Alle Power-Automate-/Microsoft-Flow-/SharePoint-Workflows inventarisieren. Wir hatten Kunden mit 80+ aktiven Workflows, von denen 40 niemand mehr erklären konnte. Das ist Migrations-Sprengstoff.

PowerApps-Inventur — die meistunterschätzte Falle

Falls Sie Custom-Apps auf SharePoint-Basis haben (von ehemaligen Mitarbeitern, Beratern, internen Power-Usern gebaut), ist die Migrations-Komplexität exponentiell höher. Ein Maschinenbauer-Projekt von uns musste 2025 abgebrochen werden, weil 30+ produktionskritische PowerApps niemand mehr verstand. Wir starten kein Migrationsprojekt mehr ohne vorherige PowerApps-Inventur.

Drittsystem-Integrationen

Welche externen Tools schreiben oder lesen in SharePoint? Power BI, Dynamics 365, Custom-Apps, Anbindungen zu DATEV oder SAP? Jede Integration muss in der Migrations-Planung berücksichtigt sein.

Phase 3: Zielarchitektur (Wochen 4-5)

Bevor Sie den ersten Lift starten, brauchen Sie eine klare Zielarchitektur. Sonst bauen Sie SharePoint einfach im neuen System nach.

Keine Permission-Bäume mehr, sondern rollenbasierte Rechte. Personen wechseln Rollen, nicht Permissions.

Workflows konsolidieren. Aus 80 oft chaotischen Power-Automate-Flows wurden in unseren Projekten typisch 12-20 saubere BPMN-Workflows. Workflow-Reduktion ist eine eigene Projektphase.

Klare Datenstruktur. Statt Sites/Bibliotheken: Akten, mit Metadaten statt Ordner-Tiefe. Eine Migration ist die Chance, das endlich richtig zu machen.

Read-Only-Backup behalten. Plan: 6-12 Monate nach Cutover bleibt das alte SharePoint im Read-Only-Modus stehen. Als Notfall-Backup falls etwas vergessen wurde.

Phase 4: Pilot (Wochen 6-12)

Bevor Sie das Hauptprojekt starten, machen Sie einen Pilot mit:

• Test-Migration mit 100-500 Dokumenten zur Tool-Validierung
• Echte User-Pilotgruppe (5-10 Personen aus verschiedenen Abteilungen) für 4 Wochen
• Workflow-Test mit den 3-5 wichtigsten Geschäftsprozessen

Typische Fundpunkte beim Tool-Test:

• Metadaten-Mapping stimmt nicht (z.B. Datum-Felder im falschen Format)
• E-Mail-Anhänge gehen verloren
• Versionsgeschichten werden unvollständig übernommen
• Sonderzeichen in Dateinamen crashen die Migration
• OneNote-Notebooks lassen sich nicht 1:1 übertragen

Diese Stolpersteine MÜSSEN im Pilot gefunden werden — im Hauptprojekt sind sie teuer.

Phase 5: Cutover und Parallelbetrieb (Wochen 13-26)

Kein erfolgreiches Projekt hat in einer Nacht gewechselt. Standard ist 60-90 Tage Parallelbetrieb:

• Neue Dokumente ab Stichtag im neuen System (klare Kommunikation an alle Mitarbeiter)
• Alte Dokumente schrittweise migriert, priorisiert nach Nutzungsfrequenz
• Read-Only-SharePoint für mindestens 6 Monate als Backup

Bandbreite ist oft der Engpass. Bei 4+ TB ist die Internet-Leitung der limitierende Faktor. In einem Projekt haben wir eine physische Festplatte ins Rechenzentrum geschickt (Hetzner Storage Box), statt 6 Wochen über das Internet zu migrieren.

Phase 6: Stabilisierung und Cleanup (Monate 7-12)

Nach erfolgreichem Cutover:

• Read-Only-SharePoint mit Plan zur endgültigen Abschaltung
• Workflow-Optimierungen basierend auf User-Feedback
• Schulungs-Refresh für Mitarbeiter, die ihr neues System noch nicht voll nutzen
• Dokumentation der finalen Akten-Struktur und Berechtigungs-Schema

Realistische Zahlen 2026

Wenn Sie 2026 eine SharePoint-Migration planen, sollten Sie kalkulieren:

Fazit

SharePoint-Migration ist machbar, aber kein Standard-Projekt. Wer den Aufwand unterschätzt, läuft in dasselbe Chaos wieder rein, nur mit anderer Software.

Erfolgreiche Migrationen haben drei Gemeinsamkeiten: gründliche Bestandsaufnahme vor jeder Technik-Entscheidung, klare Zielarchitektur statt 1:1-Nachbau, und ehrliche Pilotphase mit echten Usern.

Wenn Sie konkret eine Migration planen, sprechen Sie uns an — wir machen oft kostenfreie Komplexitäts-Einschätzungen und sagen Ihnen ehrlich, was in welcher Zeit machbar ist.