Migration weg von SharePoint: Lessons learned aus 12 Projekten in 2025

Das Jahr 2025 war für unser Beratungsteam ein Migrations-Marathon: 12 Kunden haben SharePoint verlassen, 3 weitere haben den Prozess gestartet. Die Gründe waren überwiegend nicht technisch — sondern strategisch (Souveränität, Kosten, Vendor Lock-in) oder organisatorisch (zu komplex für die eigene IT).

Hier eine ehrliche Bilanz: was bei diesen 12 Projekten funktioniert hat, was schiefgegangen ist, und was wir für 2026 anders empfehlen.

Die 12 Projekte im Überblick

Um Erwartungen einzuordnen: Die Kunden waren stark unterschiedlich. Vom 25-Personen-Steuerbüro mit 800 GB SharePoint-Daten bis zum Maschinenbauer mit 600 Mitarbeitern und 14 TB plus 47 Workflows. Im Durchschnitt:

• Unternehmensgröße: 95 Mitarbeiter
• SharePoint-Datenvolumen: 4,2 TB
• Anzahl SharePoint-Sites: 67 (Median)
• Migrations-Dauer: 4-9 Monate (Schnitt 6,5 Monate)
• Budget-Abweichung: Median +15% über Erstkalkulation
• Erfolgsquote: 10/12 vollständig erfolgreich, 1/12 teilweise (Subset blieb in SharePoint), 1/12 abgebrochen

Das abgebrochene Projekt ist eine eigene Lektion — dazu unten mehr.

Was zuverlässig funktioniert hat

1. Vorab-Inventur: 2-3 Wochen, immer

Kein Projekt hat ohne gründliche Bestandsaufnahme funktioniert. Bei SharePoint heißt das:

• Site Collection Discovery: alle Sites, Subsites, Listen, Bibliotheken inventarisieren. Tools dafür: ShareGate, Microsoft 365 Admin Center, eigene PowerShell-Skripte.
• Permission Audit: wer hat Zugriff auf was? Bei SharePoint sind das oft Permissions auf Item-Level, was im Ziel-System meist nicht 1:1 abgebildet werden kann.
• Workflow-Bestandsaufnahme: alle Power Automate / Microsoft Flow / SharePoint-Workflows inventarisieren. Wir hatten Kunden mit 80+ aktiven Workflows, von denen 40 niemand mehr genau erklären konnte.
• Drittsystem-Integrationen: welche externen Tools schreiben/lesen in SharePoint? Power BI, Dynamics 365, Custom-Apps?

2. Klares Zielbild vor dem ersten Lift

Wer ohne Zielarchitektur loslegt, baut SharePoint einfach im neuen System nach — mit allen Macken. Die produktivsten Projekte hatten ein neues Zielbild:

• Keine Permission-Bäume mehr, sondern rollenbasierte Rechtevergabe
• Workflows konsolidiert: aus 80 oft chaotischen Power-Automate-Flows wurden 15 saubere BPMN-Workflows
• Klare Datenstruktur: Akten statt Sites, Metadaten statt Ordner-Tiefe

3. Parallelbetrieb statt Big Bang

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

• Neue Dokumente ab Stichtag im neuen System
• Alte Dokumente schrittweise migriert (priorisiert nach Nutzungsfrequenz)
• Read-Only-Zugriff auf das alte SharePoint für 6 Monate nach Cutover — als Notfall-Backup

4. Migrationswerkzeuge testen, nicht glauben

Die Migrationswerkzeuge im Markt (ShareGate, AvePoint, Quest QoreStor) machen 80% gut, scheitern aber an Edge Cases. Wir haben in jedem Projekt eine Test-Migration mit 100-500 Dokumenten gemacht, bevor wir das Hauptprojekt gestartet haben. Typische Fundpunkte:

• Metadaten-Mapping stimmt nicht (z.B. Datum-Felder im falschen Format)
• Anhänge zu E-Mails werden verloren
• Versionsgeschichten werden nicht vollständig übernommen
• Sonderzeichen in Dateinamen crashen die Migration

Was schiefgegangen ist

Das gescheiterte Projekt

Der abgebrochene Migration war ein Maschinenbauer mit ungefähr 200 Mitarbeitern. Anfangs sah es einfach aus: relativ standard SharePoint-Nutzung, 1,8 TB Daten, 12 Sites. Wir kalkulierten 5 Monate.

Problem: Tief im SharePoint waren 30+ unternehmenskritische "PowerApps" — Custom-Anwendungen auf SharePoint-Basis, gebaut von einem ehemaligen Mitarbeiter, der das Unternehmen verlassen hatte. Die PowerApps steuerten Produktionsworkflows, Qualitätssicherung, Lieferantenkommunikation. Niemand wusste mehr genau, wie sie funktionierten.

