Exchange Migration mit Office 365

Microsoft stellt mehrere Wege bereit, um von einem Quellsystem (Exchange 2003/2007/2010/2013/IMAP) in die Cloud zu migrieren. Diese Seite beschreibt exemplarisch die Herausforderungen für eine Migration von Notes nach Office 365. Viele der aufgeführten Aspekte sind aber unabhängig vom eigentlichen Quellsystem. Migrationen von Notes zu Exchange sind schon viele Jahre mein tägliches Brot und bis Exchange 2007 gab es sogar von Microsoft mit der TransporterSuite für Notes eine Lösung mit Bordmitteln zumindest Mails, Termine und Kontakte zu übertragen. Eine Migration in die Cloud stellt neue Herausforderungen, zumal Microsoft keine speziellen Tools für Notes bereit stellt. Wer also nicht mit dem IMAP4-Migrationsweg arbeiten will, muss sich nach Alternativen umschauen und die damit verbundenen Fragen zu klären.

Klärungsbedarf

Es gibt eine ganze Menge von Themen, die vor der Migration geklärt werden sollten:

Themenbereich Stichpunkt
Migrationstyp

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)
Migrationswerkzeuge

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.
Postfachinhalte

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.
Öffentliche Ordner

Mittlerweile können Sie mit Exchange Online sogar öffentliche Ordner betreiben und entsprechend auch von OnPremises 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 OnPremises-Postfächer und Outlook Clients nicht auf öffentliche Ordner in der Cloud zugreifen konnten.
  • 100GB Public Folder Datenbank
    Wie auch mit Exchange OnPremises 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 OnPremises hat, sollte Inhalte auslagern oder auf mehrere Ordner verteilen oder löschen.

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

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
Client

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.
Ausführung

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.
Weiterleitungen

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.

Das sind also schon ein paar Punkte, die beachtet werden wollen.

Bordmittelmigration

Es ist ja nicht so, dass Microsoft keine Migrationswerkzeuge für den Wechsel nach Office 365 bereithält. Die komplette Steuerung erfolgt über die Cloud und wird im Exchange Admin Center angestoßen. Natürlich kann dies auch per PowerShell erfolgen:

Für einige Migrationen ist er

Microsoft offeriert hier vier Verfahren, die sich recht einfach gegenüber stellen lassen:

Verfahren Max User Quelle Provisioning Ablauf Anmerkung

Cutover (CEM)

<2000

Exchange 2003
Exchange 2007
Exchange 2010
Exchange 2013
Exchange 2016

DirSync disabled !

  1. Tool legt Benutzer, Postfach, Verteiler, Kontakte an
    LegacyExchangeDN kommt mit!
    Neue Kennworte werden angelegt
  2. Sync des Postfach RPC/HTTP alle 24h
  3. MX Record umstellen
  4. User lizenzieren und Clients umstellen
  5. Finaler Sync
  6. Altsystem abschalten

Ordner und Mails
Regeln; Kategorien; OOF
Termine, Kontakte, Tasks
Delegates
max. 25MB/Mail
Kein Dumpster
Kein SendAs
Keine Dynamische DLs
Keine Sicherheitsgruppen
Keine UM-Mailboxen
OST wird neu generiert
Keine Public Folder
Es bleiben keine Postfächer On-Prem

Staged (SEM)

1000 pro Batch

Exchange 2003
Exchange 2007

DirSync legt Anwender an

  1. DirSync legt MailUser oder Mailbox an
  2. MX Record mit Routing via "mail.onmicrosoft.com"
  3. Einmaliger Sync des Postfach RPC/HTTP
  4. MX Record umstellen
  5. User lizenzieren und Clients umstellen
  6. Finaler Sync
  7. Altsystem abschalten

Siehe CEM
Nicht mit Exchange 2010/2013
Nur Mailrouting Koexistenz, kein F/B

Hybrid

50.000 ?

Exchange 2010
Exchange 2013
Exchange 2016

DirSync managed User

  1. DirSync legt MailUser oder Mailbox an
  2. Hybridmode mit SMTP-Connector und CAS Proxy
  3. User Lizenzieren
  4. "Remote Move" je Mailbox mit Sync und Switch
  5. Clients umstellen (Autodiscover)
  6. MX Record jederzeit umstellbar
  7. Altsystem abbauen

