Migration von Microsoft SharePoint nach Office 365

Migration
Von Microsoft SharePoint nach Office 365

Migration von Microsoft SharePoint nach Office 365

  • Bernhard Schmidt
  • Unified Communications, User Productivity
  • Office 365, SharePoint, Tips

In den Unternehmen ist die digitale Transformation mittlerweile nicht mehr aufzuhalten. Besonders der Umzug von Daten in Cloud ist dabei ein wesentlicher und vielschichtiger Prozess. Welche Vorkehrungen müssen getroffen werden, um den Umzug von SharePoint On-Premises auf SharePoint Online reibungslos zu gestalten und die über viele Jahre gesammelten Daten zu erhalten? Verschiedene Szenarien müssen bedacht und eine geeignete Roadmap erstellt werden. Bernhard Schmidt gibt einen kleinen Einblick in das tägliche Arbeitsfeld der SharePoint Experten von SoftwareONE, die Unternehmen erfolgreich auf dem Weg in die Cloud begleiten.

 

Während in den Unternehmen der Trend, die Anforderungen der IT in der Cloud umzusetzen nach wie vor zunimmt, muss für eine Umsetzung in der Praxis häufig noch eine Reihe von Aufgaben erledigt werden. Kein Problem stellt dabei für gewöhnlich die Bereitstellung der Ressourcen zum Beispiel in der Microsoft Office 365 Cloud dar. Sobald in einem ersten Schritt die Synchronisation des lokalen Active Directory (AD) mit dem Azure Active Directory (AAD) realisiert ist, sind die prinzipiellen Anforderungen für eine Nutzung der Office 365 Funktionen bereits gegeben.

Vorausgesetzt, es handelt sich bei dem Unternehmen nicht um ein Start-Up, in dem noch keine nennenswerten Bestandsdaten existieren, wird man üblicherweise sehr schnell mit der Frage konfrontiert, was mit den über viele Jahre gesammelten Daten passieren soll?

Meistens ist dabei klar, dass eine Migration der Alt-Daten der einzige zielführende Weg ist. Doch was dafür zu tun ist, hängt davon ab, in welchen Systemen die Daten und Dokumente bislang gespeichert wurden. Oft existiert eine SharePoint Farm (oder sogar mehrere), auf welcher die Daten und Dokumente in unterschiedlichen Strukturen gespeichert sind. Durch Zusammenführung von Unternehmen oder bei Abtrennung von Unternehmensteilen existiert oftmals bereits ein Mandant in der Office 365 Cloud, so dass in manchen Fällen auch SharePoint Online bereits zum Einsatz kommt. Für den Fall, dass der Office 365 Ziel-Mandant nicht identisch mit dem bereits genutzten ist, muss ebenfalls die Frage geklärt werden, wie die Daten und Dokumente zwischen den Office 365 Mandanten (Tenants) zu migrie-ren sind.

Dieser Artikel beschäftigt sich daher mit der Migration von SharePoint On-Premises oder SharePoint Online nach SharePoint Online in einem neuen Office 365 Mandanten.

Mögliche Variationen – Eine Frage der zukünftigen Verwendung

Als wäre die Anforderung einer sauber geplanten und strukturierten Überführung der Daten und Dokumente noch nicht genug, bieten sich für die zukünftige Nutzung der Informationen tatsächlich verschiedene Optionen an. Zu klären sind in diesem Zusammenhang insbesondere die Fragen:

  • Erfolgt eine gemeinsame Nutzung zusammen mit externen Teilnehmern?
  • Sollen für die Zusammenarbeits-(Collaboration-)Bereiche zukünftig Teams an Stelle der reinen SharePoint Team Sites genutzt warden?

Darüber hinaus gibt es auch Konstrukte, welche zunächst nur eine Integration von Office 365 Gruppen auf der Agenda haben. Ebenfalls ist es bei der Planung der künftigen Architektur sinnvoll, bereits die neuen Möglichkeiten von SharePoint Online im Kontext von Office 365 zu berücksichtigen.

Bevor also eine Migration in Betracht gezogen wird, gilt es zunächst einmal die zukünftigen Nutzungsszenarien im Zusammenhang mit der Gesamtarchitektur auszuarbeiten. Mit anderen Worten, wenn für das Zielszenario das „Big Picture“ fehlt, dann ist das Projekt bereits vor Beginn der Migration zum Scheitern verurteilt.

