Es gibt ja grundsätzlich mal mehrere Wege um eine Migration nach SharePoint durchzuführen.
Abhängig von der Quell- und Zielversion ergeben sich bestimmte Migrationspfade. Sofern ich mich on-premises bewege, kann ich klassisch die Datenbank migrieren, wenn das Ziel Online oder Restrukturierungen on-premises ist, dann benötige ich ein Tool. Das bedeutet auch, dass nur eine sog. side-by-side Migration möglich ist, d.h. für den Zeitraum der Migration, müssen die SharePoint Umgebungen parallel laufen. CD einstecken und „aktualisieren“ (in-place UPgrade) wird und wurde von SharePoint noch nie unterstützt.
Analyse
Grundsätzlich ist es natürlich immer eine gute Idee, sich die Quelle genau anzusehen. Gerade bei älteren SharePoint on-premises sind gerne 3rd Party Tools im Einsatz oder sogar Eigenentwicklungen in verschiedensten Ausprägungen.
Ein besonderes Augenmerk sollte man auf folgende Punkte legen, um den Umfang und die Komplexität identifizieren zu können:
- Datenbankgröße (Datenvolumen)
Ist nur ein Indiz für den Umfang. - Webseitesammlungstruktur inkl. Webseiten (Site Collections inkl.. Subsite)
Gerade Migrationstools gehen über die CSOM Schnittstelle, so dass hier der Migrationsaufwand exponentiell steigt (Vgl. 100 GB in 10 Dateien oder 100 GB in 1.000.000 Dateien – letzteres benötigt erheblich länger). - Berechtigungsstruktur und Technik (ADFS, Kerberos, Windows Integrated, Forms…). Evtl. sind hier Anpassungen an den Berechtigungen notwendig.
- Farmlösungen (Farm Solutions) oder .wsp Dateien. Diese laufen im Server Kontext und können nicht nach Online migriert werden.
- Dienstanwendungen – Müssen diese bei der Migration berücksichtigt werden?
- Sandboxed Solutions – Abgekündigt und teilweise nicht mehr unterstützt.
- Add-Ins – spezielle Infrastrukturanforderungen
- Masterpages – Bestimmtes Layout/Design
- Anpassungen im Dateisystem (Site Definitions, web.config, …)
Die Migration ist immer eine Chance zur Veränderung.
Altlasten kann man an der Stelle gut loswerden. Wird also z.B. in der Analysephase eine Anpassung entdeckt, muss abgewägt werden, ob diese noch länger benötigt wird oder sogar aufwendig nachgebaut werden muss. Auch ist es eine gute Gelegenheit Dinge zu ändern, was lief schlecht in der Vergangenheit, wo gibt es Probleme. Die „alten“ Probleme können ja ruhig der Vergangenheit angehören. Welche Funktionen eigenen sich aus der neuen Generation vielleicht auch als Ersatz?
Ziel ist es in dieser Phase bereits einen groben Eindruck zu erhalten.
Methode detach/attach
Dies Variante geht natürlich nur, wenn das Ziel SharePoint on-premises heißt. Egal ob das eine Private Cloud, oder als VM Hosting in Azure ist. Es geht nicht mit Office 365. Wichtig dabei ist, es wird nur ein Versionssprung unterstützt, z.B. 2016 -> 2019. Wenn ich 2013 einsetze und mein Ziel 2019 ist, benötige ich einen weiteren Schritt 2013 -> 2016 -> 2019.
Man nennt das Vorgehen auch deshalb detach/attach, da man die Datenbank aus dem Quellsystem nimmt und im Zielsystem anhängt.
Für die produktive Migration kann man die Umgebung parallel betreiben, wobei man die Quelle dann auf reinen Lesezugriff schaltet. Technisch geht es dann so weiter:
- Backup Quell Datenbank (Inhaltsdatenbank oder auch die Dienstanwendungen)
- Datenbank im Ziel SQL wiederherstellen
- Migration sofort starten, hier am Beispiel Inhaltsdatenbank
Mount-SPContentDatabase -Name PREV_Content_Legal -WebApplication http://portal.contoso.com
Methode 3rd Party Tool
Wenn das Ziel SharePoint Online in Office 365 (und damit grundsätzlich auch Office Groups und Teams) ist, dann ist dies die einzige Variante. Zusätzlich kann ich mit dieser Variante strukturelle Veränderungen bzw. Umorganisation vornehmen – sprich aufräumen.
Der Nachteil des Aufräumens ist, dass das Migrationsvorgehen selbst länger dauert, dafür ist am Ende jedem geholfen, wenn die Inhalte leichter auffindbar, leichter strukturiert und die Berechtigungen transparenter sind.
Funktional unterscheiden sich die Tools leicht, grundsätzlich kann ich hier mal die bekanntesten nennen:
- Microsoft SharePoint Migration Tool (kostenlos)
- AvePoint DocAve Migrator
- Quest (ehemals Metalogix)
- ShareGate
Fazit
Ich habe in der Vergangenheit schon viele SharePoint Umgebungen gesehen und beide Varianten durchgespielt. Bei der Migration nach SharePoint bekommt man im Grunde immer alles an sein Ziel, wenn man es möchte und Neuerungen und Veränderungen offen gegenüber steht. Wenn etwas nicht auf Anhieb funktioniert, dann liegt es meistens an Anpassungen jeglicher Art – ob Konfiguration oder benutzerdefinierter Code.
