Migration nach SharePoint

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

 

Zeigt den PowerShell Befehl Mount-SPContentDatabase
Zeigt den PowerShell Befehl Mount-SPContentDatabase
Anschließend migriert SharePoint das Datenbankschema. Dieser Vorgang kann von wenigen Minuten bis zu einigen Stunden dauern, primär abhängig von Struktur und Größe. Daher empfehle ich diesen Vorgang unbedingt zu testen und zu messen. Ein Wartungsfenster ist dann bei großen Datenbanken und mehreren Versionssprüngen dann doch eher knapp, selbst wenn ich ein ganzes Wochenende habe.
Im Anschluss empfiehlt es sich noch die Logs zu analysieren, ob es Probleme mit Anpassungen gab oder etwaige Warnungen.
Vorteil bei dieser Variante, es kommen natürlich immer alle Daten mit, es kann für den Zeitraum der Migration noch zusätzliche Ressourcen und Aufwände erzeugen, dafür ist es anschließend erledigt.

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:

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.

Teilen

Autor: Dennis Hobmaier

Dennis Hobmaier ist Solution Designer bei Kapsch BusinessCom AG. Er hat über 15 Jahre Erfahrung in IT-Enterprise Umgebung aller Größenordnungen und bedient Kunden aus den unterschiedlichsten Branchen. Als MCSE SharePoint hat er tiefgreifende Kenntnisse in den Bereichen Microsoft Active Directory, Windows, SharePoint und Office 365. Gerne teilt er seine Projekterfahrung mit Ihnen.

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahren Sie mehr darüber, wie Ihre Kommentardaten verarbeitet werden .