Google Workspace zu Microsoft 365 migrieren

Microsoft 365 · Plattformmigration

Beim Wechsel von Google Workspace zu Microsoft 365 werden nicht bloß Postfächer und Dateien kopiert. Gmail-Labels, Google-Gruppen, persönliche und geteilte Ablagen, Kalenderfreigaben, Identitäten und Arbeitsweisen müssen in passende Microsoft-365-Strukturen übersetzt werden. Eine belastbare Migration beginnt deshalb mit dem Zielbetrieb und endet erst, wenn die wichtigsten Geschäftsvorgänge mit den vorgesehenen Benutzerkonten geprüft sind.

Die Kurzantwort: Jede Google-Funktion braucht ein ausdrücklich gewähltes Ziel

Gmail wird nicht automatisch zu einer vollständigen Exchange-Struktur, und eine Google-Ablage wird nicht allein durch das Kopieren nach SharePoint sinnvoll organisiert. Vor der Übertragung wird für jede Quelle entschieden, welches Ziel ihre betriebliche Aufgabe übernimmt, welche Eigenschaften migrierbar sind und welche Funktionen neu eingerichtet werden müssen.

Typische Zuordnung von Google Workspace zu Microsoft 365
Ausgangslage	Mögliches Ziel	Vorher zu klären
Persönliches Gmail-Postfach	Exchange-Online-Postfach	Labels, Regeln, Delegationen, Kalender, Kontakte und nicht migrierbare Elemente
Funktionsadresse oder Google-Gruppe	Freigegebenes Postfach, Verteiler, Microsoft-365-Gruppe oder Alias	Gemeinsamer Inhalt, Sendeverhalten, Mitgliedschaft, Moderation und Archivbedarf
Persönlicher Bereich in „Meine Ablage“	OneDrive der jeweiligen Person	Eigentümer, externe Freigaben, verwaiste Dateien und betriebliche Relevanz
Geteilte Ablage	SharePoint-Website oder Dokumentbibliothek, gegebenenfalls mit Teams	Zuständigkeit, Zielstruktur, Gruppen, Berechtigungen und spätere Pflege
Google Docs, Sheets und Slides	Word-, Excel- und PowerPoint-Dateien	Konvertierung, Formeln, Verknüpfungen, Layout und Funktionsprüfung
Google Meet, Chat oder Spaces	Teams und neue Kommunikationsstrukturen	Welche Inhalte benötigt werden und welche Funktionen neu aufgebaut werden

Die native Microsoft-Migration kann E-Mail, Kalender, Kontakte und weitere Postfachobjekte übertragen. Für Google Drive steht der Migration Manager zur Verfügung. Beide Werkzeuge lösen jedoch unterschiedliche Teile des Vorhabens. Google-Gruppen, gemeinsam genutzte Kalender, Raumbelegungen oder die Semantik einer gewachsenen Ordner- und Freigabestruktur benötigen zusätzliche Entscheidungen.

Vier Nachweise entscheiden über die Freigabe der Migration

Jede Person, Funktionsadresse, Gruppe, Ressource und technische Anmeldung besitzt ein dokumentiertes Ziel.
Persönliche und gemeinsame Dateien sind nach Eigentum, Nutzung und Zielablage zugeordnet.
Ein Pilot umfasst reale E-Mails, Kalender, Kontakte, Google-Dateien, Berechtigungen und mindestens einen vollständigen Arbeitsvorgang.
Umschaltung, Nachsynchronisierung, Nutzerinformation, Rückfallentscheidung und Abschaltung der Google-Dienste sind terminiert und verantwortlich zugewiesen.

1. Das Zielbild beschreibt Arbeitsabläufe und nicht nur Microsoft-Produkte

Der Wechsel ist erst planbar, wenn feststeht, wie E-Mail, Dateien, Besprechungen, Freigaben und Administration künftig funktionieren sollen. Eine Liste der gebuchten Lizenzen ersetzt dieses Zielbild nicht.

Geschäftsvorgänge machen unsichtbare Abhängigkeiten sichtbar

„Wir verwenden Gmail und Drive“ sagt wenig über den Betrieb. Aussagekräftiger ist etwa: Eingehende Rechnungen erreichen buchhaltung@, zwei Beschäftigte bearbeiten sie, eine Fachanwendung verschickt Rückfragen unter derselben Domain und die Belege liegen in einer gemeinsamen Ablage. Daraus folgen Anforderungen an Postfachtyp, Sendebericht, Berechtigungen, Dateistruktur und automatisierten Versand.