Beste Koexistenz
Lange Koexistenz
Kein Exchange 2003
Einschränkung bei Delegate
Keine Public Folder

IMAP (nur Mails)

Max 500.000 Elemente

IMAP
Notes
GroupWise
Google
Exchange 5.5-2013

Admin

  1. Anwender mit Postfach anlegen
  2. IMAP4 Replikation (alle 24h)
  3. MX-Record umstellen
  4. User lizenzieren und Client umstellen
  5. IMAP4 Schlussreplikation
  6. Altsystem abschalten

Max 500.000 Mails/User
Max 25 MB /Mail
keine Ordner mit "/" im Namen
Keine Kontakte
Keine Kalender
Keine Tasks

PST-Migration

 

Alles was Export in PST unterstützt

Admin

Benutzer überträgt manuell oder PST Import über Cloud o.ä.

PST Import wird gerne genutzt um Archive ohne Belastung des WAN in Office 365 übertragen.

Third Party

Je Produkt

Notes
GroupWise

Third Party

Je nach Produkt
  • Quest/Dell
  • BinaryTree
  • Bittitan
  • Audriga

IMAP, CEM und SEM haben keinen echten "Koexistenz"-Betrieb und sind darauf ausgelegt, möglichst schnell ein komplettes Quellsystem in die Cloud zu übertragen. Nur der Hybridmode ist real dafür geeignet, eine Koexistenz über Monate und länger aufrecht zu erhalten und Gruppen von Postfächern zu migrieren. Übrigens auch in beide Richtungen.

Ignite Webcast – understanding Simple Migrations.pptx
http://community.office365.com/cfs-file.ashx/__key/telligent-evolution-components-attachments/01-06-00-00-00-33-49-84/Ignite-Webcast-_1320_-Understanding-Simple-Migrations.pptx

Ignite Webcast - Cutover and Staged Migrations
https://www.youtube.com/watch?v=toGI1urCR4w

Einen "richtigen Hybrid-Mode" gibt es aber nur mit Exchange und Office 365. Wenn Sie mit diesen Produkten aber sehr viele Postfächer oder große Datenbestände migrieren, dann empfehlen die meisten  3d Party Tools einen von zwei Wegen:

  1. Switch nach 99% Migration
    Sie replizieren alle Postfachdaten erst einmal ins Ziel und wenn die zu 99,9% dort vorliegen, stellen Sie MX-Record und Clients um. Ein letzter Lauf holt die letzten Änderungen noch mal in das Ziel. So haben Sie einen Großteil der Daten schon im Ziel und können die Qualität schon mal abschätzen.
  2. Früher Switch mit Nachmigration
    Hierbei wird z.B. nur eine Teilmenge einmalig in das Ziel repliziert und stellen die User um. Diese haben dann nur eine leere oder teilgefüllte Mailbox. Die fehlenden Mails kommen durch eine Nachmigration hinterher. So können die Anwender ganz schnell die neuen Optionen nutzen und der alte Server ist quasi "Lastfrei" für die Migration

Beide Wege bedeuten aber, dass alle Benutzer entweder auf der alten oder neuen Plattform sind. Ein Mischbetrieb erfordert zumindest ein Routing und die Aktualisierung von Weiterleitungen auf Gegenseitigkeit.

Phasen

Eine Migration in die Cloud teile ich, mal abgesehen von Hybrid-Mode, in folgende Phasen auf:

Phase Aktionen
Analyse

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üsselungen. 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
Vorarbeiten

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)
Migration/Koexistenz

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

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

Diese Phasen wird man in der Regel als Projektplan mit Zuständigkeiten, Aufwänden und Zeiten dokumentieren und abhängig von der Größe und Komplexität unterschiedlich detailliert ausarbeiten.

Notes: MOMT und DIRPREP

Wer auf den Webseiten von Microsoft oder Office 365 nach Lösungen für Notes als Quelle sucht, wird zwar einen Bereich finden, der den Eindruck einer passenden Lösung erweckt, aber das Programm MOMTI ist ein Analysewerkzeug um einen Überblick der Elemente zu erhalten:

MONTI processes mail files to determine the total database size, document count (calendar, contacts, groups, mail, and tasks), and size by days. It also processes Mail-In Databases to determine the total database size, and Size by Days. MONTI results can be seen under the People, Mail-In Databases, and Logs views. Reports can be generated manually or scheduled.  
Quelle: Lotus Notes migration tools für Office 365 https://technet.microsoft.com/en-us/library/hh974319.aspx

