Wie ein schlankes Team bei Avanade eine Migration von 2.000 Sites mit ShareGate durchführte

Ein französisches Fertigungsunternehmen betrieb eine hybride SharePoint-Umgebung. Neuere Arbeitslasten waren bereits zu SharePoint Online migriert worden – hauptsächlich vorangetrieben durch die Einführung von Microsoft Teams – aber die Legacy-Inhalte des Unternehmens befanden sich noch auf lokalen SharePoint 2010-Servern.  

Dies ist eine Situation, die viel häufiger werden wird, da SharePoint 2016 und 2019 im Juli 2026 das Support-Ende erreichen und 70% der von uns befragten Organisationen im März 2025 angaben, noch mindestens einige Daten auf diesen Servern zu haben.

Avanades Kunde wollte alles in der Cloud konsolidieren und ihre Server außer Betrieb nehmen, um dabei laufende Infrastrukturkosten zu eliminieren.  

Klares Ziel. Keine unkomplizierte Umgebung.

2.000 Sites, 2 Personen und ein Jahrzehnt angesammelter Komplexität

Der Umfang war groß: 2.000 SharePoint-Sites und mehr als 1,3 TB Daten. Und da die Quelle SharePoint 2010 war, trug die Umgebung über ein Jahrzehnt angesammelter Komplexität mit sich, wie InfoPath-Formulare, Sandbox-Lösungen, benutzerdefinierte Workflows und JavaScript-Injektionen, die tief in Site-Seiten vergraben waren.

Avanade stellte ein Team von zwei Personen für die Migration ab: Aimery Thomas, Microsoft MVP und Modern Workplace Manager bei Avanade, war der technische Leiter und ein Junior-Entwickler half mit. Ein Architekt schaute ein paar Mal pro Woche vorbei, aber die tägliche Ausführung lag ganz auf ihren Schultern.

Für ein Projekt dieser Größenordnung benötigte das Team Tools, die die schwere Arbeit übernehmen konnten. Es gab keinen Raum für manuelle Prozesse oder zusammengeschusterte Notlösungen.

Versteckte Risiken, die Standard-Tools nicht erkennen konnten

Neben den offensichtlichen Herausforderungen sorgte sich Aimery über das, was er nicht leicht sehen konnte. Script-Injektionen – JavaScript, das direkt in SharePoint-Seiten eingebettet ist – sind notorisch schwer zu erkennen. Microsofts SharePoint Migration Assessment Tool konnte sie nicht identifizieren.

"Wir mussten ein lokales PowerShell-Skript erstellen, um diese Art von versteckten Komplexitäten zu identifizieren," sagte Aimery.

Wenn diese versteckten Komplexitäten nicht vor der Migration erfasst wurden, würden sie als Fehler danach auftauchen. Zu diesem Zeitpunkt wären sie viel schwieriger und teurer zu beheben.

Bewertung zuerst: Das Projekt halbieren, bevor eine einzige Site migriert wird

Aimerys erster Schritt war nicht die Migration. Es ging darum, genau zu verstehen, womit sie es zu tun hatten.

Mithilfe des ShareGate Migrate Quellanalyseberichts bewertete das Team alle 2.000 Sites in ihrer SharePoint 2010-Umgebung. Die erste Entdeckung war bedeutend: Etwa 1.000 Sites hatten seit mehr als zwei Jahren keinerlei Aktivität gezeigt.

Mit dem Einverständnis des Unternehmens wurden diese inaktiven Sites aus dem Projektumfang herausgenommen, wodurch das Projekt um 50 % reduziert wurde. Das bedeutete eine erheblich kürzere Projektlaufzeit und geringere Migrationskosten, bevor eine einzige Site verschoben worden war.

„Stellen Sie sicher, dass Sie genügend Zeit für die Bewertung der Quelle aufwenden. Denn Sie könnten möglicherweise die Hälfte der Sites aus dem Umfang herausnehmen", sagte Aimery.

Das Team führte dann eine tiefergehende Analyse der verbleibenden 1.000 Sites durch und klassifizierte jede einzelne anhand einer Reihe von Komplexitätskriterien: InfoPath-Formulare, laufende Workflows, Sandbox-Lösungen und Script-Injektionen. Sites, die eines dieser Kriterien erfüllten, wurden als komplex markiert.