Für den Pilot werden mehrere solcher Vorgänge beschrieben. Dazu gehören Normalfälle und kritische Ausnahmen: Vertretung bei Abwesenheit, Zugriff externer Steuerberater, Terminbuchung mit einem Raum, mobiles Arbeiten und das Ausscheiden einer Person. Erst diese Beispiele zeigen, ob das Zielsystem die tatsächliche Arbeit trägt.

Google Workspace bleibt bis zur geprüften Ablösung ein produktives System

Quellkonten, Administrationszugänge und Abonnements werden nicht während der ersten erfolgreichen Kopie gekündigt. Die Google-Umgebung enthält weiterhin Daten, Freigaben und möglicherweise Dienste, die vom Migrationswerkzeug nicht erfasst werden. Auch eine Nachsynchronisierung braucht lesbaren Zugriff auf die Quelle.

Vor Projektbeginn werden Vertragsinhaber, Abrechnungszugang, primäre Administratoren, Domainregistrar und DNS-Verwaltung dokumentiert. Falls Google zugleich Domainregistrar oder DNS-Anbieter ist, wird die Domain unabhängig vom Workspace-Abonnement betrachtet. Eine Kündigung des Produktpakets darf weder Domain noch DNS-Verwaltung unbeabsichtigt beeinträchtigen.

Umfang und Ausschlüsse werden objektbezogen festgelegt

Der Umfang nennt nicht pauschal „alle Daten“, sondern Benutzerpostfächer, Kalenderarten, Kontaktbestände, Gruppen, persönliche Ablagen, geteilte Ablagen, Dateitypen und gegebenenfalls Archivsysteme. Für jeden Bereich stehen Quelle, Ziel, Zeitraum, Ausschluss, Migrationsverfahren und Prüfmethode fest.

Bewusste Ausschlüsse werden mit einem nachvollziehbaren Grund dokumentiert. Veraltete Dateien können zurückbleiben, wenn eine verantwortliche Person dies nach festgelegten Kriterien entscheidet. Ein Werkzeugfehler oder ein nicht unterstützter Dateityp ist dagegen kein stillschweigender Ausschluss, sondern ein Befund, der bearbeitet werden muss.

2. Identitäten werden vor Daten und Berechtigungen geordnet

E-Mail-Adressen können gleich bleiben, obwohl dahinter neue Microsoft-Entra-Konten mit eigenen Kennwörtern, Mehrfaktoranmeldung, Lizenzen und Rollen entstehen. Diese Identitäten müssen angelegt und zugeordnet sein, bevor Zugriffsrechte zuverlässig migriert werden können.

Personen, Funktionsadressen und technische Konten bleiben getrennte Objektarten

Jede beschäftigte Person erhält grundsätzlich ein persönliches Arbeitskonto. Adressen wie info@ oder verwaltung@ werden nach ihrer Aufgabe als freigegebenes Postfach, Verteiler, Microsoft-365-Gruppe oder Alias aufgebaut. Ein solcher Empfänger wird nicht allein deshalb als Benutzerkonto angelegt, weil er in Google mit eigenen Zugangsdaten geführt wurde.

Technische Anmeldungen für Scanner, Websites, Automationen oder Fachanwendungen werden gesondert untersucht. Entscheidend sind Protokoll, Authentifizierungsverfahren, Absenderadresse, benötigte Rechte und verantwortliche Person. Das Kennwort eines normalen Mitarbeiters als dauerhafte Anwendungsanmeldung zu übernehmen, schafft eine unnötige Abhängigkeit und erschwert spätere Personalwechsel.

Google-Gruppen werden nach ihrer Funktion neu entworfen

Eine Google-Gruppe kann Verteiler, Diskussionsarchiv, Berechtigungsgruppe, gemeinsamer Posteingang oder Zugang zu einer geteilten Ablage sein. Diese Aufgaben entsprechen nicht einem einzigen Microsoft-Objekt. Eine Verteilerliste verteilt Nachrichten; ein freigegebenes Postfach hält gemeinsamen Inhalt und Bearbeitungsstand; eine Microsoft-365-Gruppe verbindet Mitgliedschaft mit Diensten wie SharePoint und Teams; eine Sicherheitsgruppe kann Zugriffe steuern.

