Sicher aus Google Workspace migrieren

Wer E-Mails aus Google Workspace migriert und dabei falsch vorgeht, erhält geteilte Zustellung, fehlende Aliasse und verärgerte Nutzer am Montagmorgen. Das ist eine Umschaltung und kein einfacher Export per Ziehen und Ablegen. Für den größeren Kaufkontext lesen Sie geschäftliche E-Mail. Wenn der Umzug bereits geplant ist, zeigt dieses Betriebshandbuch, wie E-Mails ohne Störung der eingehenden Zustellung zu einem IMAP-Host wie TrekMail wechseln.

Die Falle ist einfach: Administratoren konzentrieren sich auf alte Nachrichten und vergessen das Routing. Der E-Mail ist gleichgültig, dass die Migration zu 92% abgeschlossen ist. Sobald MX geändert wird, gehen neue Nachrichten an ein Ziel. Sind Aliasse, Gruppen, DNS und Clients nicht gleichzeitig bereit, entstehen zwei verschiedene Posteingänge. Nutzer senden weiter, Kunden antworten weiter, und die Hälfte landet am falschen Ort.

Die Lösung liegt in der Reihenfolge. Zuerst erfassen, dann vorab übertragen, DNS einmal ändern, Clients sauber neu verbinden und anhand von Elementzahlen prüfen. TrekMail passt zu diesem Modell mit gemeinsam genutztem Speicher, Multi-Domain-Hosting zum Pauschalpreis, integrierter IMAP-Migration und Standardunterstützung für IMAP/SMTP ohne Gebühren pro Nutzer.

Was bedeutet die Migration aus Google Workspace?

Sie müssen gespeicherte E-Mails über IMAP übertragen und anschließend das Routing für neue Nachrichten von Google zum neuen Anbieter wechseln. Der Kopiervorgang ist wichtig, die Umschaltung jedoch noch wichtiger. Wird das Routing geändert, bevor Identitäten, DNS und Clients bereit sind, verschwinden E-Mails in den falschen Posteingängen.

Diese Unterscheidung zählt, weil Google Workspace verschiedene Identitätstypen hinter einer Verwaltungsoberfläche verbirgt. Ein Anmeldekonto ist nicht dasselbe wie jede Adresse, die E-Mails für diese Person empfängt. Gemeinsame Aliasse, Gruppenadressen, Weiterleitungen und Catch-all-Verhalten beeinflussen die Umschaltung.

Bauen Sie die Zielseite vollständig auf, bevor DNS geändert wird. Bei TrekMail bedeutet das gewöhnlich: Domain hinzufügen, DNS-Einträge bestätigen, alle Postfächer erstellen und entscheiden, welche Adressen Aliasse bleiben oder echte Postfächer werden. Diese Dokumentationen helfen: Domain hinzufügen, erforderliche DNS-Einträge prüfen und nachlesen, wie TrekMail Gmail-Migrationen behandelt.

Phase 1: Vor jedem Kopiervorgang eine forensische Bestandsaufnahme erstellen

Die erste echte Aufgabe besteht darin, jede empfangsfähige Adresse zu finden. Hauptnutzer sind offensichtlich. Aliasse, Gruppen und alte Routingregeln verursachen Fehler. Fehlen diese Adressen, werden sie nach der DNS-Umschaltung zu harten Rückläufern oder stillen Sackgassen.

Beginnen Sie mit vier Listen:

Hauptnutzer und deren Postfachgrößen.
Alle mit jedem Nutzer verbundenen Aliasse.
Google Groups, die noch echte eingehende E-Mails empfangen.
Weiterleitungen, Catch-alls und stillgelegte Adressen, die weiterhin auf Rechnungen, Formularen oder Signaturen stehen.

Einfache Administratorexporte genügen deshalb nicht. Eine Vertriebsmitarbeiterin meldet sich etwa als jane@company.com an, empfängt aber weiterhin Nachrichten an sales@company.com, quotes@company.com und einer nicht dokumentierten alten Akquisitionsdomain. Wird eine davon vergessen, wirkt die Umschaltung trotz korrektem DNS defekt. Jede routingfähige Adresse braucht ein Ziel.

Administratoren verwenden zur Datenerfassung aus Google häufig GAM oder das Admin SDK, um eine vollständige Routingkarte zu erstellen. Das konkrete Werkzeug ist zweitrangig. Entscheidend ist, dass jede erreichbare Adresse vor der Migration einen ausdrücklichen Platz im Zielsystem besitzt.

gam print users aliases > aliases.csv
gam print groups members > group_members.csv

Entscheiden Sie bei der Sichtung, was jede Identität am neuen Host werden soll:

Adresstyp	Alter Weg	Neuer Weg
Hauptnutzer	Zuerst E-Mails kopieren und auf späteres Routing hoffen	Postfach zuerst erstellen und E-Mails genau dorthin importieren
Nutzeralias	Ignorieren, weil es keine Anmeldung ist	Vor der Umschaltung als Alias oder Weiterleitung anlegen
Gemeinsamer Teamposteingang	Als Google Group belassen und hoffen	Entscheiden, ob Postfach, Alias oder Weiterleitung sinnvoll ist
Stillgelegte, weiterhin genutzte Adresse	Erst durch Kundenbeschwerden davon erfahren	Bei der Bestandsaufnahme zuordnen und empfangsfähig halten

