Google Workspace zu Microsoft 365 migrieren

Eine Migration kann im Administrations-Dashboard erfolgreich aussehen und dennoch für Beschäftigte scheitern: Ein delegiertes Postfach verschwindet, eine geteilte Ablage landet beim falschen Team, ein Besprechungsraum bleibt unbuchbar oder bestehende Links führen ins Leere. Deshalb sollte man Google Workspace zu Microsoft 365 migrieren, indem man das Vorhaben als geschäftliche Umstellung statt als Massenkopie von Daten behandelt.

Auch das Ziel ist mehr als eine Sammlung von Ersatzanwendungen. Aus Gmail werden Exchange Online und Outlook; persönliche Inhalte aus Drive wechseln in der Regel zu OneDrive; für geteilte Ablagen ist meist eine bewusst geplante Informationsarchitektur in SharePoint oder Teams erforderlich. Aus Google-Identitäten werden Identitäten in Microsoft Entra ID. Gleichzeitig müssen vertraute Arbeitsweisen rund um Labels, Freigaben, Besprechungen und die Bearbeitung im Browser in ein neues Betriebsmodell übertragen werden.

Dieser Leitfaden folgt einer Reihenfolge, die kleine und mittlere Unternehmen sowie IT-Administratoren tatsächlich anwenden können: Bestand erfassen, Abonnements auswählen, Identitäten und Koexistenz vorbereiten, E-Mails und Dateien migrieren, einen Pilotversuch durchführen, DNS umstellen, das Ergebnis validieren und Benutzer unterstützen. Die Werkzeuge und Mandantenoberflächen von Microsoft entwickeln sich weiter. Nutzen Sie deshalb zu Projektbeginn die aktuelle Microsoft-Übersicht zur Migration als verbindliche Quelle für das konkrete Vorgehen.

Inhaltsverzeichnis

1. Warum Unternehmen migrieren – und wann sie es nicht tun sollten
2. Zuordnung der Arbeitslasten von Google zu Microsoft
3. Phase 1: Bestandsaufnahme und Business Case
4. Phase 2: Lizenzierung und Zielarchitektur
5. Phase 3: Identitäten, Domänen und Koexistenz
6. Phase 4: Gmail, Kalender und Kontakte
7. Phase 5: Drive und geteilte Ablagen
8. Pilot, Umstellung, DNS und Rückfallplan
9. Validierung und häufige Fehler
10. Benutzerakzeptanz und Veränderungsmanagement
11. Kontrolle von Kosten, Risiken und Zeitplan
12. Microsoft 365 über Licendi auswählen
13. Häufig gestellte Fragen

Warum Unternehmen migrieren – und wann sie es nicht tun sollten

Die meisten Unternehmen wechseln nicht, weil eine Suite jeden Funktionsvergleich gewinnt. Sie wechseln, weil Microsoft 365 besser zur übrigen Umgebung passt. Windows-Geräteverwaltung, Office-Desktopanwendungen, Teams, SharePoint, Microsoft Entra ID und die Sicherheitsdienste von Microsoft können für ein Unternehmen, das bereits in Microsoft-Technologie investiert hat, eine einheitlichere Plattform bilden. Eine Fusion kann einen gemeinsamen Mandanten verlangen. Ein Kunde oder eine Aufsichtsbehörde kann strengere Gerätekontrollen fordern. Die Finanzabteilung möchte vielleicht überlappende Werkzeuge reduzieren. Benutzer benötigen möglicherweise anspruchsvolle Abläufe in Excel, Word oder PowerPoint, die sich in einer primär browserbasierten Zusammenarbeit nur umständlich abbilden lassen.

Diese Gründe tragen nur, wenn das Ziel ein klar definiertes Problem löst. Ein mit Google Workspace erfolgreiches Unternehmen mit wenig Microsoft-Know-how und Google-spezifischer Zusammenarbeit kann erhebliche Störungen ohne ausreichenden Nutzen erleben. Gleiches gilt, wenn ein attraktiver Abonnementpreis das Projekt antreibt, aber Migrationsarbeit, Parallelbetrieb, Schulungen, Drittanbieterwerkzeuge, Nacharbeiten und zusätzlicher Support unberücksichtigt bleiben.

Verschieben Sie die Migration, wenn das Quellsystem nicht vollständig inventarisiert ist, wichtige Anwendungen von ungeprüften Gmail- oder Drive-Integrationen abhängen, die Verantwortung für Identitäten ungeklärt ist oder ein Sponsor auf Führungsebene für die Veränderung bei den Benutzern fehlt. Prüfen Sie auch eine Komplettumstellung zu einem einzigen Termin erneut, wenn gesetzliche Aufbewahrungssperren, regulierte Daten, komplexe geteilte Ablagen oder geschäftskritische E-Mail-Routen eine stufenweise Validierung erfordern. Die richtige Entscheidung kann eine Migration in Phasen, eine zeitlich begrenzte Koexistenz oder vorerst gar keine Migration sein.

Zuordnung der Arbeitslasten von Google zu Microsoft