Nach 4 Monaten und 180.000 € Beratungskosten haben wir gemeinsam mit dem Kunden entschieden: die PowerApps neu zu bauen würde nochmal 12-18 Monate und 400.000 € kosten. Der Kunde bleibt vorerst auf SharePoint, neue Dokumente werden in Aktenplatz angelegt, die PowerApps werden Stück für Stück durch ERP-Module ersetzt.

Lektion: Vor jeder SharePoint-Migration muss eine PowerApps/Power-Automate-Inventur stehen. Wer das übergeht, riskiert genau diesen Fall.

Häufige kleinere Probleme

OneNote-Notebooks: SharePoint speichert OneNote-Notebooks in einem proprietären Format. Migration auf ein anderes Notiz-System (Notion, Obsidian, BookStack) ist möglich, aber Formatierungen gehen oft verloren. In 4 von 12 Projekten haben wir die OneNotes als PDF exportiert und die echten Notebooks in SharePoint gelassen.

Microsoft Forms: Sind eng mit SharePoint verzahnt. Bei Migration mussten alle Forms neu gebaut werden (im Zielsystem oder in einem separaten Tool wie Formspree).

E-Mail-Archivierung: Wenn SharePoint als E-Mail-Archiv genutzt wird (häufig via "Save to SharePoint"-Funktion in Outlook), ist die Migration komplex — Headers gehen oft verloren, Anhänge separieren sich von E-Mails.

Bandbreite: Bei 4 TB+ ist die Internet-Bandbreite oft der Engpass. Wir haben in einem Projekt eine physische Festplatte zum Hetzner-RZ geschickt (Hetzner Storage Box) statt 6 Wochen über das Internet zu migrieren.

Was wir 2026 anders machen

Aus den 12 Projekten haben wir unseren Migrations-Ansatz an drei Punkten verschärft:

1. Verpflichtende PowerApps-Inventur in Woche 1. Wir starten kein Migrationsprojekt mehr, bevor klar ist, welche Custom-Apps existieren und wer sie versteht. Wenn niemand mehr da ist, der die Apps kennt, machen wir entweder ein Reverse-Engineering-Projekt vorab — oder wir lehnen die Migration ab.

2. Workflow-Reduktion vor Migration, nicht währenddessen. Wir haben gelernt: Wer alle Workflows 1:1 ins neue System migriert, hat im neuen System dasselbe Chaos wie vorher. Deshalb machen wir jetzt einen "Workflow-Cleanup" als eigene Phase vor der Migration — typisch 4-6 Wochen, in denen 50-70% der Workflows abgeschaltet oder zusammengelegt werden.

3. Frühe Pilotmigration mit echten Usern. Statt Test-Migration nur mit Dokumenten, machen wir jetzt eine Pilotgruppe (5-10 User aus verschiedenen Abteilungen) für 4 Wochen ins neue System. Die testen mit echtem Tagesgeschäft, finden Lücken früh.

Realistische Zahlen für 2026

Wenn Sie 2026 eine SharePoint-Migration planen, sind das unsere Erfahrungswerte:

• Dauer: 4-9 Monate (Schwierigkeit korreliert stark mit PowerApps/Power-Automate-Komplexität)
• Kosten: 800-1.500 € pro Mitarbeiter (Migrationsbegleitung), zzgl. Lizenz-/Hosting-Kosten der neuen Lösung
• Personalbedarf intern: mindestens 1 Vollzeit-Mitarbeiter für die Projektzeit, plus 5-10% Zeit jedes Abteilungsleiters
• Risiken: PowerApps, Workflow-Chaos, ungeklärte Permissions, OneNote-Notebooks

Die wichtigste Botschaft: Es lohnt sich. Alle 10 erfolgreich migrierten Kunden würden den Wechsel wieder machen. Die Hauptmotive nach 12 Monaten Betrieb der neuen Lösung waren immer dieselben: weniger Komplexität, niedrigere laufende Kosten, klare Datenstruktur, echte Eigentumsverhältnisse an den Daten.

Wenn Sie konkret planen

Falls Sie überlegen, SharePoint zu verlassen, lade ich Sie zu einem kostenfreien Erst-Workshop ein. Wir nehmen uns einen halben Tag Zeit, schauen mit Ihnen Ihre SharePoint-Landschaft an, machen eine Komplexitäts-Einschätzung und sagen Ihnen ehrlich: was geht in welcher Zeit, was wird Sonderaufwand.

Auch wenn das Ergebnis am Ende nicht Aktenplatz heißt — die Bestandsaufnahme bekommen Sie sauber dokumentiert.

Für konkrete Fragen oder einen Termin: kontakt@aktenplatz.de oder direkt eine Demo buchen.