Für jede Gruppe werden Mitglieder, Eigentümer, externe Absender, Moderation, Sendeadresse, Archivbedarf und verwendete Dateiablagen erfasst. Erst danach wird das Zielobjekt gewählt. Microsofts standardmäßige Postfachmigration überträgt Google-Gruppen nicht als fertige Microsoft-Struktur.

Administrationsrollen und Wiederherstellungswege werden neu aufgebaut

Google-Administratorrollen gehen nicht automatisch in passende Microsoft-Rollen über. Für Microsoft 365 werden persönliche Administratorkonten, die erforderlichen Rollen und gesicherte Wiederherstellungswege eingerichtet. Alltägliche Büroarbeit erfolgt nicht mit dem privilegierten Konto.

Vor dem Umschalttag testen alle Benutzer ihre Microsoft-Anmeldung einschließlich Mehrfaktorauthentifizierung. Dabei werden auch Ersatzverfahren für ein verlorenes Telefon und die Erreichbarkeit verantwortlicher Administratoren geprüft. Eine funktionierende Datenmigration hilft wenig, wenn Beschäftigte am ersten Arbeitstag keinen Zugriff erhalten.

Identitätsmatrix vor der ersten Übertragung

Primäre Google-Adresse, Aliasse und künftiger Microsoft-Benutzername
Benutzertyp, Beschäftigungsstatus, Lizenz und benötigte Dienste
Persönliche sowie privilegierte Konten und deren Verantwortliche
Mitgliedschaften, Gruppenbesitzer und externe Personen
Eigentum an persönlichen und geteilten Dateien
Kalenderdelegationen, Raumressourcen und Stellvertretungen
Anwendungen, Geräte und Automationen, die dieselbe Identität verwenden
Geplanter Umgang mit ausgeschiedenen, gesperrten oder inaktiven Konten

3. E-Mail, Kalender und Kontakte besitzen bekannte Übernahmegrenzen

Microsoft stellt eigene Verfahren für Google-Workspace-Postfächer bereit. Sie können E-Mails, Regeln, Kalender und Kontakte migrieren und je nach Verfahren weitere Objekte berücksichtigen. Der genaue Umfang wird dennoch vor dem Pilot anhand der aktuellen Werkzeugdokumentation und des tatsächlichen Quellbestands festgelegt.

Das Google-Verfahren ist einer reinen IMAP-Kopie vorzuziehen, wenn mehr als E-Mail benötigt wird

Eine IMAP-Migration erfasst nur Nachrichten in Mailordnern. Das Google-spezifische Microsoft-Verfahren kann zusätzlich Kalender, Kontakte und Regeln einbeziehen. Bei kleinen und mittleren Umgebungen führt Microsoft über die konsolidierte Migrationsoberfläche und die Google-Marketplace-App durch die Einrichtung. Welche Variante im jeweiligen Mandanten verfügbar und geeignet ist, wird zu Projektbeginn geprüft.

Für die Migration benötigt das Werkzeug zeitlich begrenzten administrativen Zugriff auf die Google-Quelle. Die eingerichtete Anwendung, deren Berechtigungen und das verwendete Migrationskonto werden dokumentiert. Nach abgeschlossener Abnahme werden nicht mehr benötigte Zugriffe wieder entzogen.

Kalender und Kontakte werden nicht mit pauschaler Vollständigkeit zugesagt

Microsoft nennt unter anderem gemeinsam genutzte Kalender, Ereignisfarben und bestehende Raumbelegungen als nicht automatisch migrierte Elemente des klassischen Verfahrens. Bei Kontakten werden höchstens drei E-Mail-Adressen pro Kontakt übertragen; benutzerdefinierte Kennzeichnungen und Kontakt-URLs können entfallen. Automatische Antworten müssen ebenfalls neu eingerichtet werden.

Deshalb enthält der Pilot nicht nur eine Zählung. Geprüft werden wiederkehrende Termine, Besprechungen mit externen Teilnehmern, Zeitzonen, Stellvertretungen, Räume, persönliche und gemeinsame Kalender sowie repräsentative Kontakte mit mehreren Feldern. Nicht migrierbare Funktionen erhalten einen eigenen Übernahme- oder Neuanlageplan.