Der vertraute Eins-zu-eins-Vergleich verdeckt wichtige Architekturentscheidungen. Insbesondere sollte eine geteilte Google-Ablage nicht automatisch zu einer einzigen riesigen SharePoint-Website werden. Auch Google-Chatbereiche lassen sich nicht sauber auf jede denkbare Teams-Struktur übertragen. Nutzen Sie die Tabelle als Ausgangspunkt und planen Sie anschließend nach Eigentumsverhältnissen und tatsächlichen Arbeitsweisen.

Phase 1: Bestandsaufnahme und Business Case

Beginnen Sie mit belastbaren Fakten. Exportieren Sie Benutzer, Gruppen, Aliase, gesperrte und archivierte Konten, gemeinsame Postfächer oder delegierte Zugriffe, Ressourcen, Routingregeln, Domänen, mobile Geräte, OAuth-Anwendungen von Drittanbietern und administrative Rollen. Erfassen Sie bei den Dateien persönliche Ablagen und geteilte Ablagen, Eigentümer, externe Freigaben, Dateitypen, Elementzahlen, Gesamtvolumen, übergroße Dateien, tiefe Pfade und Inhalte ohne eindeutig verantwortliche Person. Nehmen Sie Anforderungen an die Aufbewahrung oder rechtliche Sperren aus Google Vault in denselben Arbeitsbereich auf. Ein Migrationswerkzeug ersetzt keine Analyse des Records Management.

Erstellen Sie ein Abhängigkeitsregister: Welche Anwendungen versenden über Gmail, welche Scanner, Websites und Geschäftssysteme nutzen SMTP, und welche Abläufe benötigen Apps Script, Google Formulare, Tabellenmakros, Drive-Verknüpfungen oder feste URLs? Welche Teams teilen Dokumente extern? Eine Ampelbewertung genügt: Grün für Standardarbeitslasten, Gelb für Konvertierungs- oder Berechtigungsrisiken und Rot für nicht unterstützte oder geschäftskritische Abhängigkeiten mit eigenem Plan.

Überführen Sie die Bestandsaufnahme in einen Business Case mit messbaren Ergebnissen. Beispiele sind die Konsolidierung der Identitäten, die Bereitstellung verwalteter Desktopanwendungen, bessere Gerätekonformität, weniger doppelte Werkzeuge für die Zusammenarbeit oder eine einheitliche Steuerung von Dokumenten. Ermitteln Sie einen Ausgangswert für Ausgaben für Abonnements, Supportaufwand, Speicher, Sicherheitswerkzeuge und Benutzererfahrung. Berücksichtigen Sie die Kosten des Parallelbetriebs beider Plattformen während der Migration und eine Reserve für Nacharbeiten. Versprechen Sie keine Einsparungen, bevor Zielarchitektur und Benutzerprofile feststehen.

Benennen Sie Verantwortliche für Identitäten, E-Mail, Dateien, Sicherheit, DNS, Compliance, Anwendungen, Kommunikation und fachliche Abnahme. Die Projektleitung koordiniert diese Personen, kann jedoch nicht stillschweigend jede Entscheidung übernehmen. Halten Sie Kriterien für Fortsetzung oder Abbruch bereits jetzt fest, bevor Termindruck schwache Nachweise plötzlich ausreichend erscheinen lässt.

Phase 2: Lizenzierung und Zielarchitektur

Lizenzieren Sie nach Benutzerprofilen, nicht nach Stellenbezeichnungen. Eine browserbasiert arbeitende Person, ein Finanzanalyst mit Desktop-Excel und eine Administration für vertrauliche Daten können verschiedene Pläne brauchen. Klären Sie je Person den Bedarf an gehosteter E-Mail, Office-Desktopanwendungen, Geräteverwaltung, Bedrohungsschutz, Compliance-Funktionen oder reinen Anwendungsrechten. Prüfen Sie zudem Werkzeugvoraussetzungen und Zielspeicher; ein Konto lizenziert nicht automatisch jeden Dienst oder jede Sicherheitsfunktion. Dokumentieren Sie außerdem, wer Lizenzänderungen genehmigt und wie Pilotlizenzen nach der Umstellung angepasst werden. So vermeiden Sie unnötige Dauerlizenzen und behalten die tatsächlich benötigten Funktionen je Benutzerprofil im Blick.

Für viele kleinere Unternehmen eignet sich Microsoft 365 Business Basic für Benutzer, die vor allem Cloud-Dienste und Produktivitätsanwendungen im Web oder auf Mobilgeräten benötigen. Business Standard ergänzt Desktopanwendungen für Personen, die Office lokal installieren müssen. Business Premium verbindet die Produktivitätsplattform mit zusätzlichen Funktionen für Identität, Geräteverwaltung und Sicherheit. Prüfen Sie die aktuellen Ressourcen zu Business Premium, statt davon auszugehen, dass jede Kontrolle automatisch enthalten oder konfiguriert ist. Produktnamen, Nutzungsrechte und Verfügbarkeit können sich ändern; bestätigen Sie daher vor dem Kauf die geltenden Geschäftsbedingungen.

