SharePoint migrieren, ohne den Betrieb anzuhalten
Das Schwierige an einer Migration ist nicht, Dateien zu verschieben. Es ist, dass niemand aufhört zu arbeiten, während sie verschoben werden.
Es gibt zwei Wege, eine SharePoint-Migration durchzuführen. Der eine: ein Wochenende wählen, alles abschalten, kopieren und beten. Der andere: akzeptieren, dass der Betrieb nicht stillstehen kann, und die Migration um diese Tatsache herum bauen.
Den zweiten sind wir gegangen: bei globalen Farms der Europäischen Kommission, beim Publishing-Intranet der irischen Regierung und bei Migrationen von On-Premises nach SPFx für Fortune-500-Kunden. Das Muster wiederholt sich immer.
Was man anders zu sehen lernt
Der natürliche Reflex ist, die Migration als Problem des Datentransports zu behandeln. Auch wir haben das anfangs so gesehen. Sie ist es nicht. Sie ist ein Problem der Kontinuität.
Die Dateien kommen am Ende immer an. Was ein Projekt ruiniert, ist der Tag, an dem ein Team das Portal öffnet und das Dokument nicht findet, das es genau jetzt braucht. Es ist gleichgültig, dass es irgendwo existiert. Für diese Person hat das System in diesem Moment versagt. Und genau dort geht Vertrauen verloren, dessen Rückgewinnung weit teurer ist als jede Datei.
Was wir tun, bevor ein einziges Byte bewegt wird
Eine echte Bestandsaufnahme. Nicht Sites zählen. Verstehen, welche leben, welche seit Jahren niemand mehr öffnet, wem was gehört und welche Berechtigungen tragen, die niemand erklären kann. Ein erheblicher Teil des Gefundenen sollte gar nicht migriert werden. Er sollte archiviert oder gelöscht werden, und das ist eine Geschäftsentscheidung, keine technische.
Eine Abhängigkeitskarte. Flows, Formulare, Anpassungen, Integrationen, die jemand vor sieben Jahren gebaut hat und die noch immer einen Bericht speisen, den der Vorstand jeden Montag liest. Hier wohnen die Überraschungen.
Eine Entscheidung über das Alte. Klassische Web Parts werden nicht überleben. Die Frage lautet nicht, wie man sie konvertiert, sondern ob sie die Konvertierung wert sind. Oft ist die ehrliche Antwort nein.
In Wellen, nicht im Big Bang
Man bewegt in Gruppen mit klaren Grenzen: eine Abteilung, eine Funktion, eine Menge von Sites mit demselben Eigentümer. Jede Welle hat eine Phase, in der Quelle und Ziel koexistieren, die Quelle schreibgeschützt. Bricht etwas, steht niemand ohne Arbeitsmittel da: Man geht eine Welle zurück, nicht das ganze Projekt.
Auf dem Papier ist das langsamer. In der Praxis ist es deutlich schneller, denn es gibt keine ungeplanten Stillstände.
Was man damit gewinnt
Man gewinnt das Recht, klein zu scheitern. In einer Big-Bang-Migration ist der erste Fehler öffentlich, groß, und erreicht die Unternehmensspitze noch am selben Tag. In Wellen betrifft der erste Fehler dreißig Menschen, ist an einem Vormittag behoben, und die nächste Welle wiederholt ihn nicht.
Nichts bleibt dem Zufall überlassen. Das ist der Unterschied zwischen einer Migration, an die man sich wegen des Ergebnisses erinnert, und einer, an die man sich wegen des Wochenendes erinnert.