Regeln und Gmail-Labels werden im Ziel auf ihr Verhalten geprüft

Gmail kann einer Nachricht mehrere Labels zuweisen; Outlook arbeitet mit einer stärker ordnerbezogenen Darstellung. Die Auswahl zu migrierender Labels und Ordner wird deshalb vorab anhand typischer Postfächer geprüft. Eine formal vollständige Übertragung kann sonst im Ziel eine unübersichtliche oder unerwartet große Struktur erzeugen.

Migrierte Regeln bleiben nach Microsofts Dokumentation zunächst deaktiviert. Jede Regel wird in Outlook auf Bedingung, Zielordner, Weiterleitung und mögliche Wechselwirkung geprüft, bevor sie aktiviert wird. Signaturen, Abwesenheitsmeldungen und clientabhängige Einstellungen werden gesondert eingerichtet.

Koexistenz und Mailrouting benötigen zwei klar getrennte Phasen

Bei einer gestaffelten Migration müssen bereits umgestellte und noch bei Google arbeitende Benutzer weiterhin Nachrichten austauschen können. Microsoft beschreibt dafür Routing-Subdomains in beiden Richtungen. Adressen, Weiterleitungen und Zielzustände werden so dokumentiert, dass keine Schleife und kein unzustellbarer Empfänger entsteht.

Der Wechsel des MX-Eintrags steuert neue eingehende E-Mails zu Microsoft 365; er migriert keine vorhandenen Nachrichten. Vor der DNS-Änderung existieren alle produktiven Empfänger im Ziel, und legitime Absender wie Website oder Fachanwendung sind in SPF-, DKIM- und DMARC-Planung einbezogen. Nach der Umschaltung wird der Nachrichtenfluss intern, extern und über sämtliche Funktionsadressen geprüft.

4. Google Drive wird nach Eigentum und Zusammenarbeit auf OneDrive und SharePoint verteilt

Persönliche Ablagen und gemeinsam verantwortete Unternehmensdaten folgen unterschiedlichen Regeln. Eine unveränderte Übernahme jeder bisherigen Struktur würde bekannte Eigentums- und Berechtigungsprobleme lediglich in Microsoft 365 fortsetzen.

„Meine Ablage“ wird nicht automatisch zum richtigen OneDrive-Inhalt

OneDrive ist der persönliche Arbeitsbereich einer Person. In Google „Meine Ablage“ können jedoch auch dauerhaft gemeinsam verantwortete Unterlagen liegen. Solche Daten werden vor der Migration einem Team oder einer Unternehmensfunktion zugeordnet und in eine passende SharePoint-Bibliothek verschoben beziehungsweise dorthin migriert.

Besondere Aufmerksamkeit benötigen Dateien ausgeschiedener Nutzer, Inhalte ohne erreichbaren Eigentümer und Dokumente, die anderen Personen nur als Verknüpfung erscheinen. Microsoft weist darauf hin, dass nicht organisierte oder verwaiste Google-Dateien vom Migration Manager nicht gescannt und damit auch nicht in seinen Berichten ausgewiesen werden. Der Quellbestand muss solche Objekte deshalb vorab bereinigen.

Geteilte Ablagen benötigen eine benannte Microsoft-Zielstruktur

Eine geteilte Google-Ablage kann in eine SharePoint-Website, eine Dokumentbibliothek oder eine mit Teams verbundene Website überführt werden. Die Entscheidung folgt Verantwortlichkeit und Zusammenarbeit. Eine Ablage für Personalunterlagen gehört beispielsweise nicht in ein allgemein zugängliches Team, selbst wenn die bisherige Google-Struktur historisch so gewachsen ist.

Vor der Migration werden Zielwebsite, Bibliothek, Eigentümergruppe, Mitglieder und externe Zugriffe angelegt. Der Migration Manager kann Identitäten und Gruppen zuordnen, damit Metadaten und Berechtigungen übertragen werden. Gruppen müssen dafür im Ziel vorhanden und korrekt gemappt sein.

Google-Dateien werden konvertiert und anschließend anhand ihres vorgesehenen Zwecks geprüft

Google Docs, Sheets und Slides werden über die Google Export API in DOCX-, XLSX- und PPTX-Dateien umgewandelt. Die Quelldateien bleiben dabei unverändert. Google Drawings werden standardmäßig als PNG übertragen. Google Sites und Google Maps gehören zu den vom Migration Manager nicht migrierten Elementen; Verknüpfungsdateien werden übersprungen.