Entwerfen Sie das Ziel, bevor Sie Daten kopieren. Definieren Sie akzeptierte Domänen, Benutzerprinzipalnamen, Aliase, Exchange-Empfänger, die Bereitstellung von OneDrive, die SharePoint-Websitearchitektur, die Benennung in Teams, Eigentümer von Gruppen, externe Freigaben, Aufbewahrungsbezeichnungen, Vertraulichkeitskontrollen und administrative Rollen. Legen Sie fest, wo persönliche Arbeitsdateien enden und Teamunterlagen beginnen. Wenn jede geteilte Ablage dem OneDrive einer einzelnen Person zugeordnet wird, kann die Migration technisch abgeschlossen sein und dennoch vom ersten Tag an ein Eigentumsproblem schaffen.

Setzen Sie das Prinzip der geringsten Rechte um. Trennen Sie Migrationsoperatoren von globalen Administratoren, sofern die Werkzeuge dies unterstützen, schützen Sie Notfallkonten und lizenzieren Sie den Pilotbereich früh genug, um Richtlinien zu konfigurieren und Arbeitslasten zu testen. Die aktuelle geführte Einrichtungsabfolge für Google Workspace von Microsoft kann die Erstkonfiguration in geeigneten Szenarien kleiner Unternehmen vereinfachen. Sie sollte jedoch Teil Ihrer Architektur sein und diese nicht ersetzen.

Phase 3: Identitäten, Domänen, Sicherheit und Koexistenz

Die Zuordnung von Identitäten ist das Bindeglied zwischen E-Mail und Dateien. Vereinheitlichen Sie primäre E-Mail-Adressen, Aliase, doppelte Namen und Gruppenadressen vor der Migration. Entscheiden Sie, ob der Benutzerprinzipalname in Microsoft Entra mit der primären E-Mail-Adresse übereinstimmen soll. Erstellen Sie eine kontrollierte Zuordnungsdatei, die jeden Google-Benutzer und jede Google-Gruppe genau mit einem Zielobjekt verbindet. Dazu gehören auch ehemalige Beschäftigte, deren Daten aufbewahrt werden müssen. Testen Sie Sonderzeichen, umbenannte Benutzer und mehrere Domänen, statt anzunehmen, dass identische E-Mail-Adressen jeden Fall lösen.

Microsoft stellt geeigneten Mandanten inzwischen Google Identity Sync bereit. Die aktuelle Microsoft-Dokumentation beschreibt eine unidirektionale Synchronisierung von Benutzern und Gruppen aus Google Workspace nach Microsoft 365 und nennt Bedingungen zu Mandantengröße und Zuordnung. Bereits vorhandene Zielbenutzer werden nicht einfach überschrieben, archivierte Benutzer anders als aktive oder gesperrte Benutzer behandelt und externe Gruppenmitglieder oder Mitglieder mit benutzerdefinierten Berechtigungen können eine gesonderte Bearbeitung erfordern. Prüfen Sie die aktuellen Teilnahmebedingungen und Berichte, bevor Sie diese Lösung anstelle einer skriptbasierten oder externen Bereitstellung wählen.

Fügen Sie die Unternehmensdomäne in Microsoft 365 hinzu und bestätigen Sie sie, ohne den produktiven E-Mail-Fluss vorzeitig zu verschieben. Konfigurieren Sie die grundlegende Sicherheit, bevor Benutzer echte Daten erhalten: Multi-Faktor-Authentifizierung, Conditional Access bei entsprechender Lizenz, Rollentrennung, Überwachungsprotokollierung, Geräte- oder Anwendungsschutz, Regeln für externe Freigaben und Wiederherstellungskonten. Wenden Sie während der Umstellung keine ungeprüfte Richtlinie auf das gesamte Unternehmen an. Nutzen Sie Pilotgruppen und stellen Sie sicher, dass Administratoren eine Kontosperre beheben können, ohne Kontrollen abzuschwächen.

Koexistenz benötigt einen ausdrücklich festgelegten E-Mail-Fluss. Der klassische automatisierte Exchange-Weg verwendet Routingdomänen, damit Benutzer beider Plattformen während gestaffelter Migrationsbatches E-Mails austauschen können. Die Migrationsvoraussetzungen von Microsoft beschreiben die Bereitstellung von E-Mail-Benutzern, die Einrichtung von Routing-Unterdomänen und die Überprüfung der Weiterleitung. Die konsolidierte Microsoft-365-Oberfläche und Simplified Gmail Migration können verändern, welche Schritte automatisiert werden. Folgen Sie deshalb der in Ihrem Mandanten gewählten Methode, statt Anweisungen verschiedener Wege zu vermischen.

Behalten Sie während der Koexistenz eine einzige verbindliche Quelle für den Kontostatus. Legen Sie fest, wo neue Benutzer angelegt werden, wo Kennwort- oder Verbundänderungen erfolgen, wie ausscheidende Personen deaktiviert werden und wie Gruppenmitgliedschaften gepflegt werden. Vermeiden Sie kurz vor der Umstellung unnötige Umbenennungen. Wenn sich Identitäten verändern, während Dateien und Berechtigungen zugeordnet werden, können die resultierenden Fehler wie zufällige Migrationsprobleme wirken, obwohl mangelhafte Governance die eigentliche Ursache ist.

Phase 4: Gmail, Kalender und Kontakte migrieren

