Productivity News vom 01.08.2021: SharePoint Migrationen – Vorgehen, Tools und Stolpersteine

SharePoint On-Premises Versionen haben, wie jede andere Software, einen Lebenszyklus und auch der geht mal zu Ende. Das bedeutet, dass SharePoint On-Premises Versionen immer wieder auf neuere SharePoint On-Premises Versionen migriert werden müssen. Oder vielleicht entscheidet man sich dafür, eine Fileserver-Dateiablage oder eine on-prem SharePoint Entität in die Cloud nach Microsoft 365 zu migrieren.

In M365 sind keine Migrationen mehr notwendig – neue Updates und Features werden kontinuierlich ausgerollt. Um den End-of-Life eines Microsoft-Produktes nicht zu verpassen, können die Lebenszyklen hier verfolgt werden: Search Product and Services Lifecycle Information – Microsoft Lifecycle | Microsoft Docs. Hier ist auch zu erkennen, dass die herkömmliche SharePoint Server Versionen mind. bis 2026 unterstützt werden. 

Der Blog Beitrag zeigt die verschiedenen Migrationsarten auf und bietet Hilfe bei möglichen Migrationsfragen. Ein strukturiertes Vorgehen ist unerlässlich, um eine SharePoint Migration effizient, sicher und wirkungsvoll über die Bühne bringen zu können.

Update vom Juni 2022: An der 65. Microsoft 365 & SharePoint Community ging IOZ Collaboration-Projektleiter Flavian Burtolf im Detail auf die verschiedenen Arten von SharePoint Migrationen ein und zeigte auf, was es dabei zu beachten gilt.

Was ist eine SharePoint Migration?  

Mit Migration wird ein Plattform-Wechsel bezeichnet, bspw.  von SP2016 auf SP2019 oder SP2019 auf SharePoint Online. Ziel der Migration ist es, mindestens alle Daten auf die neue Plattform zu übernehmen. Je nach Bedarf werden auch ganze Strukturen inkl. Berechtigungen übernommen. Den Wechsel auf einen neuen SQL Server, beim Betrieb von SharePoint On-Premises, oder auch die Ablösung von einem Filesystem wird ebenfalls als Migration bezeichnet. 

Welche Vorgehen und Methoden können bei einer SharePoint Migration genutzt werden? 

Für eine Migration können verschiedene Arten angewendet werden, dies ist allerdings abhängig von Quell- und Ziel-System: 

• Datenbank-Migration; DB-Migration
• Content-Migration 

Eine DB-Migration kann nur On-Premises angewendet werden. Dabei wird die Datenbank auf die nächst höhere SharePoint Version migriert, dies jeweils auf einer neuen SharePoint Farm. Ein auslassen von SharePoint Versionen wird erst mit der neuen SharePoint Server Subscription Edition (Announcement «A new day for SharePoint Server – SharePoint Server Subscription Edition preview») möglich sein, bei vorherigen Versionen ist dies nicht supported. Das bedeutet, dass bei einer Migration von SP2013 auf SP2019 immer auch auf SP2016 migriert werden muss, wie es der offizielle Migrations-Pfad von Microsoft beschreibt. Der Ablauf ist also: SP2013 > SP2016 > SP2019. Bei einer DB-Migration werden möglichst viele Informationen wie Site-Strukturen inkl. Daten, Bibliotheken & Listen, Ansichten & Spalten, Code & Scripts, Workflows, Termstore etc. übernommen. 

Weitere Informationen zu den Migrationsszenarien

Dem gegenüber werden bei einer Content-Migration die Daten auf eine neue Plattform migriert. Die Content-Migration wird hauptsächlich bei der Migration von On-Premises nach SharePoint Online angewendet. Dabei werden auf M365 die Site-Strukturen gemäss den M365-Konzepten aufgebaut, dies mit SharePoint Online oder Microsoft Teams, und die Daten werden dann in die entsprechenden Site-Strukturen migriert. Die Migration der Daten kann dann mit Dritt-Tools (kostenpflichtig wie bspw. Metalogix oder ShareGate), Microsoft Tools (kostenlos) oder auch manuell (copy & paste) vorgenommen werden.  