Eine erfolgreiche Konvertierung beweist nur, dass eine Zieldatei erzeugt wurde. Bei Google Sheets werden Formeln, Verknüpfungen, Datenvalidierung, Diagramme und Automatisierungen an repräsentativen Dateien geprüft. Bei Docs und Slides zählen Layout, Kommentare, eingebettete Inhalte und verwendete Schriftarten. Geschäftskritische Vorlagen erhalten eigene Abnahmetests.

Berechtigungen werden bewusst auf Zielrollen abgebildet

Der Migration Manager ordnet Google-Rollen Microsoft-Rechten zu. Bei einer persönlichen Ablage wird „Editor“ zu „Kann bearbeiten“, während Kommentierende und Lesende als „Kann anzeigen“ übernommen werden. Bei geteilten Ablagen werden mehrere Google-Rollen auf die gröbere Microsoft-Berechtigung „Kann bearbeiten“ abgebildet. Die Abbildung erhält daher nicht jede ursprüngliche Nuance.

Ordnerberechtigungen werden standardmäßig migriert; Dateiberechtigungen müssen in den Projekteinstellungen ausdrücklich aktiviert werden. Nach der Übertragung wird nicht nur erlaubter Zugriff geprüft. Ebenso wichtig ist der negative Test: Eine Person ohne Zuständigkeit darf die betreffende Bibliothek oder Datei nicht öffnen.

Der Scanbericht ist Arbeitsgrundlage und kein Freigabestempel

Vor der Übertragung werden persönliche und geteilte Ablagen gescannt. Die Berichte zeigen unter anderem Datenmenge, Objektzahl, Pfadlänge, Berechtigungen und einzelne Fehler. Microsoft empfiehlt, große Laufwerke in kleinere Aufgaben zu teilen; eine Aufgabe sollte 100.000 Elemente oder ein Terabyte nicht überschreiten. Entscheidend ist jedoch die Detailauswertung: Eine Aufgabe kann als „Ready to migrate“ oder später als „Completed“ erscheinen, obwohl einzelne nicht unterstützte Dateien fehlgeschlagen sind.

Jeder Fehlercode ist einem konkreten Objekt und einer Entscheidung zugeordnet.
Verwaiste Daten wurden bereits in Google ermittelt und einem Eigentümer zugewiesen.
Quell- und Zielpfade sowie Identitätszuordnungen wurden stichprobenartig geprüft.
Konvertierte Google-Dateien bestehen fachliche Funktionsprüfungen.
Externe Freigaben und Einzeldateirechte sind ausdrücklich ein- oder ausgeschlossen.
Eine inkrementelle Nachmigration ist mit Bearbeitungsstopp und Abnahmetermin abgestimmt.

5. Pilot, Vorabübernahme und Umschalttag werden als ein Ablauf geplant

E-Mail und Dateien können vorbereitet und vorab kopiert werden. Die verbindliche Umstellung braucht dennoch einen Zeitpunkt, ab dem neue Arbeit ausschließlich im Zielsystem entsteht.

Der Pilot bildet Unterschiede im Unternehmen ab

Ein geeigneter Pilot umfasst nicht nur den technisch versiertesten Benutzer. Ausgewählt werden unterschiedliche Postfachgrößen, ein Vertreter mit Kalenderdelegation, eine Person mit umfangreicher Drive-Ablage, eine Funktionsadresse, eine externe Freigabe und mindestens eine geschäftskritische Google-Datei. Dadurch werden Sonderfälle sichtbar, bevor alle Benutzer betroffen sind.

Die Ergebnisse werden gegen vorher definierte Sollfälle geprüft. Abweichungen führen zu einer Anpassung von Mapping, Werkzeug oder Zielstruktur. Sie werden nicht mit dem Hinweis akzeptiert, Beschäftigte müssten sich eben an das neue System gewöhnen, wenn tatsächlich Daten oder notwendige Rechte fehlen.

Vorabübertragung und Delta-Synchronisierung reduzieren die Umschaltlast

Größere Datenbestände werden vor dem produktiven Wechsel kopiert. Kurz vor oder nach dem Umschalttag folgt eine inkrementelle Übertragung der seitdem geänderten Inhalte. Dafür muss feststehen, welche Quelle bis zu welchem Zeitpunkt noch bearbeitet werden darf und wie Konflikte vermieden werden.