Wählen Sie die E-Mail-Methode nach der Bestandsaufnahme. Die automatisierten Batch-Werkzeuge von Microsoft im Exchange Admin Center können E-Mails, Regeln, Kalender und Kontakte übertragen. Sie unterstützen gestaffelte Batches, was hilfreich ist, wenn das Unternehmen nicht alle Personen gleichzeitig umstellen kann. Das aktuelle Microsoft 365 Admin Center bietet außerdem eine konsolidierte Migrationserfahrung für Google Workspace. Bei der Simplified Gmail Migration führt eine Anwendung aus dem Google Marketplace kleinere Unternehmen durch die Postfachmigration. Verfügbarkeit und Eignung können sich ändern; kein einzelner Weg ist universell einsetzbar.

Erfüllen Sie für den klassischen automatisierten Weg die jeweiligen Voraussetzungen für Dienstkonto, API, Administratorrolle, Routingdomäne und Empfänger. Erstellen Sie Migrationsbatches anhand einer geprüften Benutzerliste und nicht aus einer improvisierten Tabelle, die erst am Tag der Umstellung zusammengestellt wurde. Beginnen Sie mit einem Vorablauf, der historische Inhalte kopiert, während die Benutzer weiterhin in Google arbeiten. Prüfen Sie Synchronisierungsfehler, korrigieren Sie Ausnahmen und starten oder setzen Sie den Vorgang wie unterstützt erneut fort. Eine abschließende Synchronisierung kurz vor der Umstellung verkleinert die Lücke, rechtfertigt aber kein Versprechen von null Ausfallzeit.

Die Übersicht zur automatisierten Batch-Migration dokumentiert wichtige Grenzen. Im klassischen Batch-Verfahren werden freigegebene Kalender und Ereignisfarben nicht migriert; Raumbuchungen werden nicht migriert; Abwesenheits- und automatische Antworteinstellungen werden nicht migriert; und für Gmail-Labels sowie einige benutzerdefinierte Kontaktfelder oder URLs bestehen Einschränkungen. Dokumentiert sind höchstens drei E-Mail-Adressen pro Kontakt. Die Standardgrenze für eine einzelne Nachricht beträgt 35 MB und kann bis auf 150 MB konfiguriert werden. Behandeln Sie diese Punkte als Testfälle und Themen der Benutzerkommunikation, nicht als Fußnoten, die erst nach der Umstellung entdeckt werden.

Erstellen Sie neu, was sich nicht sauber migrieren lässt. Legen Sie Raum- und Gerätepostfächer in Exchange an, weisen Sie Buchungsrichtlinien zu, erstellen Sie erforderliche freigegebene Kalender neu, dokumentieren Sie Stellvertretungen und bitten Sie Benutzer, Serientermine nach der Umstellung zu prüfen. Gmail-Labels verhalten sich nicht genau wie Outlook-Ordner oder -Kategorien, insbesondere wenn eine Nachricht mehrere Labels trägt. Kontrollieren Sie repräsentative markierte Nachrichten und erklären Sie das Ergebnis, bevor Benutzer davon ausgehen, dass Daten fehlen.

Nutzen Sie für den gewählten automatisierten Weg das aktuelle Verfahren im Exchange Admin Center. Überwachen Sie Elementzahlen, übersprungene Elemente, Fehlerursachen und den Zeitpunkt der letzten Synchronisierung. Deaktivieren oder ändern Sie Aufbewahrungs- und Archivrichtlinien am Ziel, wenn die Microsoft-Methode dies erfordert. Ein durch eine Richtlinie verschobenes oder gelöschtes Element kann bei der Überprüfung fälschlich als fehlend erscheinen. Löschen Sie Google-E-Mails nicht sofort, nur weil das Dashboard grün ist. Bewahren Sie die Quelle für ein vereinbartes Validierungs- und Aufbewahrungsfenster auf.

Phase 5: Drive und geteilte Ablagen migrieren

Eine Dateimigration ist ein Projekt der Informationsarchitektur, das sich als Kopiervorgang tarnt. Persönliche Arbeitsinhalte werden normalerweise von Meine Ablage nach OneDrive übertragen. Geteilte Ablagen im Eigentum eines Teams gehören in SharePoint-Websites, die häufig über Teams zugänglich gemacht werden. Entscheiden Sie vor dem Anlegen von Aufgaben über Website-Grenzen, Eigentümer, Mitglieder, externe Freigaben, Vertraulichkeit, Aufbewahrung und Benennung. Teilen Sie eine übergroße geteilte Ablage auf, wenn unterschiedliche Abteilungen, Vertraulichkeitsstufen oder Lebenszyklen ein gemeinsames Ziel ungeeignet machen.

Der Microsoft Migration Manager für Google Workspace folgt einer sinnvollen Reihenfolge: verbinden, scannen und bewerten, bereite Quellen zur Migrationsliste hinzufügen, Zielpfade prüfen, Identitäten zuordnen und anschließend migrieren und überwachen. Nutzen Sie den vollständigen Ablauf, wenn die Komplexität dies erfordert. Für geeignete KMU-Mandanten kann eine schlankere Oberfläche verfügbar sein. Eine vereinfachte Bedienung beseitigt jedoch nicht die Notwendigkeit zu wissen, wo Inhalte hingehören.

