Exchange Migration mit Office 365

Es gibt ein paar Optionen, von einem Mailsystem in ein neues System umzuziehen, z.B.:

• Stichtag
  d.h. alle Benutzer arbeiten nach einem Zeitpunkt nur noch mit der neuen Umgebung. Es gibt keine Koexistenz-Phase und zu diesem Stichpunkt wird der MX-Record umgestellt, die neuen Clients genutzt, alle Mobilgeräte angepasst. Diese Migration ist einfach aber mit steigender Benutzeranzahl kaum zu stemmen. Neben der "Fehlerfreiheit" und dem fast unmöglichen "Undo" bei übersehenen Problemen ist der personelle Aufwand für Support und Problembehandlung ein Grund für den Einsatz bei kleinen Umgebungen, z.B. <200 Benutzer
• Hybrid/Koexistenz
  Je größer eine Firma ist, desto eher ist die schrittweise Migration z.B. pro Team angesagt. Hier muss natürlich eine Koexistenz realisiert werden. Im einfachsten Fall nur als ein internes Mailrouting und idealerweise mit einem Abgleich der Adresslisten. Im erweiterten Fall aber auch die Anzeige von Frei/Belegt-Zeiten und die Nutzung gemeinsamer Datenpools (Shared Mailboxen, öffentliche Ordner)

Ein Notes Server kann als "Mail/Termin/Kontakt-Server" verwendet werden. Die meisten Notes Systeme sind aber auch Applikationsserver und hier wird eine Migration nach Office 365 Exchange auf Grenzen stoßen. Aber auch für die Mail, Termine und Kontakte gibt es unterschiedliche Ansätze

• "Nur Mails" per IMAP migrieren
  Das kann Office 365 sogar alleine um so die Mails aus der Quelle in das Ziel zu übertragen. Leider betrifft dies nicht die Termine, Kontakte u.a. Und auch andere Informationen gehen dabei verloren.
• "Umfangreiche Migration" per 3rd Party Produkte
  Es gibt eigens für die Migration von Notes nach Exchange verfügbare Werkzeuge, die eine umfangreichere Konversion der Inhalte von einer Plattform auf die andere Plattform versprechen. Früher haben diese Tools per VIM in Notes die Daten gelesen und per MAPI/CDO in Exchange importiert. Der Weg in Exchange ist heute natürlich EWS. Andere Programme können über einen lokalen Agenten erreicht werden, was ganz neue Wege eröffnet.
• Umweg über Exchange 2007
  Exchange 2007 ist immer noch "verfügbar" und kann installiert werden. für Exchange 2007 gibt es die kostenfreie Transporter Suite. Man kann also durchaus überlegen, die Notes-Mails über den Weg auf einen temporären lokalen Server zu migrieren und erst dann über Hybrid in die Cloud zu gehen.
• Keine/späte Migration
  Es muss wirklich gefragt werden, ob die alten Informationen "migrationswürdig" sind. für Termine und Kontakte kann das schon wichtig werden aber wer schaut schon in die Mails älter 30 Tage nach? Solange das alte System zur Suche noch da ist kann man sogar mit einem "leeren Postfach" beginnen und eventuell frühere Mails nachliefern.
• Client Migration
  Es gibt durchaus auch Variante, dass der Anwender selbst seinen Client sowohl mit dem alten als auch dem neuen System verbindet und selbst die Mails verschiebt/kopiert. Das ist aber wirklich nur für ganz kleine Umgebungen (<25 Benutzer?) praktikabel und durchaus Fehler anfällig.

Werden aber Inhalte übernommen, gibt es durchaus Fragen, die hier gestellt werden müssen:

• Welche Postfächer
  Räumen Sie auf, denn jede Mailbox, die sie sowieso nicht brauchen, sollten Sie schon in der Quelle aufräumen statt zu migrieren. Vielleicht hilft die Information, dass eine migrierte Mailbox in der Cloud wirklich auch eine Lizenz kostet.
• Welche Elemente ?
  In einem Notes Postfach sind durchaus neben Mails auch Termine und Kontakte enthalten. Die Speicherformat, speziell bei Serienterminen und Feiertagen weichen durchaus voneinander ab, so dass beim Kopieren sicher die ein oder andere Information verloren gehen wird. Wie gut die Konversion ist, hängt auch vom eingesetzten Tool ab. Tools, die schon lange im Markt sind, haben meist schon mehr Sonderfälle gesehen als neue Marktteilnehmer