Mit kostenpflichtigen Dritt-Tools können dann auch mehr Informationen als nur Daten migriert werden, zudem können u.a. auch Metadaten zu Änderungen wie auch Versionshistorien übernommen werden. 

Wie ist das Vorgehen bei SharePoint Migrationen?  

Eine Migration kann grob in die folgenden vier Phasen gegliedert werden:

1. Vorbereitung  

Bei einer Migration ist die Vorbereitung essenziell, um optimale Voraussetzungen für eine erfolgreiche Migration zu schaffen. Einerseits muss das Quell-System detailliert analysiert werden und andererseits muss das Migrationsprojekt geplant werden, je nach Migrationsart und der Ziel-Plattform hat es erhebliche Auswirkungen auf die Benutzer – diese müssen dann entsprechend vorbereitet werden. 

Die Analyse des Quell-Systems kann in zwei Teile gegliedert werden:  

Organisatorisch/Strukturell: Man muss sich einen Überblick über die zu migrierenden Daten und Strukturen verschaffen. Es muss klar sein, was migriert werden soll und was der Anspruch ist. Folgende Fragen können dabei helfen:

• Welche Daten müssen migriert werden?
• Wie sind die Verantwortlichkeiten geregelt?
• Wie sind die Ablagestrukturen aufgebaut?  

Technisch: Aus technischer Sicht muss das Quell-System so weit analysiert werden können, damit man sich ein Bild zu den Grössen-Verhältnissen machen kann. Zudem hat jedes System Limitationen: Diese können das Quell- oder auch das Zielsystem betreffen. Die Restriktionen müssen bekannt sein, um während der Migration nicht plötzlich vor Problemen zu stehen. Bereits im Einsatz stehende oder für die Zukunft geplante Dritt-Tools sind ebenfalls zu berücksichtigen. Es ist frühzeitig zu prüfen, ob diese noch genutzt werden sollen oder ob es in der Zwischenzeit nicht doch bereits andere Möglichkeiten gibt. 

2. Definition & Konzeption 

In dieser Phase wird das Migrationsszenario und die neue Informationsarchitektur definiert. Mit der Migration auf eine neue Plattform oder Version sollen in der Regel auch neuere Funktionen und Möglichkeiten «freigeschaltet» werden. Einerseits müssen also die Daten migriert werden, andererseits möchte man von neuen Gegebenheiten profitieren. Dazu einige Beispiele, um sich die Migrations-Schritte etwas besser vorstellen zu können: 

• Beispiel 1: SharePoint On-Premises Migration SP2016 auf SP2019 

Mit der DB-Migration werden die kompletten Strukturen, Daten, Berechtigungen etc. übernommen. Es sind also höchstwahrscheinlich keine Anpassungen an den Strukturen nötig. Viel mehr kann man sich darum kümmern, ob sich der Inhalt verändert und bspw. das moderne Layout unter SharePoint 2019 übernommen werden soll.

• Beispiel 2: Fileserver-Migration nach SharePoint 

Eine Migration eines Fileservers nach SharePoint ist schon ein etwas grösserer Schritt. Während der Fileserver «nur» als Datenablage genutzt wird, erhält man mit SharePoint ein ganzes Set mit neuen Tools und Funktionen. Dokumentenmanagement-Funktionen wie Co-Authoring, Versionierung, Versionshistory, Inhaltsgenehmigung und allen voran Metadaten können nun genutzt werden. Zudem soll SharePoint nebst der Datenablage auch als Portal (Intranet, Extranet, Digital Workplace) genutzt werden, also ein starker Einschnitt in die Arbeitsweise der Nutzerinnen und Nutzer. Weitere Arbeit im Changemanagement wird auch durch das Ändern von bspw. Pendenzen notwendig: bisher wurden diese in Excel-Listen geführt, neu stehen SharePoint-Listen oder der Microsoft Planner zur Verfügung. Die Arbeitsweise soll optimiert und effizienter gestaltet werden – ein grosser Schritt für die Mitarbeitenden. Um dann auch abgelegte Informationen wieder aufzufinden, bietet SharePoint umfassende Such-Möglichkeiten, um ein Such-Center bedürfnisgerecht anzupassen, müssen Search-Cases definiert werden, um das Such-Center dahingehend zu konfigurieren.

