Best Practices für die Planung von Microsoft 365-Migrationen

Was ist das Geheimnis einer Migration, die nicht zu einem totalen Zeitfresser wird? Sie haben es erraten—solide Planungen vor der Migration. Lesen Sie weiter, um die Best Practices zu erlernen, die Sie zum Erfolg führen.

Was ist der Unterschied zwischen einer chaotischen Migration und einer reibungslosen? Nun, es hängt oft davon ab, was vor dem Verschieben von Daten passiert.  

Die Planung vor der Migration dreht sich ganz darum, ein solides Fundament für den Erfolg zu schaffen. Wie das Sprichwort sagt: „Miss zweimal, schneide einmal" – je gründlicher Sie planen, desto weniger Überraschungen und Rückschläge werden Sie während der Migration erleben.  

Das letzte Mal habe ich M365 Migrationsprobleme und ihre Lösung besprochen. In diesem Artikel schauen wir uns an, wie Sie sich ordnungsgemäß auf die Migration vorbereiten, und behandeln die wichtigsten Planungsschritte, die Ihnen Zeit sparen, Risiken reduzieren und Ihre Organisation für einen erfolgreichen Übergang aufstellen. Von der Ausrichtung der Stakeholder auf eine klare Vision bis hin zur Vorbereitung Ihrer Zielumgebung stellt sorgfältige Planung sicher, dass Sie am Tag der Migration voll durchstarten können.

Schauen Sie sich die vollständige Session on-demand an: Erobern Sie die größten Microsoft 365 Migrationsprobleme.

‍Definieren Sie Ihre Vision und den Umfang

Beginnen Sie damit, klar zu definieren, warum Sie zu Microsoft 365 migrieren und was Sie erreichen möchten.  

Vielleicht möchten Sie eine bessere Remote-Zusammenarbeit ermöglichen, alternde lokale Server außer Betrieb nehmen, die Sicherheit verbessern oder unterschiedliche Tools in eine einheitliche Plattform konsolidieren. Die Etablierung der Vision hilft dabei, die Bedeutung des Projekts an Stakeholder und Endbenutzer zu kommunizieren.  

Neben der Vision bestimmen Sie den Umfang der Migration. Migrieren Sie nur Dateien und SharePoint-Sites? E-Mails und Kalender?  Was ist mit Abteilungsanwendungen oder Workflows, die mit SharePoint oder Teams verknüpft sind und für den täglichen Betrieb kritisch sind? Dokumentieren Sie, welche Systeme, Workloads und Geschäftseinheiten im Umfang enthalten sind und welche (vorerst) außerhalb des Umfangs liegen. Dies verhindert später eine Ausweitung des Umfangs. Es ist auch klug, Erfolgskriterien im Voraus festzulegen. Zum Beispiel könnte ein Erfolgskriterium lauten: „Alle Mitarbeiter haben am ersten Tag Zugang zur neuen Umgebung und zu den wichtigsten Inhalten, und Legacy-Systeme werden bis Datum X außer Betrieb genommen." Solche Kriterien geben Ihnen konkrete Ziele, auf die Sie hinarbeiten können.

Als Teil der Umfangsdefinition stellen Sie ein Projektteam und eine Governance-Struktur zusammen. Identifizieren Sie einen Executive Sponsor, der das Projekt unterstützen und bei der Lösung wichtiger Probleme oder Ressourcenbedarf helfen kann. Bestimmen Sie einen Projektmanager oder Migrationsleiter, der alle beweglichen Teile koordiniert. Sie benötigen auch Vertretung aus verschiedenen Bereichen: IT-Betrieb (für Infrastruktur- und Identitätsplanung), Sicherheit/Compliance (um sicherzustellen, dass diese Anforderungen erfüllt werden) und Vertreter der Geschäftseinheiten oder Power User (um für Benutzerbedürfnisse zu sprechen und bei Inhaltsentscheidungen zu helfen). Definieren Sie klar Rollen und Verantwortlichkeiten im Team – wer kümmert sich um die Kommunikation? Wer verwaltet das technische Migrationstool? Wer überprüft, ob Inhalte korrekt migriert wurden? Die frühe Etablierung dieser Governance und Teamstruktur stellt sicher, dass jeder seinen Teil im Plan kennt.