Vorgehensweise für die SharePoint Migration nach Office 365

Im Folgenden sind die Aufgaben beschrieben, welche zur Planung und Umsetzung der Migration von SharePoint Inhalten zu erledigen sind:

1. Bestandsaufnahme der bestehenden Microsoft SharePoint Server Installation(en)

Als Grundlage für eine zielführende Strategie ist es wichtig zu wissen, welche Technologie und Skalierung tatsächlich im Einsatz ist (insbesondere SharePoint Versionen, Servernamen und Basisinformationen der Installation(en)). Wenn es sich um SharePoint Online handelt, werden entsprechend die Informationen zum Office 365 Mandanten benötigt.

2. Analyse der SharePoint Plattform nach Inhalt und Anwendungen

Um eine Basis für die technische und zeitliche Planung der Migration zu bekommen, werden detaillierte Informationen zur bisherigen Implementierung und Nutzung der aktuellen Plattform benötigt. Die Inventur sollte dabei von den Datenbeständen bis zu den Anwendungsfällen von eingesetzten Lösungen gehen und auch eine Typisierung der Lösungen selbst vornehmen.

3. Erstellung eines Konzeptes, um die erforderlichen Anwendungen nach Office 365 zu portieren

Dabei wird ebenfalls entschieden, auf welche Anwendungen künftig verzichtet werden kann. In Abhängigkeit davon, welche Technologie eingesetzt wurde, gibt es unterschiedliche Wege der Portierung, die auch durch geeignete Werkzeuge unterstützt werden. Als Ergebnis sind die portierten Anwendungen in der Office 365 Cloud verfügbar und können mit SharePoint Online genutzt werden.

4. Analyse des Inhalts der SharePoint Farm hinsichtlich Datenmengen und Strukturen

Als Grundlage dienen zum einen die Inhaltsdatenbanken (Datenvolumen), im Detail erfolgt eine Auswertung auf Basis von:

  • Webanwendungen
  • Site Collections
  • Sites ((Unter-)Websites)
  • Bibliotheken und Listen

Hier gilt der Ansatz: „je granularer die Informationen, desto effektiver die Auswertung“. Die ermittelten Informationen fließen unmittelbar in die weitere Planung ein, so dass sich durch Abgleich der Segmentierung mit der Organisationsstruktur eine realistische Roadmap erstellen lässt, welche eine gezielte Kommunikation an die Anwender erlaubt!

Zur Erhebung der Daten können bedarfsweise auch gängige Tools verwendet werden. Ein kostenloses Skript ist beispielsweise im Microsoft "TechCenter" unter dem englischen Titel "Get detail report of all Documents in SharePoint site using Powershell" erhältlich. Ebenfalls bieten die meisten Migrationstools akkurate Berichte zur Planung an.

5. Die Auswahl des Werkzeugs für die Migration

Eine Übersicht gängiger Hersteller findet sich bei Gartner. Hinsichtlich der tatsächlichen Eignung lohnt es allerdings, sich ein eigenes Bild zu verschaffen, zumal die Hersteller sehr aktiv bei der (Neu-)Ausrichtung ihrer Tools sind. Anders gesagt ist das „Overall Rating“ nicht der Weisheit letzter Schluss, besser ist es jeweils für die konkrete Situation das optimale Werk-zeug zu identifizieren.

6. Testen, testen, testen

Nachdem das Migrations-Tool eingerichtet ist, gilt es im Rahmen einer Test-Migration mit einer eingeschränkten Datenmenge Erfahrungen zu sammeln und festzustellen, ob das Migrationsergebnis den Erwartungen entspricht. Ergeben sich bei den Tests Schwierigkeiten, lassen sich diese bereits frühzeitig analysieren und adäquate Lösungen dafür erarbeiten. Diese Schwierigkeiten lassen sich so bei der produktiven Migration unmittelbar vermeiden oder beheben.

7. Erst jetzt beginnt die Planung der Migration

