E-Mail-Migration zu Microsoft 365: ohne verlorene Mails und ohne Arbeitswoche-Ausfall

Die Migration der Firmen-E-Mail zu Microsoft 365 sieht nach einem Samstagnachmittag-Job für den IT-Verantwortlichen aus. In einem 25-Personen-Unternehmen ist es tatsächlich ein Drei-Wochen-Projekt mit zwei echten Momenten, in denen man dem Team eine Woche Arbeit kosten kann. Die gute Nachricht: gut geplant merken die Anwender nichts vom Umstieg — außer dass Outlook eine Mail jetzt in einer Sekunde findet statt in dreißig.

Anfang dieses Jahres haben wir eine solche Migration für einen 25-Personen-Großhändler für Industrieteile begleitet. Der alte Mailserver stand im Keller, lief unter Exchange 2013, beherbergte 142 GB Postfächer und hatte gerade angekündigt, in einem halben Jahr den Herstellersupport zu verlieren. Neue Hardware plus Lizenzen wären auf rund 28.000 PLN gekommen — ohne Ransomware-Resilienz und ohne brauchbaren mobilen Zugriff. Nach dem Wechsel auf Microsoft 365 Business Standard (25 Lizenzen × 56 PLN/Monat netto, also 16.800 PLN/Jahr) gab es im selben Preis OneDrive und Teams dazu. Die Migration lief 19 Kalendertage, der MX-Cutover dauerte 4 Stunden in der Nacht von Samstag auf Sonntag, und am Montagmorgen bemerkte der Vertrieb nur, dass die Mail-Konfiguration auf den Handys „sich von selbst eingerichtet" hat. Verlorene Mails: null.

Hier ist das Gerüst, mit dem dieser letzte Satz auch in deinem Unternehmen am Ende stehen kann.

Was zu inventarisieren ist

Die meisten Migrationsprobleme haben eine gemeinsame Ursache: niemand wusste, was wirklich im alten System lag. Die erste Woche ist keine „Migration", sondern eine Bestandsaufnahme.

• Postfächer und ihre Größen. Nicht nur aktive Mitarbeiter — auch geteilte Postfächer (buero@, service@), Aliase und Ex-Mitarbeiter, deren Postfach noch jemand „zur Sicherheit" mitliest. In einem 25-Personen-Unternehmen kommen typischerweise 35–50 Objekte zusammen.
• Regeln, Signaturen, Autoresponder. Server-seitige Regeln verschwinden über Nacht, wenn sie niemand neu anlegt. Genau das ist der Moment, in dem die Buchhaltung plötzlich keine CC mehr auf Rechnungen bekommt, weil die Regel „Kopie an Buchhaltung weiterleiten" auf dem alten Server saß.
• Verteilerlisten und Gruppen. Im Exchange sind sie Objekte, bei gehostetem IMAP oft nur ein Alias-Geflecht beim Provider. Sie müssen auf Papier ankommen, weil sie nirgends sauber exportiert werden.
• SMTP-Integrationen. ERP, Webshop, Multifunktionsdrucker, Kameras, Alarmanlage — alles, was Mails aus eurer Domain versendet. Die Liste ist immer länger, als sich irgendjemand merkt. Daraus entstehen die meisten „seltsamen Montagsfehler".
• DNS-Einträge. MX, SPF, DKIM, DMARC, autodiscover, manchmal auch ein altes _imap._tcp. Mach einen Snapshot, bevor du irgendetwas anfasst. Bei polnischen Kunden sehen wir fast immer einen SPF, der mit zehn alten Providern überfüllt ist, durch die seit Jahren niemand mehr sendet.

Diese Phase ist nicht glamourös, filtert aber 80% der Überraschungen heraus. Ohne sie ist der MX-Cutover ein Sprung ohne Seil.

Wie die Daten umziehen, ohne Stillstand

Microsoft 365 bietet drei realistische Migrationswege, je nachdem, woher man kommt:

• Cutover-Migration (Exchange on-prem, bis 100 Postfächer). Die einfachste Option für kleine Firmen mit lokalem Exchange. M365 zieht die Postfächer selbst über Outlook Anywhere; danach wird MX umgeschaltet. Offizielles Limit: 2.000 Postfächer, für ein 25-Personen-Unternehmen passiert das in einem Rutsch.
• IMAP-Migration (gehosteter Mail-Hoster wie home.pl, OVH, cPanel). M365 verbindet sich als IMAP-Client und kopiert Inbox und Unterordner. Was nicht mitkommt: Kalender, Kontakte, Regeln und in manchen Konfigurationen sogar „Gesendete Elemente". Diese müssen manuell oder über Hilfsmittel (PST) nachgezogen werden.
• PST-basierte Migration. Am wenigsten elegant, aber universell. Jedes Postfach wird in eine PST-Datei exportiert und über Azure Storage in M365 hochgeladen. Funktioniert immer, lässt den Anwender aber mit einer Woche Lücke zwischen „heute morgen" und „heute abend" zurück, sofern man es nicht inkrementell macht.