Scannen Sie zuerst und lesen Sie die Berichte. Suchen Sie nach nicht unterstützten Dateien, eingeschränkten Elementen, überlangen Pfaden, ungültigen Namen, Eigentumsproblemen, großen Elementen und Datenmengen, die den Zeitplan gefährden. Prüfen Sie die Zielzuordnung, statt jede automatische Übereinstimmung zu akzeptieren. Ordnen Sie Benutzer und Gruppen zu, bevor Sie erwarten, dass Berechtigungen und Metadaten korrekt folgen. Führen Sie einen repräsentativen Pilotversuch mit nativen Google-Dateien, extern freigegebenen Ordnern, vererbten Berechtigungen, großen Strukturen und Inhalten ausgeschiedener Beschäftigter durch.

Bei der Konvertierung ändert sich die Datei und nicht nur ihr Speicherort. Die aktuelle Microsoft-Dokumentation zu nicht unterstützten Dateien erklärt, dass Google Docs, Tabellen und Präsentationen über die Google Export API in DOCX, XLSX und PPTX konvertiert werden, während die Originale in Google verbleiben. Google Zeichnungen werden in PNG umgewandelt. Google Sites und Google Maps werden nicht migriert. Verknüpfungen werden übersprungen; nicht organisierte oder verwaiste Dateien werden weder gescannt noch gemeldet. Das aktuelle Verhalten bei Formularen und weiteren Elementtypen kann sich ändern. Prüfen Sie daher die Dokumentation, wenn das Migrationsprojekt angelegt wird.

Eine Konvertierung kann Formeln, Skripte, Seitenlayout, Kommentare, eingebettete Objekte und Links verändern. Stellen Sie ein Testpaket aus komplexen Dokumenten zusammen und lassen Sie das Ergebnis von den tatsächlichen Eigentümern genehmigen. Auch Berechtigungen müssen stichprobenartig geprüft werden: Interne Benutzer, Gruppen, Gäste, anonyme Links und benutzerdefinierte Zugriffe werden nicht in jedem Fall identisch übertragen. Führen Sie ein Nacharbeitsprotokoll für Dateien, die manuell exportiert, neu gestaltet, archiviert oder entsorgt werden müssen. Migration Manager kopiert Inhalte, entfernt aber keine Originale aus Google. Die Stilllegung der Quelle bleibt deshalb eine separate, kontrollierte Maßnahme.

Pilot, Umstellung, DNS und Rückfallplan

Ein glaubwürdiger Pilotversuch bildet die schwierigen Bereiche des Unternehmens ab und nicht nur kooperative IT-Benutzer. Nehmen Sie mehrere Abteilungen, Führungskräfte oder Assistenzen mit Stellvertretungsrechten, Beschäftigte im Homeoffice, mobile Benutzer, Eigentümer geteilter Ablagen, externe Mitwirkende, Personen mit Raumbuchungen und mindestens ein Konto mit einem großen oder ungewöhnlichen Postfach auf. Definieren Sie Erfolgsschwellen für E-Mail-Fluss, Anmeldung, Outlook-Profile, mobilen Zugriff, Besprechungen, Berechtigungen, Dokumentkonvertierung und Supportanfragen.

Führen Sie den Pilotversuch unter produktionsnahen Bedingungen durch. Verwenden Sie die vorgesehenen Abonnements, Richtlinien, das geplante DNS-Design und die geplante Endpunktkonfiguration. Erfassen Sie Zahlen an Quelle und Ziel, bekannte Ausschlüsse, die Abnahme durch Benutzer und den Zeitbedarf für Korrekturen. Wenn der Pilot zeigt, dass fünf Prozent der Dateien manuell bearbeitet werden müssen, nehmen Sie diesen Aufwand in den Zeitplan auf. Erklären Sie den Pilot nicht allein deshalb zum Erfolg, weil 95 Prozent kopiert wurden.

Verringern Sie vor der Umstellung die Gültigkeitsdauer der DNS-Einträge, sofern Anbieter und Änderungsrichtlinie dies gestatten. Tun Sie es aber früh genug, damit der bisherige Wert auslaufen kann. Bestätigen Sie den Zugang zum DNS-Host, dokumentieren Sie jeden aktuellen Eintrag und bereiten Sie die exakten Zielwerte aus dem Microsoft 365 Admin Center vor. Prüfen Sie MX, Autodiscover, SPF, DKIM und DMARC. SPF muss ein einziger gültiger Eintrag bleiben, der alle berechtigten Absender einschließt. Das unbedachte Hinzufügen eines zweiten SPF-TXT-Eintrags kann die Auswertung beschädigen. Testen Sie Absender aus Fachanwendungen und Gateways von Drittanbietern separat.

Legen Sie die Reihenfolge des Ereignisses fest: Vermeidbare Änderungen an Konten und Strukturen einfrieren, unterstützte Abschluss- oder Deltaläufe beenden, Batchstatus prüfen, Einträge für den E-Mail-Fluss ändern, eingehende und ausgehende Zustellung bestätigen, Sicherheitsdatensätze der Domäne aktivieren oder validieren und danach Benutzer gemäß Wellenplan freigeben. Die Microsoft-Übersicht ordnet die Verbindung der Domäne nach der E-Mail- und Kalendermigration ein, weil die Änderung von MX eine Dienstumstellung und kein bloßes Vorbereitungskästchen ist.