Nachdem die Voraussetzungen geschaffen wurden, geht es jetzt an die Planung der eigentlichen Migration. Sie berücksichtigt insbesondere folgende Aspekte:

  • Zeitliche Planung und Datenmengen, die innerhalb der definierten Zeitabschnitte transportiert werden können
  • Neu-Zuordnung der Site Strukturen soweit dies notwendig ist (Grundsätzlich ändert sich die Stamm-URL immer, auch bei SharePoint Online, da die Subdomäne nur einmal verfügbar ist)
  • Kommunikation an die Anwender – Einer der wichtigsten Aspekte, wird jedoch leider oft vernachlässigt
  • Testen und Probleme beheben (Da sich nicht alles im Vorfeld vorhersehen lässt, ist es wichtig, hierfür auch Budget und Zeit einzuplanen)

8. Die Anwender-Kommunikation

Hier sollten auch relevante Governance-Aspekte wie neue Verantwortlichkeiten und angepasste Prozesse berücksichtigt werden. Allein durch die geänderten Rollen in der Administration sind hier praktisch immer Verschiebungen zu erwarten, hinzu kommen häufig neue Themen zu Bereichen wie Sicherheit und Compliance.

9. Start der produktiven Phase

Sind die vorherigen Punkte alle erledigt, kann die produktive Migration der Inhalte gestartet werden. Auch hierbei ist eine Kommunikation an die Anwender wichtig, damit diese ab sofort auf die neuen Adressen zugreifen. Optimierende Maßnahmen können hier zum Beispiel sein:

  • Umleitungs-Links auf den alten SharePoint Adressen, welche auf die neuen Office 365 Adressen verweisen.
  • Sicherstellen, dass auf die ursprünglichen Sites bzw. Site Collections nicht mehr schreibend zugegriffen werden kann.

10. Umleitungen einrichten

An den Stellen, wo Anwendungen beteiligt sind, erfolgt eine Verlinkung innerhalb der Navigation auf den Intranet-Seiten. Dort ersetzen sie die ursprünglichen Links auf die Anwendungs-Adressen.

11. Abhängigkeiten prüfen

Nachdem alle Inhalte vollständig migriert sind, ist es ratsam die Umleitungssites für einen akzeptablen Zeitraum (z.B. 4- 12 Wochen) beizubehalten und im Anschluss daran die Farm herunterzufahren. So lassen sich Abhängigkeiten nachvollziehen, die vorab nicht berücksichtigt wurden. Im Fall von SharePoint Online werden der Einfachheit halber nur die Berechtigungen der Nutzer gekappt.

12. Wenn alles funktioniert,

... können die Server der SharePoint Farm sowie die zugehörige SQL In-stanz de-provisioniert werden und die Ressourcen ggf. für andere Zwecke zum Einsatz ge-bracht warden.

13. Anwender-Prozesse definieren

Damit ein stabiler und nachhaltiger Betrieb in der Cloud möglich ist, müssen entsprechende Governance-Prozesse definiert und etabliert werden. Die Governance-Aspekte sollten spätestens dann geregelt sein, wenn die Anwender anfangen, produktiv auf SharePoint Online in der Office 365 Umgebung zu arbeiten.

14. Backups sicherstellen

Zwar betrifft es nicht die Migration selbst, dennoch ist es ratsam, sich möglichst früh Gedanken darüber zu machen, ob die Wiederherstellungsmechanismen der Office 365 Cloud ausreichend sind oder ob ggf. auch Backup- und Restore mit Hilfe eines geeigneten Tools (bzw. Service) organisiert werden sollen. Die Aufbewahrungszeiten und Service-Level müssen dabei nicht zwingend mit den zuvor in der On-Premises-Welt definierten Standards übereinstimmen.

Was passiert mit den MySites  bzw. OneDrive for Business?

Sofern die MySites oder OneDrive for Business im Alt-System bereits genutzt wurden, werden diese analog zur der eben beschriebenen Methodik migriert. In den meisten Fällen sind die gleichen Tools problemlos in der Lage dies zu bewerkstelligen. Die Komplexität ist indes deutlich geringer, so dass Planung und die Testläufe im Vorfeld deutlich schneller von der Hand gehen.

Befinden sich die Daten auf Fileserver-basierten Anwender-Freigaben, kann der Umzug ebenfalls zumeist mit den gleichen Migrationstools durchgeführt warden.