Eine Delta-Synchronisierung ist kein Ersatz für einen organisatorischen Wechsel. Wenn Beschäftigte nach der Umstellung parallel in Google Drive und SharePoint weiterarbeiten, können zwei gültig erscheinende Fassungen entstehen. Die Nutzerinformation benennt deshalb den verbindlichen neuen Speicherort und den Umgang mit noch sichtbaren Google-Links.

Arbeitsplätze und Mobilgeräte werden vor dem ersten Microsoft-Arbeitstag vorbereitet

Office-Programme, Teams, OneDrive-Synchronisierung und Outlook werden mit dem geschäftlichen Microsoft-Konto eingerichtet. Bestehende Google-Profile bleiben bis zur Abnahme kontrolliert erhalten. Browserprofile, gespeicherte Kennwörter, Smartphone-Apps und Standardprogramme werden so angepasst, dass Benutzer nicht versehentlich im alten System weiterarbeiten.

Die Einweisung konzentriert sich auf tatsächliche Unterschiede: Wo liegen persönliche und gemeinsame Dateien, wie wird ein Dokument extern geteilt, wie antwortet man aus dem gemeinsamen Postfach, wo findet eine Teams-Datei ihren Speicherort und an wen wird ein Berechtigungsproblem gemeldet? Eine allgemeine Produktvorführung beantwortet diese betrieblichen Fragen nicht.

Entscheidungspunkte am Umschalttag

Letzte erfolgreiche Vorabübertragung und offene Fehler bestätigen.
Änderungsfenster und Bearbeitungsstopp für die Google-Quelle ausrufen.
Restdaten migrieren und produktive Empfänger im Microsoft-Ziel prüfen.
MX, Autodiscover und geplante Authentifizierungsdaten ändern.
Interne und externe Mailwege einschließlich Anwendungen testen.
Benutzeranmeldung, Kalender, Dateien, Freigaben und mobile Nutzung prüfen.
Abweichungen gegen festgelegte Rückfallkriterien bewerten.
Nächsten Informations- und Nachsynchronisierungszeitpunkt mitteilen.

6. Die Abnahme verbindet technische Berichte mit realen Arbeitsergebnissen

Objektzahlen und Erfolgsstatus liefern wichtige Hinweise. Die Freigabe erfolgt zusätzlich anhand vereinbarter Datenstichproben, negativer Berechtigungstests und vollständiger Arbeitsvorgänge.

Postfächer werden nach Inhalt und Funktion geprüft

Für ausgewählte Benutzer werden Ordner beziehungsweise Labels, ältere Nachrichten, große Anhänge, Kalenderzeiträume und Kontakte verglichen. Danach folgen Funktionsprüfungen: intern und extern senden, antworten, weiterleiten, Besprechungen erstellen, eine Vertretung verwenden und aus einer Funktionsadresse senden.

Die Prüfung unterscheidet einen tatsächlich fehlenden Inhalt von einer veränderten Darstellung. Beides kann relevant sein, wird aber unterschiedlich behoben. Ein in Outlook anders einsortiertes Element ist kein Datenverlust; ein nicht migrierter gemeinsamer Kalender bleibt dennoch eine offene Aufgabe.

Dateien werden auf Vollständigkeit, Konvertierung und Zugriff getestet

Migrationsergebnisse und Detailberichte werden ausgewertet. Repräsentative Dateien aus persönlichen und gemeinsamen Ablagen werden geöffnet und bearbeitet. Bei konvertierten Google-Dateien werden die vereinbarten Formeln, Verknüpfungen, Layouts und Ausgaben geprüft. Fehlende oder nicht unterstützte Objekte erhalten eine dokumentierte Nacharbeit.

Für Berechtigungen werden mindestens Eigentümer, reguläres Mitglied, nur lesende Person, externe Freigabe und ausdrücklich unberechtigter Benutzer getestet. Nur positive Tests würden ungewollt offene Datenbereiche übersehen.

Google Workspace wird erst nach Ablauf einer geregelten Nachhaltephase beendet

Die Nachhaltephase deckt verspätete E-Mails, nicht migrierte Sonderobjekte, alte Freigabelinks und Rückfragen der Benutzer ab. Google-Zugriffe werden in dieser Zeit kontrolliert eingeschränkt, damit keine unbemerkte Parallelablage entsteht. Administrativer Lesezugriff bleibt für die vereinbarte Prüfung erhalten.