Bewerten Sie Ihre aktuelle Umgebung

Mit dem Umfang im Blick erstellen Sie eine umfassende Bestandsaufnahme Ihrer aktuellen Umgebung. Das bedeutet, zu auditieren, welche Inhalte und Systeme Sie haben und wie sie strukturiert sind.

Wichtige Fragen, die in diesem Stadium zu beantworten sind, umfassen:

• Welche Inhalte haben wir und wo befinden sie sich? Listen Sie alle Repositories auf: Dateifreigaben, SharePoint-Sites, Exchange-Mailboxen, PST-Dateien und andere SharePoint-bezogene Inhalte, vielleicht Inhalte in Google Drive oder anderen Plattformen, falls Sie konsolidieren. Vergessen Sie nicht weniger offensichtliche Datenquellen wie Outlook-Öffentliche Ordner oder in Team-Kollaborationstools gespeicherte Daten, die möglicherweise durch Teams ersetzt werden.
• Wie viele Daten gibt es? Schätzen Sie das Volumen (z.B. Terabytes an Dateien, Anzahl der Sites, Mailboxen und deren Größen usw.). Dies beeinflusst den Zeitplan und die Wahl der Migrationsmethode.
• Wer besitzt oder verwendet diese Inhalte? Identifizieren Sie die Abteilungen oder Gruppen, die verschiedene Inhaltssätze „besitzen". Das Wissen um den Besitzer hilft später bei der Entscheidung, was zu migrieren ist, und beim Erhalt von Genehmigungen zum Verwerfen oder Archivieren von Dingen. Ermitteln Sie auch Benutzerzahlen und ob Sie inaktive Benutzerdaten haben (Dateien oder Mailboxen ehemaliger Mitarbeiter), die möglicherweise nicht migriert werden müssen.
• Was sind die Abhängigkeiten? Dokumentieren Sie alle Abhängigkeiten oder Integrationen. Haben Sie beispielsweise ein Intranet auf SharePoint, das auf bestimmte Dateifreigaben verweist, oder Workflows, die ein Legacy-System mit Ihren Dokumenten verbinden? Das Verständnis dieser Abhängigkeiten hilft bei der Zuordnung bestehender Funktionalitäten zu Microsoft 365-Äquivalenten und gewährleistet Kontinuität und Benutzerzufriedenheit.
• Was sind die Anpassungen und Sonderfälle? Vielleicht haben Sie benutzerdefinierte SharePoint-Webteile oder InfoPath-Formulare oder makrofähige Excel-Tabellen, die auf lokale Pfade angewiesen sind. Listen Sie diese auf. Einige lokale Funktionen haben möglicherweise keine direkten Cloud-Äquivalente, daher benötigen Sie einen Plan (vielleicht einen Prozess neu gestalten oder eine Drittanbieterlösung verwenden oder einige Änderungen in der Funktionalität akzeptieren).

Die Durchführung dieser Bewertung kann eine große Aufgabe sein, aber Migrationstools können helfen. Zum Beispiel können ShareGates Inventar- und Analysefunktionen (als Teil seines Migrationstools) Ihre Umgebung scannen und Berichte über Sites, Größe der Inhalte, ungenutzte oder verwaiste Daten und mehr erstellen. (Falls Sie noch kein Tool haben, ist sogar eine manuelle Tabelle, die diese Elemente verfolgt, besser als nichts!) Das Ergebnis dieser Bewertung ist im Wesentlichen Ihr „Migrationsinventar" und ein klareres Bild des Projektumfangs.

Planen Sie Ihre Informationsarchitektur in Microsoft 365

Wechseln Sie nun den Fokus zum Ziel: Microsoft 365. Ein kritischer Planungsschritt ist das Design der Ziel-Informationsarchitektur und -einstellungen in Microsoft 365 vor der Migration von irgendetwas. Das bedeutet zu entscheiden, wie Sie SharePoint-Sites, Microsoft Teams, OneDrive und andere für Ihre Organisation relevante Komponenten strukturieren werden. Zum Beispiel:

• SharePoint-Struktur: Bestimmen Sie, ob Sie einen einzelnen Intranet-Stil-Hub mit mehreren Sites oder ein stärker verteiltes Modell verwenden werden. Vielleicht erstellen Sie eine moderne Hub-Site für jede Abteilung. Planen Sie Dokumentbibliotheken und wie Inhalte organisiert werden (nach Projekt, nach Funktion usw.). Eine gut durchdachte SharePoint-Architektur macht es für Benutzer einfacher, Inhalte zu finden, sobald sie im neuen System sind.
• Microsoft Teams vs. SharePoint vs. OneDrive: Klären Sie, welche Inhalte wohin gehören. Ein gängiger Ansatz ist: persönliche Arbeitsdokumente gehen zu OneDrive und gewährleisten effiziente Speicherung und Zugriff. Team-/Projektkollaborationsdokumente gehen in Teams (die im Hintergrund SharePoint-Team-Sites verwenden), und organisationsweite oder archivierte Inhalte könnten in dedizierten SharePoint-Kommunikations-Sites leben. Entscheiden Sie, ob Sie als Teil der Migration Teams für bestimmte Gruppen erstellen (z.B. alte E-Mail-Verteilerlisten oder Netzlaufwerk-Ordner durch ein Team ersetzen).
• Berechtigungen und Governance in der neuen Umgebung: Die Planung Ihrer Architektur geht Hand in Hand mit der Planung der Governance. Bestimmen Sie, wer Zugang zu was in der neuen Einrichtung haben sollte, und nutzen Sie Azure Active Directory für optimiertes Identitätsmanagement. Das ist eine Chance, Berechtigungen zu überdenken – vielleicht übermäßig komplexe Berechtigungsschemas zu vereinfachen, die im alten System existierten. Identifizieren Sie, ob es sensible Sites oder Daten gibt, die besondere Behandlung erfordern (z.B. HR- oder Finanzdaten, auf die nur wenige zugreifen sollten). Microsoft 365 bietet robustes Berechtigungsmanagement; planen Sie die angemessene Nutzung von Azure AD-Gruppen, SharePoint-Berechtigungsebenen und Teams-Mitgliedschaft, um die Zugriffskontrollen Ihres aktuellen Systems zu spiegeln (oder zu verbessern).
• Konfigurieren Sie Tenant-Einstellungen im Voraus: Es gibt zahlreiche Einstellungen im Microsoft 365 Admin Center, die Ihre Migration oder die Benutzererfahrung in der neuen Umgebung beeinflussen könnten. Stellen Sie beispielsweise sicher, dass Sie alle notwendigen Lizenzen für Benutzer bereitgestellt haben, die migrieren werden. Konfigurieren Sie SharePoint Online-Einstellungen wie Site-Speicherlimits und überprüfen Sie, dass Freigabeeinstellungen mit Ihren Sicherheitsrichtlinien übereinstimmen (z.B. werden Sie standardmäßig externe Freigabe von Inhalten erlauben oder einschränken?). Wenn Sie E-Mails migrieren, entscheiden Sie im Voraus über Exchange Online-Einstellungen (wie Mailbox-Größenlimits, Spam-Filterung usw.). Im Wesentlichen möchten Sie Ihren Microsoft 365-Tenant vorbereitet und bereit haben, Inhalte und Benutzer zu empfangen.

Es wird auch empfohlen, in diesem Stadium eine Testeinrichtung oder einen Proof of Concept durchzuführen. Falls möglich, erstellen Sie eine kleine Test-Microsoft 365-Umgebung (oder verwenden Sie nur eine Teilmenge Ihres Tenants, wenn Sie in einen Live-Tenant migrieren), um Ihre geplante Architektur zu validieren. Erstellen Sie beispielsweise eine Test-SharePoint-Site und versuchen Sie, einige Beispieldokumente

‍