• Beispiel 3: SharePoint On-Premises Migration nach Microsoft 365 

Zwar wird in diesem Fall von SharePoint nach SharePoint migriert, aber die Änderungen sind doch sehr umfassend. Spricht man im Falle von On-Premises «nur» von SharePoint, können in Microsoft 365 eine Vielzahl von Tools genutzt werden, u.a. Teams, Planner, To-Do, Power Platform. Die dadurch entstandenen neuen Möglichkeiten sind zu berücksichtigen und sollen mit der Migration (soweit sinnvoll) implementiert werden. Ebenfalls sollen die Standard-Konzepte genutzt werden und ein Konzept z.B. Teams Berechtigungen Public vs. Private, nicht über den Haufen geworfen werden. 

3. Realisierung und Aufbau 

Um nun migrieren zu können, müssen die On-Premise Server bereitgestellt werden. Bei einer Content-Migration müssen allfällige neue Strukturen aufgebaut werden, um dann die Daten aus der Quelle entsprechend zu übernehmen.  

Test-Migrationen werden vorgenommen, um die Strukturen zu validieren, die Durchlaufzeiten abzuschätzen und Migrationsfehler frühzeitig zu erkennen und diese zu beheben. Alle Arbeiten während der Test-Migration werden in einem Drehbuch festgehalten, so kann dann bei der Live-Migration auf die Dokumentation zurückgegriffen und die Einstellungen erneut vorgenommen werden. Hier können bereits die Super-User miteinbezogen werden, diese prüfen die migrierten Daten auf der neuen Plattform und können dabei direkt mit der neuen Plattform vertraut gemacht werden.  

4. Migration 

Durch den strukturierten Ablauf und den vorhergehenden Phasen kann die Migration gemäss Planung und Drehbuch durchgeführt werden. Wichtig ist, das alle benötigten Ressourcen zum Zeitpunkt der Migration zur Verfügung stehen und genügend Zeit für die Migration, aber auch das Testing eingeplant wird. Die Detail-Planung hilft bei der Migration, sich Schritt-für-Schritt an den Ablauf zu halten. Dazu gehört unbedingt auch ein Go or No-Go Entscheid; quasi der Plan B, falls etwas schief läuft oder «Murphy» Unfug treibt. Die End-Benutzer müssen über die Migration rechtzeitig informiert sein und geschult werden, damit sie nach der Migration möglichst schnell mit der neuen Plattform effizient arbeiten können. 

Mit welchen Massnahmen können Unternehmen den eigenen M365 Tenant auf die anstehende Migration vorbereiten? 

Die Microsoft-Konzepte sollten unbedingt eingehalten werden, das ist eine wichtige Voraussetzung, um dann auch in Zukunft von den vielen Änderungen der Microsoft-Cloud zu profitieren und diese einzusetzen. 

Die Strukturen sollten einfach und transparent gewählt werden und sind so aufzubauen, dass es für Benutzer einerseits klar ist, welche Daten wo abgelegt werden und andererseits, welche Daten wo zu finden sind. Klare Strukturen helfen, Redundanzen abzubauen und Transparenz in die Ablagen zu bringen.  

Mit M365 ändert nicht nur das Ablagesystem, sondern auch die Arbeitsweise für Benutzer. Den Benutzenden muss die Struktur und Idee der Plattform, wie auch den Nutzen vermittelt werden. Diese müssen kommuniziert und geschult werden. Es hilft, wenn Schulungen anhand von UseCases durchgeführt werden, welche Benutzer in der täglichen Arbeit oft vorfinden und anwenden. So widerspiegelt die Schulung die Arbeitsweise der User und Gelerntes kann direkt angewendet werden. 

Welche Tools und Applikationen unterstützten bei einer Migration? 