Für den 25-Personen-Exchange-Kunden haben wir Cutover gewählt. Für ein 12-Personen-Steuerbüro mit gehostetem IMAP — IMAP-Migration plus PST für Kalender. In beiden Fällen ist der Schlüssel die Migration in zwei Wellen: die erste kopiert alles außer den letzten 24 Stunden, die zweite (in der Cutover-Nacht) holt den letzten Tag nach. So musst du Samstagabend nicht 142 GB kopieren, sondern 80–200 MB.

Der MX-Cutover — die Stunde der Wahrheit

Das ist der Moment, in dem sich die Welt umlegt. Aus der Praxis: in der Nacht von Samstag auf Sonntag zwischen 22:00 und 02:00, nie freitagnachts, weil DNS-TTLs in den polnischen Telco-Resolvern selten bis zur ersten Montagsschicht durchgängig sauber sind.

Schritt für Schritt am Cutover-Abend:

1. MX-Eintrag-TTL auf 300 Sekunden senken, idealerweise 24 Stunden vorher. Sonst leiten manche Provider deine Mails noch einen Tag weiter auf den alten Server.
2. Warteschlange auf dem alten Server anhalten und 5 Minuten warten, bis das, was gerade noch reinkam, verarbeitet ist.
3. Delta-Sync in M365 starten — die zweite Welle, die den letzten Tag nachzieht.
4. **MX auf .mail.protection.outlook.com umstellen und gleichzeitig SPF und DMARC aktualisieren*. SPF muss include:spf.protection.outlook.com enthalten — sonst landen deine Mails ab dem Cutover bei deutschen Geschäftspartnern im Spam.
5. Alten Server 72 Stunden als Empfänger weiterlaufen lassen. Manche alten SPF- und MX-Caches bei deinen Partnern aktualisieren sich erst am Montag. Der alte Server im Nur-Empfang-Modus mit Forwarder zu M365 fängt diese Nachzügler ab.
6. Drucker, ERP und SMTP-Integrationen auf den neuen Host umstellen (smtp.office365.com mit technischem Konto und App-Passwort oder, besser, einem M365-Connector mit IP-Authentifizierung).

Genau am letzten Punkt stolpern die meisten Projekte nach dem Go-live. Multifunktionsdrucker, die seit fünf Jahren ohne Anmeldung Scans per Mail verschicken, senden über M365 erst dann wieder, wenn jemand ein technisches Konto mit App-Passwort einrichtet oder einen IP-Connector konfiguriert. Das sind 30 Minuten Arbeit, wenn man daran denkt — oder ein halber Montagvormittag in Panik, wenn nicht.

Was am ersten Montag zu prüfen ist

Die ersten 48 Stunden nach dem Umschalten sind keine Mittagspause. Halt eine Checkliste in der Hand und hak ab:

• Sende- und Empfangstests von drei externen Konten (Gmail, ein O365-Partner, ein polnischer Hosting-Partner). Prüfen, ob die Mail beim Empfänger nicht im Spam landet — DMARC notfalls die erste Woche auf p=quarantine statt p=reject.
• Regeln, Autoresponder, Signaturen für jeden Anwender — Liste aus dem alten Server ziehen und Person für Person abarbeiten.
• SMTP-Integrationen. Hat das ERP die PDF-Rechnung gesendet? Der Drucker den Scan? Der Shop die Bestellbestätigung? Jedes „nein" wird noch am selben Tag erledigt.
• Mobile Clients. Outlook für iOS/Android sollte das neue Konto über autodiscover selbst erkennen. Bei fünf Stichproben prüfen.
• Geteilte Postfächer und Vollzugriffe. „Die Assistenz hatte Zugriff auf das Postfach der Geschäftsleitung" — das ist eine separate Konfiguration, die manuell nachgezogen werden muss.

Plan in derselben Woche das erste Backup der M365-Postfächer ein. Microsoft hält deine Mails auf eigenen Servern, macht aber kein Backup, mit dem du eine Löschung von vor sechs Monaten zurückholen kannst. Das ist eine eigene Entscheidung und ein eigener Kostenpunkt (siehe unseren Beitrag zum Microsoft-365-Backup für KMU).

Wie geht es weiter

Eine E-Mail-Migration zu Microsoft 365 im KMU ist technisch nicht kompliziert. Sie ist aber nachtragend gegenüber dem Chaos, das üblicherweise in DNS-Einträgen, Server-Regeln und SMTP-Integrationen lebt. Wer dir einen „Wochenend-Switch ohne Plan" verkauft, verkauft nicht das, was du brauchst — du brauchst zwei Wochen Inventur und eine Nacht Cutover.

Wenn du in den nächsten Monaten den Schritt zu Microsoft 365 planst oder mitten in der Migration feststeckst — lass uns reden. Das erste Gespräch ist kostenlos und dauert eine halbe Stunde. Oft reicht es, um die größten Risiken in deiner Konfiguration aufzuzeigen, bevor jemand MX anfasst.

Die Microsoft-365-Migration endet nicht mit dem MX-Wechsel — sie endet erst, wenn Drucker, ERP und Shop wieder so Mails verschicken wie am Freitagabend.

← Zurück zum Blog