Der Rückfallplan muss vor der Startentscheidung schriftlich vorliegen. Legen Sie fest, wer die Welle stoppen darf, wann der letzte sichere Entscheidungspunkt erreicht ist, wie MX oder Routing wiederhergestellt werden, wie neu an Microsoft 365 zugestellte E-Mails behandelt werden und ob Benutzer Dateien in beiden Systemen bearbeiten dürfen. Eine DNS-Rückkehr wirkt wegen vorhandener Caches nicht sofort. Das Zurückdrehen des E-Mail-Flusses führt außerdem Daten, die auf beiden Seiten neu entstanden sind, nicht automatisch zusammen. Bei vielen Fehlern ist es sicherer, die nächste Welle anzuhalten und Probleme zu beheben, statt Benutzer zurückzusetzen, die bereits erfolgreich arbeiten.

Besetzen Sie einen zentralen Kommunikationskanal mit benannten technischen und fachlichen Verantwortlichen, und protokollieren Sie Änderungen samt Zeitpunkten. Halten Sie Service-Desk-Skript, Benutzerankündigungen und Eskalationsdaten bereit. Planen Sie die erste große Welle nicht vor Gehaltsabrechnung, Quartalsabschluss, Produkteinführung oder Feiertag, sofern das Unternehmen dieses Risiko nicht ausdrücklich akzeptiert.

Checkliste zur Validierung und häufige Fehler

Der Status Abgeschlossen ist noch keine geschäftliche Abnahme. Die Microsoft-Dokumentation für Dateien weist darauf hin, dass Aufgaben als bereit oder abgeschlossen erscheinen können, obwohl nicht unterstützte Elemente auf Elementebene fehlgeschlagen sind. Validieren Sie nach Arbeitslast, Benutzer und Ausnahmekategorie.

• Identität: Benutzer können sich anmelden, MFA funktioniert, Lizenzen sind zugewiesen, Aliase werden aufgelöst, Gruppen haben die richtigen Eigentümer und deaktivierte Konten bleiben deaktiviert.
• E-Mail: Eingehende, ausgehende und interne Zustellung funktionieren; Ergebnisse bei historischen Ordnern oder Labels sind verstanden; Stellvertretungen, Aliase, Regeln und Ausnahmen für große Nachrichten wurden geprüft.
• Kalender: Serientermine, Zeitzonen, Organisatorverhalten, Räume, freigegebene Kalender und mobile Synchronisierung wurden getestet.
• Dateien: Zahlen und Größen sind unter Berücksichtigung bekannter Konvertierungsunterschiede abgeglichen; Eigentümer, Berechtigungen, externer Zugriff und Beispieldokumente wurden genehmigt.
• Clients: Outlook, Teams, OneDrive und die Office-Aktivierung funktionieren auf repräsentativen Windows-, macOS- und Mobilgeräten.
• Sicherheit: Überwachungsereignisse treffen ein, Conditional Access verhält sich wie vorgesehen, Freigabekontrollen greifen, die Aufbewahrung wurde getestet und der Notfallzugriff bleibt verfügbar.
• Betrieb: Prozesse für Eintritt, Wechsel und Austritt von Beschäftigten, Wiederherstellung, Support und Eskalation funktionieren auf der neuen Plattform.

Häufige Fehler sind meist vorhersehbar: Nicht zugeordnete Identitäten verursachen den Verlust von Berechtigungen; nicht bereitgestellte OneDrives oder Websites blockieren Ziele; veraltete Aliase erzeugen E-Mail-Konflikte; OAuth- oder API-Berechtigungen laufen ab; Pfade oder Dateien werden nicht unterstützt; externe Gäste lassen sich nicht zuordnen; und Aufbewahrungsrichtlinien verschieben während der Prüfung Elemente. Ein weiterer verbreiteter Fehler besteht darin, rohe Dateizahlen zu vergleichen, ohne die Konvertierung nativer Google-Dateien oder übersprungene Verknüpfungen einzurechnen. Ordnen Sie jede Abweichung einer Kategorie zu: erwartet, behoben, von einer verantwortlichen Person akzeptiert oder weiterhin blockierend.

Sichern Sie Nachweise. Exportieren Sie Migrationsberichte, Fehlerlisten, Zuordnungsdateien, DNS-Einträge, Abnahmebestätigungen und Entscheidungen über Nacharbeiten. Prüfen Sie Benutzer mit hohem Risiko gezielt, statt nur Durchschnittswerte anzusehen. Halten Sie den Zugriff auf die Quelle während des genehmigten Validierungszeitraums schreibgeschützt oder anderweitig kontrolliert aufrecht, vorbehaltlich rechtlicher und sicherheitsbezogener Anforderungen. Entfernen Sie danach Migrationsanwendungen, Dienstkonten, vorübergehende Berechtigungen, Weiterleitungsregeln und veraltete Routingdomänen, sobald diese nicht mehr benötigt werden.

Benutzerakzeptanz und Veränderungsmanagement