• Alter und Größe
  Wenn das Quellsystem schon einige Jahre im Betrieb war, dann haben sich oft viele tausende Mails angesammelt und Anlagen brauchen Platz. Die Übertragung in die Cloud dauert entsprechend lange und es kann durchaus hilfreich sein, z.B. große Anlagen zu überspringen oder vorher zu beseitigen und zumindest bei Mails eine realistische Altersbegrenzung anzusetzen. Beachten Sie, dass z.B.: per EWS in Office 365 nur maximal 25MB-Elemente abgelegt werden können. Hier sollten Sie also "putzen"
• Verschlüsselte Elemente
  Es ist in Notes sehr einfach, Mails mit den Schlüsseln der NotesID zu verschlüsseln. Bei der Migration sind genau diese Mails natürlich die Problemfälle. Die Anwender sollten diese vorab also entschlüsseln.
• Termin “Einladungen”
  Auch Termine können knifflig sein, insbesondere Serientermine, zu denen man eingeladen wird. Beim Kopieren ins Ziel steht man vor der Wahl, ob im Ziel die Einladung noch mal versendet wird oder man darauf vertraut, dass die anderen Postfach die Einladung mit migrieren. Dann fehlt in der Regel aber die Verknüpfung, so dass bei einer TerminÄnderung oder Absage kein Update erfolgt
• DocLinks
  Notes kennt natürlich auch Hyperlinks zu Dokumenten, die anderswo liegen. Ein Doclink im Ziel funktioniert nur, wenn dieser entweder ein HTTP-Link auf den weiter laufenden Notes Server ist oder der Notes Client das Dokument weiter erreichen kann. Hier sind Kompromisse erforderlich
• Persönliche Verteiler
  Wer in seinen Kontakten eigene Verteiler pflegt die auf Einträge im Adressbuch verweisen, muss darauf hoffen, dass das Migrationswerkzeug diese Mitgliedschaften auch korrekt aktualisiert.
• Notes Applikationen
  Alle "Applikationen", für die Notes so bekannt ist, sind ein ganz eigener Baustein der Migration. Auch wenn viele hier eine automatische Lösung versprechen, so habe ich bislang immer die Erfahrung gemacht, dass man sich jede Applikation anschauen und überlegen muss, wie und ob diese in Zukunft weiter genutzt werden kann
• Mailadressen und “Reply”-Funktion (Konvertierung)
  Da ist es dann schon wieder einfach, bei jedem übertragenen Element die enthaltenen Mailadressen von Notes nach SMTP umzustellen. Voraussetzung ist, dass das Migrationswerkzeug vorher natürlich auch alle alten und neuen Empfänger erfasst hat.

Mittlerweile können Sie mit Exchange Online sogar öffentliche Ordner betreiben und entsprechend auch von On-Premises nach Exchange Online migrieren. Denken Sie dabei aber an ein paar Eckpunkte

• Mailbox vor Public Folder
  Sie sollten erst die Postfächer in die Cloud migrieren, ehe sie die öffentlichen Ordner verlagern. Anfangs war das sogar notwendig, da Exchange On-Premises-Postfächer und Outlook Clients nicht auf öffentliche Ordner in der Cloud zugreifen konnten.
• 100GB Public Folder Datenbank
  Wie auch mit Exchange On-Premises werden die öffentlichen Ordner auch in der Cloud nicht mehr in einer eigenen Public Folder Datenbank abgelegt, sondern in Postfachdatenbanken. Sie können und sollten ggfls. mehrere Public Folder Postfächer anlegen, wenn jedes dieser Postfächer ist auf 100 GB beschränkt und mehr als 1000 Postfächer sind auch nicht möglich
• 25GB pro Public Folder
  Zusätzlich darf ein einzelner Ordner nicht größer als 25 GB sein. Wer heute größere Ordner On-Premises hat, sollte Inhalte auslagern oder auf mehrere Ordner verteilen oder löschen.

Eine gute Referenz sind hier die Exchange Online Limits und Migrationsanleitungen:

• 
  Use batch migration to migrate legacy public folders to Microsoft 365 or Office 365
  https://docs.microsoft.com/en-us/exchange/collaboration-exo/public-folders/batch-migration-of-legacy-public-folders
• Exchange Online limits
  https://docs.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits
• Public folders in Microsoft 365, Office 365, and Exchange Online
  https://docs.microsoft.com/en-us/exchange/collaboration-exo/public-folders/public-folders