Für die praktische Nutzung von OneDrive for Business sollte unbedingt der OneDrive for Business Client genutzt werden, der für eine zielgerichtete Synchronisation der Inhalte sorgt.

Fazit

Die Migration von SharePoint in die Office 365 Cloud ist ein komplexer Vorgang mit vielen Schritten. Wichtig ist es deshalb, bei Planung und Vorbereitungen die notwendige Sorgfalt walten zu lassen und sich für die Durchführung genügend Zeit einschließlich Pufferzeiten einzuplanen. Wählt man dazu noch ein Tool aus, das für das bestehende Szenario optimal geeignet ist, lässt sich das Migrationsvorhaben üblicherweise sehr gut handhaben.

Abgesehen von der Migration bringt die Cloud neue Governance-Aspekte nicht nur für klassische Betriebsthemen sowie Backup und Restore. Gerne bietet Ihnen hierbei SoftwareONE tatkräftige Unterstützung zu Planung und Umsetzung in Form Ihres Unified Cloud Management (UCM) an.

In this case, “changes” are usually based on sudden alterations of requirements during the project or on the realization that the implementations of specifications will be more complex – or indeed impossible – in the manner that was originally intended.

So in these cases, change management does indeed mean a significant intervention in the project. The risk management methods that are applied additionally and simultaneously are insufficient to guarantee success of the project. The necessary instruments will also require flexible handling.

If the situation boils down to the duration of the project as the principle aspect, it will be necessary during change to check whether the technical requirements (e.g. product version, support services) and other factors have become different as well. Doing so ensures that the preconditions defined in the original planning retain their validity.

While in practical settings there may certainly be circumstances that make change (specifically in ongoing projects) necessary (e.g. changes in case law or legislation), the majority of changes that are typically encountered can be prevented by prudent investments in the identification of requirements and in project planning. Meaningful “requirements engineering” (recording and analyzing requirements as an upstream process) and other processes can help to avoid this type of “changes”.

This statement retains its validity for the agile approach as well. After all, it is absolutely essential that any components of the solution that require smooth integration in the platform are clearly defined in the architecture and that their functions are implemented purposefully.

It goes without saying that when planning and introducing new solutions, it is not unusual that a clear perception of the final product does not exist at the start of the project, and that it cannot even be defined unambiguously in the specifications of requirements themselves.

And while this may seem like the ideal scenario in which to work with agile methods, it would often be a fatal error to plan the broadest possible deployment from the word go. After all, the extremely high likelihood of necessary changes would merely cause confusion among users when the new solution is rolled out – not to mention significant added costs.

A suitable approach in the development of one or several candidates for a purposeful solution would be to implement prototypes for various options and to compare their suitability for the relevant case scenario. A targeted PoC (Proof of Concept) can then be implemented with the most auspicious candidates to check whether they do indeed tick all the boxes.

The following steps can then be planned with the usual degree of dynamism and agility as is ordinarily encountered and frequently necessary in our modern world of permanent transformation.

Do you Need help with Your SharePoint?

Get an overview on our SharePoint Services or contact our experts directly.

Get Advise Now
  • Donnerstag 12 Juli 2018

Kommentieren Sie diesen Artikel

Hinterlassen Sie einen Kommentar, um uns mitzuteilen, was Sie von diesem Thema halten!

Kommentar hinterlassen

Autor

Bernhard Schmidt Senior Consultant SharePoint and Office 365

Modern Workplace and Microsoft Products

Related Articles

  • 13 November 2019
  • Henrik Krumbholz
  • User Productivity

Requirements Engineering: Gründe für und gegen RE

Requirements Engineering (RE) meint das Anforderungsmanagement im Rahmen eines Projektes. Wir zeigen, wie und warum RE sinnvoll ist und in welchen Situationen es Anwendung finden sollte.

  • 07 November 2019
  • Stephan Schaare
  • Unified Communications, Publisher Advisory
  • Microsoft, Teams, Office 365

Microsoft Teams in Kombination mit anderen Office-365-Diensten

Mit Microsoft Teams lassen sich auch weitere Office-365-Dienste nutzen und verbinden. Erfahren Sie, welche Dienste konkret wie nutzbar sind.