Benutzer brauchen keine Tour durch jede Microsoft-365-Funktion, sondern müssen die Änderungen ihrer täglichen Arbeit verstehen. Stellen Sie kurze, rollenbezogene Anleitungen bereit: Outlook-Ordner und -Kategorien gegenüber Gmail-Labels, OneDrive-Freigaben gegenüber Drive, Teams-Kanäle gegenüber spontanen Chats, Eigentum an SharePoint-Team-Inhalten, Besprechungen, Raumbuchung, Offline-Dateien und Zugriffsanfragen. Zeigen Sie vor allem fehlerträchtige Unterschiede.

Gewinnen Sie Multiplikatoren aus dem Pilotbereich, geben Sie Führungskräften eine Checkliste für die Umstellung und veröffentlichen Sie einen klaren Supportweg. Versenden Sie Zugangsdaten und Einrichtungsanweisungen über einen Kanal, der auch bei einer Störung der E-Mail verfügbar bleibt. Bieten Sie während der ersten Wellen Sprechstunden an und ordnen Sie Fragen nach Themen. Wiederkehrende Unklarheiten sind Rückmeldungen zur Gestaltung: Sie können auf schlechte Benennungen, fehlende Berechtigungen, eine zu komplizierte Websitestruktur oder eine nicht dokumentierte Richtlinie hinweisen.

Messen Sie die Akzeptanz nach dem Start. Prüfen Sie Anmeldungen, aktive Nutzung, Supportvolumen, ungelöste Freigabeanfragen, Speicherwachstum und doppelte Arbeit in Google. Kündigen Sie die Quelle nicht allein deshalb, weil der Migrationstermin verstrichen ist. Legen Sie sie erst still, wenn Datenvalidierung, Aufbewahrung, geschäftliche Abnahme und vertragliche Kündigungsfristen erfüllt sind.

Kosten, Risiken und realistische Zeitplanung kontrollieren

Kein verantwortungsvoller Leitfaden kann eine feste Dauer oder einen festen Preis versprechen. Ein Unternehmen mit fünfzig Benutzern, standardmäßigem Gmail und aufgeräumten Ablagen kann einfacher sein als ein Studio mit zwanzig Benutzern, mehreren Terabyte Mediendaten, umfangreichen externen Freigaben und Automatisierungen in Apps Script. Den Zeitplan beeinflussen Datenvolumen, Elementzahl, API-Drosselung, Postfachgröße, nicht unterstützte Inhalte, Qualität der Identitäten, Anzahl der Domänen, Koexistenz, rechtliche Sperren, Bereitschaft der Endgeräte, Geschäftskalender und die Geschwindigkeit von Entscheidungen der Verantwortlichen.

Kontrollieren Sie Kosten mit Wellen und Entscheidungspunkten. Lizenzieren Sie Pilotbenutzer zuerst, wenn dies kaufmännisch sinnvoll ist. Kaufen Sie keine Migrationssoftware, bevor Sie geklärt haben, ob ein natives Werkzeug die Anforderungen erfüllt, und planen Sie doppelte Abonnementkosten ein. Priorisieren Sie Nacharbeiten nach geschäftlicher Auswirkung, statt harmlose Abweichungen bei Zählwerten zu verfolgen. Führen Sie ein Risikoregister mit Wahrscheinlichkeit, Auswirkung, verantwortlicher Person, Gegenmaßnahme und Auslöser. Halten Sie eine Reserve für komplexe Dokumente, geteilte Berechtigungen und Anwendungsintegrationen vor.

Ein sinnvoller Zeitplan wird in Phasen und nicht in Versprechen ausgedrückt: Bestandsaufnahme; Architektur und Beschaffung; Vorbereitung von Mandant und Identitäten; Pilot; Nacharbeiten; gestaffeltes Vorkopieren; Umstellungswellen; Validierung; und Stilllegung der Quelle. Jede Phase endet aufgrund von Nachweisen. Wenn die Bestandsaufnahme den Umfang vergrößert, aktualisieren Sie den Zeitplan offen. Weniger Tests beseitigen kein Risiko, sondern übertragen dieses Risiko lediglich auf Beschäftigte und Service Desk.

Den zur Migration passenden Microsoft-365-Plan auswählen

Der Marktplatz von Licendi umfasst Microsoft-365-Pläne und weitere Optionen für Softwarelizenzen. Wählen Sie Abonnements anhand der Benutzer, Anwendungen, Sicherheitskontrollen und Compliance-Anforderungen des Zielentwurfs. Gehen Sie nicht davon aus, dass jedes Abonnement eine übertragbare, unbefristete gebrauchte Lizenz ist. Microsoft-365-Dienste sind im Allgemeinen laufende Abonnements, während andere über den Marktplatz angebotene Software unterschiedlichen Lizenzmodellen und Übertragungsbedingungen unterliegen kann.

Fazit

Eine erfolgreiche Migration von Google Workspace bemisst sich nicht daran, wie schnell Daten Google verlassen. Entscheidend ist, ob Menschen nach der Stilllegung der Quelle in Microsoft 365 kommunizieren, Informationen finden, erforderliche Unterlagen aufbewahren und sicher arbeiten können. Eine gründliche Bestandsaufnahme und die Zuordnung der Identitäten verhindern die meisten vermeidbaren Überraschungen. Pilotversuche decken die übrigen Probleme auf, solange eine Rückkehr noch praktikabel ist.