Das Ergebnis: etwa 800 einfache Sites und 200 komplexe. Einfache Sites würden zuerst migriert. Komplexe Sites würden mehr Zeit erhalten.

Diese Triage verwandelte ein umfangreiches, überwältigendes Projekt in zwei überschaubare Phasen mit einem klaren Angriffsplan.

Automatisierte Ausführung mit vollständiger Transparenz

Mit dem definierten Umfang migrierte das Team die 800 einfachen Sites in vier Wellen. Jede Welle war durch eine Mischung aus Site-Größen und Dateienanzahl ausbalanciert, um die Ausführung vorhersagbar zu halten.

Aimery nutzte mit seinem Entwicklerhintergrund intensiv ShareGates PowerShell-Modul. Das Team skriptete den gesamten Prozess: das Erstellen von SharePoint Online-Ziel-Sites und das programmgesteuerte Auslösen von Migrationen, alles ohne die grafische Benutzeroberfläche verwenden zu müssen.

„Was ich am nützlichsten fand, war die Möglichkeit, meine ShareGate-Migrationen mit PowerShell auszuführen", sagte Aimery. „Während des Migrationsprozesses hatten wir so viele andere Aufgaben. Aber für die Migration mussten wir nur die Ausführung eines Skripts auslösen und alles wurde automatisch erledigt."

Aber Automatisierung bedeutete nicht, blind zu fliegen. Auch wenn alles über PowerShell lief, konnte das Team den Echtzeit-Migrationsfortschritt über ShareGates Benutzeroberfläche verfolgen, wodurch sie entwicklergerechte Kontrolle mit visueller Überwachung erhielten. Für ein Beratungsteam, das Migrationen als Dienstleistung anbietet, ist diese Kombination das, was einem Zwei-Personen-Team ermöglicht, ein Projekt durchzuführen, das andernfalls vier oder fünf Personen benötigen könnte.

Den Berichten vertrauen

Nach jeder Welle verließ sich das Team auf ShareGates Migrationsberichte, um zu bestätigen, dass Berechtigungen, Dokumente, Metadaten und alles andere dort gelandet waren, wo sie hingehörten.

„Wir verließen uns wirklich auf die ShareGate-Migrationsberichte", erklärte Aimery. „Wenn der Bericht sagte, dass alles erfolgreich war, vertrauten wir darauf."

Der Wellenansatz baute auch natürliche Sicherheitsnetze ein. Während das Team Welle zwei migrierte, hatten die Endbenutzer von Welle eins Wochen Zeit, ihre Sites zu überprüfen. Aimerys Team stand durchgehend für intensive Betreuung zur Verfügung, aber es wurden keine fehlenden Dokumente gemeldet.

Wenn Berichte Probleme meldeten, hatte das Team auch dafür ein System. Sie führten eine Zuordnungsdatei, die jeden Fehlertyp aus den ShareGate-Berichten mit einer spezifischen Korrekturmaßnahme verknüpfte. Zum Beispiel wurden Probleme mit Lookup-Spalten durch das Ausführen einer inkrementellen Migration gelöst. Kein Rätselraten, nur ein dokumentiertes Vorgehen.

Es ist die Art von Prozess, der skaliert. Dieselbe Zuordnungsdatei und derselbe Fehlerbehandlungsansatz können beim nächsten Kundenauftrag aufgegriffen und wiederverwendet werden, ohne von vorn zu beginnen.

Komplexe Sites: weniger komplex als erwartet

Für die 200 komplexen Sites migrierte das Team zuerst den Inhalt und bewertete dann, was tatsächlich neu aufgebaut werden musste. Aimery besprach die Workflows jeder Site mit dem Kunden. In den meisten Fällen bestätigten sie, dass sie diese nicht mehr benötigten.

Von allen komplexen Sites erforderten nur sieben Workflows einen Neuaufbau in Power Automate. Eine abschließende inkrementelle Migration erfasste alle Inhaltsänderungen, die während der Neuaufbauphase vorgenommen wurden, und das Projekt war abgeschlossen.