Eine Exchange-Online-Migration scheitert selten daran, dass Postfächer sich nicht kopieren lassen. Sie scheitert an Scannern, die noch den alten internen Mailserver ansprechen, an öffentlichen Ordnern, die niemand gezählt hat, und an einem MX-Wechsel am Freitagnachmittag, nach dem niemand mehr im Haus ist. Wer das Fenster an einem Werktag legt und den DNS-Rückweg kennt, bleibt handlungsfähig, wenn eine Anwendung Mail nicht annimmt.

Welche Altlasten eine Mailumstellung aufhalten

Vor dem Kopieren steht die Frage, woher die Postfächer kommen. Ein lokaler Exchange, ein IMAP-Postfach beim Hoster oder ein Berg von PST-Dateien sind drei verschiedene Wege, und sie verlieren unterschiedlich viel: Regeln, Stellvertretungen, Kalenderfreigaben und den Inhalt öffentlicher Ordner. Wird das erst am Umstellungstag entdeckt, bleibt nur noch der Notimport, und der ist langsam und unvollständig.

Gleichzeitig senden Geräte und Fachanwendungen Mail, ohne dass ein Benutzer das merkt: Multifunktionsgeräte, die Alarmanlage, das Buchungsprogramm, die Warenwirtschaft. Diese Absender stehen nicht in der Postfachliste. Fehlen sie im Plan, kommt nach dem MX-Wechsel keine interne Statusmail mehr an, obwohl Outlook bei den Mitarbeitern schon funktioniert.

Ein Fenster mit Inventur, Probe und Rückweg

  1. Quelle. Wir listen Postfächer, Räume, gemeinsame Konten, Verteiler und öffentliche Ordner mit Größe und letztem Zugriff. PST-Dateien auf Laufwerken gelten als Quelle, nicht als Randnotiz.
  2. Absender. Scanner, Fachsoftware und Webformulare werden mit Absenderadresse und heutigem Versandweg erfasst. Was keine Anmeldung kann, bekommt vor dem MX-Wechsel einen anderen Weg.
  3. Probe. Ein unkritisches Postfach wird vollständig umgezogen, inklusive Kalender und Stellvertretung. Daran zeigt sich, ob Profile neu angelegt werden müssen.
  4. Fenster. Der MX-Wechsel liegt an einem Werktag mit erreichbarer Fachabteilung. Die TTL ist vorher niedrig, der alte Eintrag liegt schriftlich bereit.
  5. Nachlauf. Autodiscover, alte Outlook-Profile, Mobilgeräte und Weiterleitungen werden in den Tagen danach geprüft, nicht erst wenn die erste Mahnung fehlt.

Ob der Zielzustand ein reiner Cloud-Betrieb oder eine Übergangsform mit lokalem Exchange ist, klären wir vor dem ersten Kopierlauf. Beides im selben Wochenende zu entscheiden, vermischt zwei Projekte. Die Migration bewegt Postfächer; die Betriebsform bestimmt, wer danach Empfänger und Relays verwaltet.

Woran Projekte in der Praxis scheitern

  • Öffentliche Ordner und freigegebene Kalender erst bemerken, wenn Benutzer sie in Outlook vermissen.
  • Den MX-Eintrag ändern und gleichzeitig den Domain-Registrar oder das Webhosting umziehen.
  • Alle Outlook-Profile am Freitag automatisiert neu erzeugen, ohne dass jemand die Nebenstellenanlage und die Scanner mitprüft.
  • PST-Dateien per Drag-and-drop als einzige Migrationsmethode nutzen und Regeln sowie Zugriffsrechte damit verlieren.

Beispiel aus dem Betriebsalltag

Ein Installationsbetrieb in Mödling hatte die Postfächer über das Wochenende sauber in Exchange Online. Am Montag fehlten die Lieferscheine aus dem Scanner im Lager, weil das Gerät weiterhin die IP des abgeschalteten Exchange-Servers verwendete. Die Mitarbeiter hielten Outlook für defekt. Nachdem der Scanner auf einen authentifizierten Versand umgestellt war, lief der Versand wieder; der MX-Eintrag musste nicht zurück. Seither steht jedes sendende Gerät auf dem Migrationsblatt, bevor Postfächer bewegt werden.

Kurze Entscheidungshilfe

  • Gibt es eine Liste aller Systeme, die Mail senden, inklusive Absenderadresse?
  • Sind öffentliche Ordner, Raumkalender und Stellvertretungen gezählt?
  • Liegt der DNS-Zugang auf einem Firmenkonto, und ist der alte MX-Wert notiert?
  • Ist eine Person aus der Buchhaltung am Umstellungstag erreichbar, um eine echte Rechnung zu senden und zu empfangen?

Wenn die Migration nach Exchange Online bei Ihnen ansteht, klären wir den Umfang unverbindlich: Microsoft 365 und Cloud. Hybrid oder Cloud-only Alternativ direkt Kontakt aufnehmen oder die häufigen Fragen lesen.