Verwenden Sie die aktuellen Microsoft-Werkzeuge für die Arbeitslasten, die sie tatsächlich unterstützen, dokumentieren Sie jede bekannte Einschränkung und lassen Sie konvertierte Dokumente und Berechtigungen von den fachlich Verantwortlichen abnehmen. Mit gestaffelten Übertragungen, kontrollierten DNS-Änderungen, messbarer Validierung und gezielter Schulung kann der Wechsel planbar werden, ohne so zu tun, als werde er vollkommen oder unsichtbar ablaufen.

Häufig gestellte Fragen

Kann Microsoft Gmail, Kalender und Kontakte migrieren?

Ja. Die verfügbaren Microsoft-Verfahren für die Migration von Google Workspace können Gmail-Daten sowie unterstützte Kalender- und Kontaktinhalte nach Exchange Online übertragen. Welche Daten genau auswählbar sind und welche Einrichtung erforderlich ist, hängt von der im Mandanten verfügbaren Methode ab. Freigegebene Kalender, Raumbuchungen, Ereignisfarben, Gmail-Labels und einige Kontaktfelder unterliegen im klassischen automatisierten Batch-Verfahren Einschränkungen. Testen und kommunizieren Sie daher den aktuellen Umfang der gewählten Methode.

Wird Google Drive direkt zu OneDrive migriert?

Persönliche Inhalte aus Meine Ablage werden üblicherweise OneDrive zugeordnet, während geteilte Ablagen normalerweise in gesteuerte SharePoint-Websites oder mit Teams verbundene Websites gehören. Migration Manager kopiert unterstützte Inhalte, Metadaten und Berechtigungen entsprechend der Konfiguration. Zielarchitektur, Zuordnung der Identitäten und Nacharbeit für nicht unterstützte Elemente erfordern weiterhin Entscheidungen der Administration.

Werden Google Docs in Microsoft-Office-Dateien konvertiert?

Ja. Migration Manager verwendet die Google Export API, um Google Docs, Tabellen und Präsentationen in DOCX, XLSX und PPTX zu konvertieren. Dabei können sich Formeln, Skripte, Layout, Kommentare, eingebettete Inhalte oder Links verändern. Eigentümer sollten daher komplexe Dateien validieren. Die ursprünglichen Google-Dateien bleiben in der Quelle, sofern das Unternehmen sie nicht später entfernt.

Funktionieren alle Berechtigungen und Freigabelinks weiterhin?

Eine Garantie ist nicht möglich. Durch die Zuordnung von Identitäten können unterstützte Berechtigungen erhalten bleiben, doch benutzerdefinierte Zugriffe, externe Benutzer, anonyme Links, Verknüpfungen, Eigentumsverhältnisse und Zielrichtlinien können das Ergebnis verändern. Testen Sie repräsentative Freigabemuster, veröffentlichen Sie bei Bedarf neue Links und führen Sie für Ausnahmen ein Nacharbeitsregister.

Wie viel Ausfallzeit ist für eine Migration erforderlich?

Es gibt keinen allgemeingültigen Wert. Vorabübertragungen und eine gestaffelte Koexistenz können Störungen verringern. Abschließende Synchronisierung, DNS-Verteilung, Neukonfiguration der Clients und Supportprobleme bringen dennoch Risiken mit sich. Planen Sie ein kontrolliertes Wartungsfenster und versprechen Sie keine Migration ohne Ausfallzeit.

Können Google Workspace und Microsoft 365 während der Migration parallel betrieben werden?

Ja. Unterstützte gestaffelte E-Mail-Verfahren können Routingdomänen und bereitgestellte Empfänger verwenden, damit bereits migrierte und noch nicht migrierte Benutzer E-Mails austauschen. Die Koexistenz erhöht allerdings die Komplexität: Verantwortung für Identitäten, Weiterleitungen, Gruppenänderungen, Kalenderverhalten und Supportgrenzen müssen dokumentiert und getestet werden.

Wann kann das Google-Workspace-Abonnement gekündigt werden?

Kündigen Sie erst nach der Validierung von E-Mails und Dateien, der rechtlichen und aufbewahrungsbezogenen Prüfung, der Abnahme durch die fachlich Verantwortlichen, dem Ende der Rückfallfrist sowie dem Entfernen oder Exportieren aller nicht migrierbaren Inhalte. Prüfen Sie zuvor die Vereinbarungen für Domäne und DNS-Hosting. Die Migrationswerkzeuge kopieren unterstützte Daten; sie treffen keine Entscheidung über die Stilllegung der Quelle.

Welcher Microsoft-365-Plan ist nach Google Workspace am besten geeignet?

Der beste Plan hängt vom jeweiligen Benutzerprofil ab. Business Basic kann zu Personen passen, die hauptsächlich in der Cloud arbeiten. Business Standard ergänzt Desktopanwendungen für produktives Arbeiten, und Business Premium bietet weitere Funktionen für Identität, Geräteverwaltung und Sicherheit. Prüfen Sie aktuelle Nutzungsrechte, Compliance-Anforderungen, Benutzergrenzen und Migrationsvoraussetzungen, statt standardmäßig einen einzigen Plan für alle auszuwählen.