Vor der Kündigung werden Vault- oder andere Archivanforderungen, Aufbewahrungspflichten, Datenexporte, verbliebene Anwendungen und Eigentumsfragen geprüft. Die Dokumentation nennt abgeschaltete Dienste, verbleibende Verträge, entfernte Migrationsberechtigungen und die neuen Verantwortlichen in Microsoft 365.

Abnahmeprotokoll für die Unternehmensleitung

Migrierte und bewusst ausgeschlossene Benutzer, Postfächer, Kalender und Dateiablagen
Fehler, nicht unterstützte Elemente und erledigte beziehungsweise offene Nacharbeiten
Ergebnisse der Datenstichproben und geschäftlichen Prüfvorgänge
Berechtigungstests einschließlich nachgewiesener Zugriffssperren
Neue Zuständigkeiten für Benutzer, Gruppen, Lizenzen und Freigaben
Verbleibende Google-Dienste, Kündigungstermine und Aufbewahrungsentscheidungen
Verwaltungszugänge, Wiederherstellungswege und entfernte Migrationsrechte
Termin und Kriterien für den endgültigen Projektabschluss

Häufige Fragen zur Migration von Google Workspace zu Microsoft 365

Kann die bisherige geschäftliche E-Mail-Adresse bestehen bleiben?

Ja. Die Domain kann in Microsoft 365 verifiziert und mit denselben geschäftlichen Adressen verwendet werden. Der MX-Eintrag bestimmt, wohin neue E-Mails zugestellt werden. Konten, Empfänger und Versandauthentifizierung müssen vor dieser Umschaltung vorbereitet sein.

Werden Gmail, Kalender und Kontakte vollständig übertragen?

Microsofts Google-spezifische Werkzeuge übertragen mehr als eine reine IMAP-Migration, besitzen aber dokumentierte Grenzen. Gemeinsam genutzte Kalender, Raumbelegungen, Ereignisfarben, bestimmte Kontaktfelder, automatische Antworten und weitere Sonderobjekte können zusätzliche Arbeit erfordern. Der konkrete Umfang wird im Pilot geprüft.

Werden Google Docs, Sheets und Slides zu Microsoft-Dateien?

Der Migration Manager konvertiert Google Docs in DOCX, Sheets in XLSX und Slides in PPTX. Die erzeugte Datei muss anschließend auf ihre benötigten Funktionen geprüft werden, weil Formeln, Verknüpfungen, Layout oder eingebettete Inhalte abweichen können.

Kann Google Workspace sofort nach dem MX-Wechsel gekündigt werden?

Nein. Der MX-Wechsel betrifft den Empfang neuer E-Mails. Restmigration, Nachsynchronisierung, nicht unterstützte Objekte, alte Freigaben und Archivanforderungen bleiben zu prüfen. Die Google-Umgebung wird erst nach dokumentierter Abnahme und geregelter Nachhaltephase beendet.

Soll jede geteilte Google-Ablage zu einem Team in Microsoft Teams werden?

Nein. Teams ist eine Arbeitsoberfläche, deren Dateien in SharePoint liegen. Manche Ablagen benötigen eine SharePoint-Website ohne Team, andere eine eigene Bibliothek oder restriktive Berechtigungen. Ziel und Mitgliedschaft folgen dem betrieblichen Zweck.

Wie lange dauert eine solche Migration?

Die Dauer hängt nicht allein von der Datenmenge ab. Benutzerzahl, Postfachgrößen, Google-Dateitypen, Berechtigungen, externe Freigaben, Fehler im Scan, verfügbare Bandbreite und erforderliche Nacharbeiten bestimmen den Aufwand. Ein Pilot und die Scanberichte liefern eine belastbarere Planung als eine pauschale Zeitangabe.

Technische Quellen

Microsoft 365 in Frankfurt

Google Workspace mit einem prüfbaren Zielbild ablösen

fra.digital erfasst Identitäten, Postfächer, Kalender, Google-Ablagen und die betroffenen Arbeitsabläufe. Daraus entstehen Zielstruktur, Pilot, Umstellungsplan und Abnahmekriterien für den Wechsel zu Microsoft 365.

Migration besprechen