Es ist aber kein Migrationstool, welches einen Mehrwert erlaubt. Die Microsoft für Notes als Quelle bleibt eine IMAP4-Migration oder der Einsatz von Dritttools

3rd Party Produkte

Neben der Migration mit Office 365 Bordmitteln gibt es einen ganzen Bulk von Drittprodukten zur Migration. Interessant sind solche Produkte natürlich immer, wenn die Lösung von Microsoft nicht ausreichend ist. Das ist insbesondere der Fall, wenn die Quelle z.B. Notes, GroupWise o.ä. ist und eine reine Mailmigration per IMAP4 nicht ausreicht oder sie bei der Migration Daten filtern wollen. Das reine Übertragen von Exchange nach Office 365 ist mit Bordmitteln eigentlich sehr ausgereift und auf jeden Fall einen Versucht wert. Fast alle Anbieter haben nicht nur ein Produkt, sondern mehrere Produkte für verschiedene Quellen und Betriebsarten.

Meine Übersicht ist sicher nicht komplett und ich erhebe nicht den Anspruch die Produkte auch nur halbwegs bewerten zu können:

Produkt + Link  Quelle Betriebsart Anmerkungen 

BinaryTree CMT:
http://www.binarytree.com/products/notes-to-exchange/cmt-for-exchange.aspx

Notes 

On-Prem
Eigenbetrieb

 

Binary Tree “managed”
http://www.binarytree.com/solutions/remote-migrations/remote-managed-migrations.aspx

Notes  

On-Prem
Remote managed

 

Binarytree Weekend Express
http://www.binarytree.com/solutions/remote-migrations/weekend-express.aspx
(repliziert Notes-NSF nach “Notes staging Server” um dann „CutOver“ zu migrieren)

Notes  

repliziert NSF auf Hosted Noes
Schnelle "Cutover" von Cloud Notes auf Office 365 

 

www.Cloudmigrator365.com
ca 10€/User

Notes 
GroupWiseIMAP
Exchange

On-Prem Software
Eigenbetrieb oder "Assisted"

auch Public Folder

Quest OnDemand Migration
http://software.dell.com/platforms/office-365/

Notes 
GroupWiseIMAP
Exchange 

Hosted 

 

MigrationWiz
https://www.bittitan.com/products/ 
https://community.bittitan.com/kb/Pages/How%20do%20I%20configure%20a%20Pre%20Stage%20migration.aspx 

 

Drei Optionen:

  • preStage: Zuerst werden Mails ältere 90/60/30 Tage übertragen und nach der Umstellung der User und MX werden die restlichen Mails samt Termine und Kontakte kopiert.
  • Single-Pass: MX-record wird umgestellt und dann alles auf einmal kopiert.
  • Quickswitch: Zuerst werden jüngere Elemente kopiert, dann MX und User umgestellt und alte Mails nachmigriert.

MigWiz synchronisiert also nicht.

 

Kernel Office 365 Migrator für Lotus Notes
http://www.nucleustechnologies.com/lotus-notes-to-office365.html  

 

On-Prem
Importiert anscheinend einfach NSF/PST-Dateien 

 

Die meisten der Programme migrieren Mails und je nach Quelle auch Kontakte, Termine und Tasks. Sie erwarten aber von Administrator, dass im Ziel die Postfächer schon vorliegen und meist eine CSV-Datei die zu migrierenden Postfächer und die Ziele vorgibt. Die Pflege von Weiterleitungen in der Quelle nach der Migration und im Ziel vor der Migration fehlt, so dass sie am Besten damit fahren, alle Benutzer zu einem Stichtag umzustellen.

Die "sanfte" Migration mit einzelnen Benutzern oder Abteilungen gelingt meist nur über einen Zwischenschritt On-Premises. Dann können aber auch leistungsfähige Tools für die klassische On-Prem-Migration (z.B. Quest oder BinaryTree) zum Einsatz kommen, die einen DirSync und sogar Free/Busy zwischen unterschiedlichen Systemen erlauben.

Achtung:“After you create a new mailbox, you must assign a license to it or it will be disabled when the grace period ends"

Weitere Links