Eine Entscheidungshilfe bietet Domain-E-Mail-Alias oder Postfach. Viele Migrationsfehler beginnen genau dort.

Phase 2: Daten vorab übertragen, weil Google IMAP drosselt

Bei jeder nennenswerten Größe ist eine Vorbereitungsphase nötig. Google dokumentiert IMAP-Bandbreitenlimits für den täglichen Abruf und Upload je Konto. Große Postfächer werden nicht an einem Wochenende fertig, unabhängig vom Optimismus des Projektplans.

Google nennt für Workspace-Konten folgende Gmail-Bandbreitenlimits: 2,500 MB IMAP-Download und 500 MB IMAP-Upload pro Tag. Das sind technische Rahmenbedingungen, keine Empfehlung. Ein Postfach mit 50 GB kann beim vollständigen Abruf über IMAP Wochen brauchen.

Daraus ergibt sich dieses Muster:

Ältere E-Mails vorab übertragen, während Nutzer noch mit Google arbeiten.
An den Tagen vor der Umschaltung Delta-Synchronisierungen ausführen.
Neueste E-Mails nach dem DNS-Wechsel oder im letzten Synchronisierungsfenster übertragen.

Teilen Sie schwere Nutzer nach Datumsbereichen auf, wenn das Tool dies erlaubt. Der Migrationsablauf von TrekMail unterstützt gestaffelte Importe, sodass E-Mails in Gruppen statt mit einem blinden Komplettabruf migriert werden können.

Beispiel: Besitzt die Buchhaltung ein Postfach mit 36 GB, braucht aber sofort nur die letzten 90 Tage, importieren Sie zuerst aktuelle Ordner, ändern den E-Mail-Fluss und ergänzen das Archiv nach Stabilisierung des Betriebs.

Auch Googles aktuelle Anmeldehinweise sind wichtig. Die ältere Standardauthentifizierung ist weitgehend entfallen; App-Passwörter bleiben in unterstützten Konfigurationen die wichtigste Ausnahme. Für Gmail-Quellen verlangt die TrekMail-Dokumentation je nach Google-Richtlinie ein Gmail-App-Passwort statt des normalen Kontopassworts. Siehe Googles Hilfe zu App-Passwörtern.

Phase 3: DNS einmal und in richtiger Reihenfolge umstellen

DNS entscheidet bei der Umschaltung, wo neue E-Mails eintreffen. Senken Sie die TTL rechtzeitig, veröffentlichen Sie die neuen Authentifizierungseinträge und ändern Sie MX erst, wenn Zielpostfächer und Aliasse bestehen. Eine umgekehrte Reihenfolge erzeugt geteilte Zustellung.

Die saubere Reihenfolge ist bewusst unspektakulär. Senken Sie zwei Tage vorher TTL für MX, SPF und DMARC auf 300 Sekunden. Veröffentlichen Sie einen Tag vorher DKIM für den Zielanbieter. Ersetzen Sie bei der Umschaltung Googles MX durch TrekMail. Prüfen Sie die Verteilung anschließend über einen öffentlichen Resolver statt über den Cache Ihres Laptops.

; Transitional SPF while some devices still send through Google
v=spf1 include:_spf.google.com include:spf.trekmail.net -all

dig @1.1.1.1 example.com MX +short

Belassen Sie während der Überschneidung Google und TrekMail im SPF, wenn über beide Systeme gesendet wird. Das entspricht RFC 7208. Beachten Sie das Limit von 10 DNS-Abfragen. Ist der Eintrag bereits mit Anbietern überladen, vereinfachen Sie ihn vor der Migration.

Bei wiederholten Umzügen vieler Kundendomains zahlt sich TrekMail aus. Der alte Weg ändert DNS und Postfächer Domain für Domain bei gleichzeitigen Nutzergebühren. Der neue Weg bietet eine Plattform zum Pauschalpreis mit Multi-Domain-Verwaltung, gemeinsam genutztem Speicher, DNS-Assistent und integrierter Migration.

Phase 4: Clients und nicht nur Passwörter korrigieren

Nach der Migration wirken viele Supportfälle wie Passwortfehler, sind aber keine. Auf Google eingerichtete Clients behalten OAuth-Annahmen, zwischengespeicherte Autodiscover-Daten oder alte Anbietervorgaben. Nutzer brauchen eine neue IMAP-Konfiguration für den neuen Host und keine verzweifelte Schleife von Passwortversuchen.

Mobilgeräte und Outlook sind besonders betroffen. Auf Smartphones wählen Nutzer aus Gewohnheit das Google-Logo, was nach der Umschaltung falsch ist. Alte Outlook-Profile versuchen möglicherweise weiterhin Google zu erreichen, obwohl MX längst woanders hinzeigt.