• Public folder procedures in Office 365, Microsoft 365, and Exchange Online
  https://docs.microsoft.com/en-us/exchange/collaboration-exo/public-folders/public-folder-procedures

Im Notes Adressbuch sind die verschiedenen Empfänger enthalten, die vom Server für die Zustellung der Mails und von Anwendern als Adressbuch genutzt werden. Über den Office 365 DirSync können die Anwender in der Cloud anhand eines On-Prem-AD gepflegt werden aber da Notes anders als Exchange das AD nicht nutzen, kommen so in Office 365 keine Daten der Benutzer für das Mailsystem an. Das sind primär natürlich die Mailadressen aber es gibt noch weitere Informationen:

• Mailadressen
• Displayname
• Mailverteiler 
• Mailkontakte
• Stellvertreter und Teams

Heute Notes, morgen Outlook, OWA, ActiveSync. Da steht ein großer Berg "Softwareverteilung" vor ihnen, der bewältigt werden muss. Natürlich lässt sich mit Office 365 auch ein Outlook per "Streaming" relativ smart auf einen Client bringen. Wenn Sie aber viele Clients haben und alle in kurzer Zeit umgestellt werden, dann sollten Sie eine alternative Verteilung vorsehen. Aber selbst mit installiertem Client und "Autodiscover" ist eine gewisse Fehlerrate vorhanden, die einen Supporteinsatz erfordern wird.

Vielleicht wollen Sie im gleichen Schritt auch die Mobilegeräte verwalten (z. B. Quarantäne). Gerade der Wechsel auf dem Mobilgerät ist für Anwender nicht einfach. Löschen Sie doch ihre alte Partnerschaft um dann eine neue einzurichten. Hoffentlich haben ihre Anwender vorher noch die Change gehabt, Mails auf einem mobilen Gerät zum Server zu synchronisieren, damit diese auch migriert wird.

Neben der Abstimmung kommt natürlich auch der Schulungsbedarf bei den Anwendern dazu.

Dass ein Prozess etwas bewegen muss, ist unzweifelhaft. Bleibt die Frage wer dies betreibt und wo der Dienst beheimatet ist. Der Weg in die Cloud eröffnet nämlich auch ganz neue Wege für die Migration. Zumindest wenn die Migration einfacheren Anforderungen genügen muss.

• Lokal Selbstbetrieb
  Natürlich gibt es die klassischen Tools, die Sie auf einem Server in ihrem LAN installieren und die von Notes die Daten "lokal" extrahieren und dann per EWS in die Cloud übertragen. Diese Programme können Sie klassische kaufen und einsetzten
• Lokal Remote Managed
  Mittlerweile bieten die Hersteller dieser 3rd Party Werkzeuge auch die Dienstleistung an, die Migration durchzuführen. Die Programme werden bei ihnen lokal installiert aber aus der "Ferne" von einem Fachmann bedient. Ein gewisses Vertrauen ist hier natürlich erforderlich, dass externe auf System in ihrem Netz dürfen und alle Mails in der Quelle lesen und im Ziel ablegen können.
• Hosted Managed
  Eine dritte Version besteht darin, dass ein Drittanbieter auf seiner Plattform in der Cloud die Software zur Migration betreibt und die Elemente aus ihrem Notes System extrahiert und von dort in die Cloud verschiebt. Es gibt Produkte, die die Daten direkt von ihrem Notes Server holen und in die Cloud übertragen. Interessant ist hier auch der Ansatz eines Produkts, einen Notes Server in der Cloud zu betreiben und all ihre lokalen NSF-Dateien erst mal auf die Server in der Cloud zu replizieren und von dort dann an einen Wochenende mit geballte Bandbreite in die Cloud zu schieben.
• Hosted Selbstbetrieb
  Natürlich gibt es auch die Option, dass Sie die Software in der Cloud von Anbieter hosten lassen aber selbst die Migration steuern.

Auch hier zeigt sich, dass neue Denkweisen bei einer Migration zu überlegen sind. Wobei die meisten dieser Lösungen natürlich eher eine Umstellung zu einem Stichtag unterstützen und seltener eine lange Koexistenz. Wenn die Migration aber schon hosted läuft, dann lassen sich natürlich auch ganz andere Lizenzmodelle etablieren, z.B. EinzelUserabrechnung oder nach Datenmenge.