Die einfachste Migrationsart ist es, die Dateien manuell per Drag-and-Drop hochzuladen, das funktioniert aber nur für kleinere Datenmengen oder die Migration von Daten isolierter Anwendungsfälle (bspw. Projekte werden über SharePoint abgewickelt und vorerst sollen nur diese Projektdaten migriert werden). Bei manuellen Migrationen werden allerdings Metadaten wie bspw. Ersteller und Erstelldatum vom aktuellen Zeitpunkt der Migration übernommen.  

Schon etwas mehr Hilfe bieten die M365 Migrations-Tools von Microsoft. Im SharePoint Admin Center in M365 stehen nebst dem Migration Manager auch das SharePoint Migration Tool und auch Mover zur Verfügung. Diese Tools unterstützen die Migration von Daten in die M365 Cloud. In der Microsoft-Dokumentation sind weitere Details beschrieben: https://docs.microsoft.com/de-de/sharepointmigration/migrate-to-sharepoint-online 

• Migration Manager: Migration von Dateien aus dem Filesystem, Box, Google Workspace oder Dropbox nach M365 
• SharePoint Migration Tool (SPMT): Migration von SharePoint Server 2010, 2013 und 2016 sowie Dateiablagen nach M365 
• Mover: Migration von Cloud-Services in die M365-Cloud 

Noch mehr Unterstützung bieten kostenpflichtige Tools wie bspw. Metalogix oder ShareGate. Diese bieten umfassende Funktionalitäten und Reportings, um Migrationen durchzuführen. Die Einstellungsmöglichkeiten, um die Migrationen durchzuführen, sind sehr vielfältig, ebenso die Reports und Logs, welche bei den Migrationen erstellt werden. Die Migrationen u.a. bei Metalogix gehen über reine Datenmigrationen hinaus: d.h. es können ganze Tenant-Migrationen inkl. AD-Accounts und Exchange Postfächer migriert werden. 

Welches sind die häufigsten Stolpersteine bei SharePoint Migrationen? 

Viele Stolpersteine können durch ein strukturiertes Vorgehen vermieden werden. Die Vorbereitung und Analyse der zu migrierenden Daten und Systeme gibt Aufschluss über den Umfang der Migration und den Anspruch an die Migration. Die Testmigration wird dafür genutzt, um Fehler oder Probleme aufzudecken und diese vor der Migration zu beheben. Zudem können sich die Benutzer rechtzeitig mit der neuen Umgebung vertraut machen und auch bereits neue Funktionen prüfen. 

Stolperstein 1: Mangelhafte Kommunikation an Anspruchsgruppen

Die entsprechenden Benutzergruppen müssen frühzeitig kontaktiert und informiert werden, damit das Vorgehen wie auch der Grund für die Migration kommuniziert werden können. Informiert sein müssen u.a. Management, Benutzer, Service-Dienstleister, Helpdesk. 

Stolperstein 2: Limitationen bei Pfadlänge, Sonderzeichen oder Dateitypen

Wichtig ist die Berücksichtigung von Limitationen, die bei der Migration beachtet werden müssen, die meisten Limits die immer wieder geprüft werden müssen: Pfadlänge, Sonderzeichen, Dateitypen. 

Stolperstein 3: Migrationsgeschwindigkeit wird über- oder unterschätzt

Die Migrationsgeschwindigkeit wird durch viele Faktoren beeinflusst. Mit der Testmigration kann dem etwas entgegengewirkt werden und die Migrationszeit kann ungefähr abgeschätzt werden, aber eine gewisse Unbekannte bleibt immer.  

Fazit 

Die Vorbereitungen und die Analyse sind entscheidend, um das anstehende Migrationsprojekt abstecken und effizient durchführen zu können. Eine Test-Migration und ein Drehbuch sorgen für ein kontrolliertes und strukturiertes Vorgehen. Hier ist in jedem Fall auf die Limitationen zu achten, damit unliebsame Überraschungen ausbleiben. Je nach Umfang kann die Migration mit den Microsoft-eigenen Tools durchgeführt werden; bei komplexeren Projekten lohnt sich die Investition in ein Tool eines Drittanbieters. Die Anspruchsgruppen müssen frühzeitig involviert werden – insbesondere dann, wenn sich mit der neuen Plattform auch Arbeitsweisen ändern.