Verwenden Sie für TrekMail direkte IMAP-Einstellungen:

Incoming server: imap.trekmail.net
Port: 993
Security: SSL/TLS
Username: full email address
Password: mailbox password

Entfernen Sie auf iPhone und Android das alte Google-Konto und fügen Sie das Postfach als „Andere“ oder IMAP hinzu. Erstellen Sie in Outlook Desktop ein neues Mailprofil, statt das alte zu reparieren. Die TrekMail-Clientanleitungen erklären die IMAP/SMTP-Einstellungen. Für einen manuellen Migrationsablauf ergänzt der Leitfaden zu imapsync diese Informationen.

TrekMail ist standardorientiertes IMAP-Hosting. Kein POP3, kein vorgetäuschtes Exchange. Wer auf proprietären Einrichtungsabläufen von Google oder Microsoft besteht, arbeitet mit dem falschen Protokoll.

Phase 5: Mit Anzahlen prüfen und Rückkehr einfach halten

Prüfen Sie den Postfachzustand anhand von Ordnerzahlen und echtem E-Mail-Fluss, nicht anhand der Gigabyte. Googles Speicheransicht enthält Komprimierung und nicht postalische Faktoren, die sich nicht direkt auf IMAP-Ziele abbilden lassen. Zählen Sie Nachrichten, bestätigen Sie Ein- und Ausgang und schließen Sie dann die Umschaltung ab.

Die Mindestcheckliste:

Ordnerzahlen stimmen bei allen wichtigen Postfächern ausreichend überein.
Eingehende Tests erreichen nach der MX-Verteilung nur TrekMail.
Ausgehende E-Mails bestehen SPF-, DKIM- und DMARC-Prüfungen.
Aliasse und gemeinsame Adressen liefern genau an das vorgesehene Ziel.
Nutzer können sich mit den neuen Einstellungen auf Desktop und Mobilgerät anmelden.

Kleine Abweichungen können normal sein. Beschädigte Nachrichten, fehlerhafte Einladungen und ungewöhnliche leere Elemente überstehen IMAP nicht immer. Nicht normal ist, wenn neue eingehende E-Mail nach dem vermeintlichen Abschluss weiterhin Google erreicht. Dann ist die Migration noch nicht beendet.

Die Rückkehr muss direkt und schnell sein. Wenn eingehende E-Mail allgemein ausfällt, stellen Sie MX auf Google zurück, solange die TTL niedrig ist. Exportieren Sie danach Nachrichten, die im fehlerhaften Zeitfenster am neuen Host eingingen, und fügen Sie sie bei Bedarf erneut ein. Ein Rückkehrplan, der nicht in fünf Minuten ausführbar ist, ist keiner.

Alter Weg und neuer Weg: Warum Administratoren TrekMail wählen

Bei häufigen Migrationen besteht der tatsächliche Aufwand nicht nur aus Lizenzkosten. Er umfasst wiederkehrende Verwaltung von Domains, Postfacherstellung, Clientzurücksetzungen und Wiederholungen. TrekMail reduziert diese Arbeit mit einem Multi-Domain-Modell zum Pauschalpreis für Betreiber statt Tabellen pro Nutzerplatz.

Schritt	Alter Weg	Neuer Weg mit TrekMail
Bereitstellung	Postfächer einzeln erstellen und berechnen	IMAP-Postfächer auf einer Plattform zum Pauschalpreis anlegen
Speicher	Grenzen und Zusatzkäufe pro Nutzer verfolgen	Gemeinsamen Speicher im gesamten Konto verwenden
Migration	Eigenes Werkzeug kaufen oder skripten	Integrierte IMAP-Migration kostenpflichtiger Tarife nutzen
Domainbetrieb	Jede Domain in einem getrennten Administrationsbereich verwalten	Mehrere Domains über ein Dashboard betreiben
Kosten	Weiterhin Nutzeraufschläge bezahlen	Mit Starter ab $3.50/month beginnen und nach Tarif statt Nutzerplatz skalieren

TrekMail bietet eigene Domains, IMAP-Postfächer, Catch-all, Weiterleitung, eigenes oder je nach Tarif enthaltenes SMTP und serverseitige Migration. Nano bleibt kostenlos und benötigt keine Karte. Kostenpflichtige Tarife bieten einen kostenlosen Testzeitraum von 14 Tagen, für den eine Kreditkarte erforderlich ist. Wer heute eine Marke und im nächsten Quartal zwanzig Kundendomains verwaltet, erkennt den Unterschied zwischen Marge und Chaos.

Für Teams mit vielen gleichzeitigen Postfächern ähnelt der betriebliche Vorteil dem Multi-Domain-E-Mail-Hosting: ein Dashboard, weniger Komponenten und keine Gebührenfalle bei jedem neuen Posteingang.

Wenn die Migration nicht zum Notfall am Wochenende werden soll, beginnen Sie bei den TrekMail-Preisen. Bauen Sie zuerst das Ziel auf, übertragen Sie E-Mails vorab, ändern Sie DNS einmal und prüfen Sie anschließend wie ein Administrator.