Achtung
Angeblich kann man in einem Office 365 Tenant maximal 200 Weiterleitungen nach extern einrichten oder Microsoft blockt Weiterleitungen, wenn es zu viele externe Empfänger gibt.. Das ist bei Migrationen zu beachten, wenn Sie der Benutzer schon im Ziel arbeitet und Sie Mails an dan Quellpostfach ins Ziel umleiten.

Dies ist also zu berücksichtigen, wenn Sie aus einem Tenant raus migrieren und damit Mails eine Zeit lang noch in das Ziel weiterleiten wollen. Das ist natürlich die Stärke von 3rd Party Tools, die z.B. per EWS die Inhalt replizieren und damit keine SMTP-Weiterleitung erforderlich ist.

Sie sind gut beraten möglichst genau die QuellUmgebung zu können. Dazu gehören u.a. die folgenden Fakten

• Größen
  Die Menge an Mails (In MB und Stück) ist für die spätere Migrationsdauer eine wichtige Zahl
• Postfächer
  Die meisten Produkte lizenzieren nach Benutzern.
• Mailadressen
  Wichtig für die Domänen, die später im Ziel bedient werden sollen
• Verteiler
  Diese werden für die Verteilung von Mails aber auch für Berechtigungen genutzt. Wenn bei der Migration nicht alle Benutzer auf einmal übertragen werden, müssen die Verteiler auf beiden Seiten synchron gehalten werden. Das kann schon sportlich sein
• Verschlüsselung
  Prüfen Sie, ob Elemente gegen eine Übertragung geschützt sind, z.B. durch DRM, SMIME oder proprietäre Verschlüsslungen. Wer einen Systemwechsel vornimmt, z.B.: von GroupWise oder Notes nach Exchange muss die Elemente zumindest entschlüsseln
• Applikationen
  Nicht immer ist ein Mailsystem "nur" ein Mailsystem. Integrationen in CRM und Konnectoren zu Fax etc. sollten Sie können und eine Lösung für die Zeit nach der Migration entwerfen. Bei Notes ist das Thema Applikation natürlich besonders zu bearbeiten.
• Entscheidung
  Am Ende der Analyse steht die Entscheidung, wie und was womit migriert wird

Ehe die eigentliche Migration der Inhalte erfolgen kann, sind natürlich Vorarbeiten zu leiten, z.B.

• Ziel-Umgebung einrichten
  d.h. z.B. Office 365 Vertrag abschließen, ggfls. Benutzer anlegen, Domänen autorisieren, Lizenzen zuweisen
• Berechtigungen
  Das Migrationskonto benötigt in der Quelle und im Ziel die Rechte die Elemente zu lesen und zu schreiben. Begriffe wie Delegation, Impersonation, Throttling werden hier fallen. Hier ist auch eine gute Change, die Postfächer auf alte Berechtigungen zu prüfen und zu bereinigen. Wenn Sie z.B. in einem Postfach früher einen Stellvertreter eingetragen hatten und das AD-Konto gelöscht wurde, bleiben die Rechte als "S-Nummer" erhalten und stören die Migration. (Siehe auch MailboxACL)
• Mailrouting
  Sie müssen sicher sein, dass die Empfänger unter ihrer SMTP-Adresse weiterhin erreichbar bleiben und die Mails zwischen den Welten möglich ohne Spamfilter und verschlüsselt übertragen werden. Bei einer Koexistenz läuft das aus SMTP-Connectoren und Kontakte hinaus
• Client
  Bei einem Systemwechsel muss auch der Client eventuell schon vorbereitet werden. Planen Sie Schulungen und Handouts für die Umstellung . Vergessen Sie die mobilen Clients nicht
• Cleanup
  Klären Sie den Status jedes Empfängers und den Inhalt von Mailboxen. Wenn Sie etwas aufräumen können, dann tun sie dies vor der Migration, um die Datenmenge zu reduzieren und überflüssige Probleme vorweg zu beseitigen, z.B. 25MB Limit für Elemente , tote Postfächer)

Die eigentliche Migration beschäftigt sich dann mit der Übertragung der Daten von der Quelle ins Ziel entlang des festgelegten Migrationswegs.

Auch wenn alle Elemente schon im Ziel sind und alle Benutzer das Ziel nutzen, sollte das Quellsystem sauber zurück gebaut werden. Kontrollieren Sie z.B. Zugriffe und irrtümlich noch zugestellte Mails, stellen Sie die falsch konfigurierten Absender um und leiten Sie die Mails weiter. Wenn das alte System nicht mehr erforderlich ist, dann sollte es auch weg