MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

3rd Party Migration mit CodeTwo

Auf dieser Seite beschreibe ich meine Erfahrungen einer Migration von Exchange OnPremises bei einem Hoster zu Exchange Online. Ich selbst hatte CodeTwo zur Migration vorher noch nie genutzt und der Hoster hatte damit angeblich bei anderen Kunden gute Erfahrungen gemacht.

Funktion als Kurzfassung

Die grundlegende Funktion von CodeTwo ist schnell beschrieben:

  • CodeTwo ist eine Windows Software, die ein Admin auf einem Windows Client installiert und ausführt.
    Also nichts in der Cloud oder Webserver
  •  CodeTwo migriert Inhalte aus Postfächern mittels MAPI, EWS, IMAP von einem bestehenden Quellsystem in ein Zielsystem
    Dabei gibt es eine initiale Migration und nachfolgende Delta-Migrationen.
  • Die Postfächer der Quelle liest CodeTwo aus dem AD aus oder per LDAP
    Ist nicht nicht möglich, z.B. IMAP4, Quelle nur per EWS erreichbar etc., dann kann eine CSV-Datei die benötigten Informationen liefern.
  • Die Postfächer im Ziel müssen vorhanden sein
    Hat CodeTwo die Rechte auf das Exchange Ziel, (OnPrem:Exchange PowerShell, Exchange Online: Graph), kann es auch Postfächer anlegen
  • Die Migration kann manuell oder über einen Zeitplan ausgeführt werden
    Aktiv ist dabei aber immer die CodeTwo Desktopsoftware, welche vom Administrator auf einem PC gestartet sein muss. Es gibt keinen "Dienst".
  • Der Umfang der Migration
    Sie können steuern, welche Elemente (Mail, Termine, Kontakte, etc.) und welche Ordner Migriert werden. Sie können zudem Mails "vor" oder "nach" einem Zeitpunkt beschränken aber keinen Zeitraum. Für eine Migration in mehreren Stufen reicht das aber aus.
  • Jobs und Gruppen
    Sie könne mehrere Migrationsjobs anlegen, die mehrere Postfächern enthalten. Es wird aber immer nur genau ein Migrationsjob gleichzeitig ausgeführt. Nur mehrere Postfächer innerhalb eines Jobs können parallel migriert werden. Das ist unschön, wenn eine Migration gerade läuft und sie ein einzelnes anderes Postfach außerhalb der Reihe migrieren wollen. Hier hilft dann nur eine Installation auf einem zweiten Server.

Aus meiner Sicht ist CodeTwo ist damit erst einmal ein einfaches „Copy“-Werkzeug, welches mit geringem Aufwand und Komplexität die Inhalte zwischen Exchange und IMAP4-Umgebungen übertragen kann, was auch nicht wirklich verschwiegen wird:

“Migrationen von Exchange Server erfolgen durch die Verbindung mit einem Quellserver und einem Microsoft 365-Zieltenant über Exchange Web Services (EWS). Die Verbindung zu einem älteren Exchange-Quellserver (z. B. Exchange 2010 ohne SP1) ist auch über ein dediziertes MAPI-Profil möglich. Auf diese Weise kann CodeTwo Office 365 Migration den Inhalt von Postfächern auf Ihrem Quellserver lesen und in die Postfächer in Exchange Online kopieren“
CodeTwo Office 365 Migration | FAQ https://www.codetwo.de/office-365-migration/faq

Umgebung

Diese Migration war dahingehend besonders, dass die Quell kein lokaler Exchange Server mit Domain war, über welchen CodeTwo sich die Daten aus den Benutzern beziehen konnte, sondern die Quelle war ein "Hosted Exchange", auf den der Kunde nur sehr eingeschränkten Zugriffe hatte. Er konnte mit einem Dienstkonto quasi nur per EWS an alle Postfächer zugreifen. In der Konstellation kann CodeTwo leider nicht selbst die Informationen über die Quelle ermitteln, sondern benötigt eine CSV-Datei mit den Informationen über die Quelle und das Ziel. Der Hoster der Quelle hat dazu eine Liste der Benutzer samt Mailadressen und MailboxGUID geliefert.

Das Ziel war Microsoft 365 mit Exchange Online, in dem die Benutzer alle schon per ADSync angelegt wurden und mit einer Exchange Lizenz hatten Sie auch zugleich ein noch leeres Exchange Postfach. Da der MX-Record noch zum Hoster verwiesen hat und auch alle Benutzer noch dort gearbeitet haben, ist das nicht weiter aufgefallen.

Achten Sie als Admin aber dennoch darauf, dass kein Benutzer per "Plug and Play" vielleicht schon das neue leere Postfach nutzt.

Die Migration sollte dann CodeTwo in drei Schritten übernehmen.

  • CodeTwo kopiert initial alle Inhalte nach Exchange Online
  • CodeTwo aktualisiert das Ziel mittels Delta-Migration
  • Umschaltung des MX-Records und der Anwender zu einem bestimmten Zeitpunkt

Es war nicht geplant, dass Anwender in Gruppen umgestellt werden und damit eine Koexistenz in zwei Organisationen aufgebaut werden muss. Soweit war die Planung in Ordnung.

Migration

Allerdings hat sich die Migration dann doch etwas verzögert, weil z.B. noch nicht alle Clients aktuell genug waren, die Sommerferien dazwischen gekommen sind. Sicher kennen Sich auch Gründe, warum Migrationen sich verzögern. Die Mailboxmigration, oder genauer das Kopien wurde im Mai gestartet aber die Umschaltung erfolgte dann doch erst im August. Nehmen wir mal folgende Zeitachse an.

  • 1. Mai: Start der initialen Migration
    Es wurden die neuen leeren Postfächer im Ziel angelegt und dann über CodeTwo Migrationsjobs die Daten aus der Quelle per EWS ausgelesen und ins Ziel per EWS geschrieben. Der Prozess hat einige Tage gedauert, was nicht ungewöhnlich ist. Die Migration von Einzelelementen per EWS über Export/Import schafft je nach Standort des Servers, Anzahl und Größe der Mails ca. 50-500kByte/Sek.
  • nach 1. Mai bis 1. August
    In der Zwischenzeit bis zur Umschaltung gibt es natürlich weitere "Änderungen" in der Quelle. Anwender lesen Mails (Status ungelesen->gelesen), löschen Mails oder verschieben diese in andere Ordner, Ändern Termin o.ä. CodeTwo nutzt dazu eine "Delta-Migration", welche Änderungen aus der Quelle ins Ziel übertragen. Die Erwartung eines Administrators und Benutzer ist natürlich, dass diese Änderungen bei einer Delta-Migration auch übertragen werden. Auf die Details komme ich gleich noch.
  • 1. August - Cutover, Clients und MX-Record
    Da es relativ wenige Benutzer waren, wurde zum Stichtag der MX-Record auf die neue Umgebung umgestellt und alle Anwender informiert, dass Sie Outlook und Mobilclients neu einrichten sollten. Sie finden dann alle Mails der Quelle dank CodeTwo im Ziel wieder. Neue Mails landen im Ziel und wenn noch Mails im alten System landen, dann holt die weiterhin laufende Delta-Migration diese Mails auch noch ins Ziel.

Soweit sieht das alles nach einem geeigneten Plan aus. Sicher sollte ich als Administrator auch noch sicherstellen, dass während der Migration kein Benutzer schon sich mit dem Ziel verbindet. Das passiert schnelle als sie denken, denn Outlook 365 macht zwar weiterhin eine Exchange - Autodiscover-Abfrage aber prüft parallel auch Autodiscover 365 und wenn es ein Exchange Online Postfach finden, dann verbindet er sich damit. Wohl dem, der z.B. mit Conditional Access/Azure Conditional Access den Zugriff für Anwender noch unterbunden hat.

Zum Stichtag der Umstellung sollten Sie natürlich den Zugriff auf das Ziel freigeben aber nun den Zugriff auf die Quelle für Anwender unterbinden. Sie müssen übrigens die Clients manuell konfigurieren, da CodeTwo keine "TargetAddress" auf der Quelle setze und damit auch kein Autodiscover Redirect ermöglicht.

Probleme

Allerdings wurde recht schnell deutlich, dass irgendetwas nicht stimmt. Mitarbeiter haben sich beschwert, dass:

  • Schon gelesene Mails wieder ungelesen waren
  • Bereits verschobene Termine wieder am alten Zeitpunkt aufgetaucht sind
  • Längst gelöschte Mails wieder vorhanden waren.
  • Aktualisierte Kontakte wieder den alten Stand hatte.

Das war dann in der Menge doch unerwartet und bedurfte einer genaueren Analyse, was die Migration leisten kann.

CodeTwo Delta-Migration

Wir hätten gewarnt sein können, denn CodeTwo beschreibt auf ihrer Webseite durchaus, was CodeTwo unter eine "Delta-Migration" versteht.

Die grundlegende eingeschränkte Funktion ist auch bei CodeTwo dokumentiert.

Yes, the program has a built-in feature to perform delta migrations. It can be used once the migration process is finished to check whether there are any new items on the source server and migrate them to the target server. Those items that have already been migrated, even if some changes were made to them on the source server, will not be migrated again.
Understanding the program - Migration | CodeTwo Office 365 Migration User's manual https://www.codetwo.com/userguide/office-365-migration/migration.htm

Wer genau liest, hätte es wissen können. Der Begriff "delta migration" ist meiner Ansicht dennoch irreführend, denn es ist eher ein "XCOPY /Newelement" oder inkrementelle Migration. CodeTwo liest bei der Migration alle Elemente aus der Quelle und merkt sich in einem lokalen Cache. Bei folgenden Läufen wird nur noch geprüft, ob das Element schon früher migriert wurde. Wenn das Element schon einmal migriert wurde, dann wird es nicht mehr übertragen. So kann CodeTwo zuverlässig verhindern, dass Elemente mehrfach als Dubletten migriert werden. Allerdings werden Änderungen in der Quelle damit auch nicht berücksichtigt. Ich habe meine Erkenntnisse einmal als Stichpunkte zusammengefasst:

  • InitialSync kopiert alle Mails aus der Quelle ins Ziel
    Dabei merkt sich CodeTwo in einer lokalen Datenbank, welche Mails es schon migriert hat, um Dubletten zu verhindern
  •  DeltaSync kopiert nur Elemente aus der Quelle ins Ziel, die noch nicht in der Datenbank liegen.
    Bereits migrierte Elemente werden nicht mehr migriert, selbst wenn diese geändert wurden. Das hat umfangreiche Auswirklungen:
    Löschen in der Quelle -> wird im Ziel NICHT entfernt
    Änderung in der Quelle -> Wird im Ziel NICHT aktualisiert, z.B. geänderte Termine, „Gelesen“-Status von Mails etc.
    Verschobene Elemente werden im Zielordner als neu erkannt -> Dubletten
    Mehr Details finden wie weiter unten.
  •  Bei Nutzung eines Zeitfilters scheint CodeTwo nur die Übersicht der Mails vom Quellserver abzurufen
    Das ist schneller, als alle Mails zu lesen und auf dem Client zu filtern. Im Protokoll ist aber zu sehen, dass CodeTwo auch die nicht benötigten Mails sieht und auf dem Client ausfiltert, ehe er dann die zu migrierenden Mails komplett lädt und überträgt. CodeTwo scheint mit EWS weder die serverseitigen Filter noch die DeltaSync-Funktion zu nutzen.
  •  Ein „Rücksetzen“ der Migration ist pro Postfach möglich
    CodeTwo löscht dann den lokalen Cache des Postfachs und migriert alle Elemente, die laut Konfiguration (Elemente, Ordner, Zeit) migriert werden sollen, erneut -> Sie erhalten Dubletten im Ziel, wenn Sie das Ziel nicht vorher geleert haben. (Siehe auch Clean-Mailbox)

Zu einer Migration gehören aber natürlich noch mehr Aufgaben als nur ein COPY der lesbaren Inhalte von Postfächern. Was passiert mit den Proxy-Adresses, kann CodeTwo auch Mailverteiler synchronisierne oder zumindest übertragen, Was passiert mit Regeln, Berechtigungen, Abwesenheitsassistenten etc?

CodeTwo Testfälle

Ich beschränke mich bei der Tabelle auf die Inhaltsmigration. Fragen zur Verwaltung der Postfächer, ihrer Eigenschaften und Mailverteilern sind hier nicht abgedeckt. Die Tabelle gibt meine Ergebnisse vom September 2025 wieder und berücksichtigt daher keine neueren Versionen oder Funktionen des Produkts.

Fall Szenario Ergebnis Status

1

Quelle: Neues Element (Mail, Termin, Kontakt)

Werden beim Fullmigration und inkrementellen Migrationen übertragen

OK

2

Quelle: Mail löschen

In der Quelle gelöschte Mails werden im Ziel nicht gelöscht! Wurde die Mail in der Quelle nach "Gelöschte Objekte" verschoben und ist der Ordner in der Migration eingeschlossen, dann wird diese migriert, d.h. ist dann doppelt im Postfach.

Unschön

3

Quelle: Mail ändern (z.B. Gelesen/Ungelesen/Kennzeichnung)

Gelesen/ungelesen und Kennzeichnen werden nicht

Fehler

4

Quelle: Mail in anderen Ordner verschieben

Objekt wird im neuen Ordner neu migriert aber am alten Platz im Ziel nicht gelöscht.

Unschön

5

Quelle: Termin verschieben (Zeitpunkt)

Geänderte Termine werden nicht im Ziel aktualisiert

Fehler

6

Quelle: Termin löschen

Die Termine wurden im Ziel nicht gelöscht

Fehler

7

Ziel: Termin löschen

Der in der Quelle weiter vorhandene Termin wird nicht mehr neu migriert

Fehler

8

Quelle: Kontakt Neu

Kontakt wird übertragen, ggfls. in anderem Kontaktordner

OK

9

Quelle: Kontakt ändern (Rufnummer)

Kontakt wird nicht aktualisiert

Fehler

10

Quelle: Kontaktgruppe mit Kontakt + GAL Kontakt

Werden samt aller Mitglieder übernommen aber Mitglieder aus der GAL erscheinen z.B. mit dem LegacyExchangeDN als Adresse und sind damit nur nutzbar, wenn Sie auch die Benutzer mit X.500 Adresse mit kopieren

OK

11

Quelle: Ordner umbenennen

Order wird neu ins Ziel kopiert. Bestehender Ordner im Ziel bleibt erhalten. Datendopplung kann durch Anwender gelöscht werden.

Unschön

12

Ziel: zusätzliche Mail empfangen

Mail bleibt erhalten und Anwender sieht sie nach dem Umschalten, da eine Umleitung mittels TargetAddress nicht durch CodeTwo gesetzt wird

Unschön

13

Ziel: Ordner umbenennen und in der Quelle eine Mail darin ändern

Der umbenannte Ordner wird komplett neu kopiert. Bestehender Ordner im Ziel bleibt erhalten. Datendopplung kann durch Anwender gelöscht werden.

Unschön

14

Sprachkonflikt: Quelle "Posteingang" und Ziel "Inbox"

 

noch nicht getestet

15

Posteingangsregeln

Werden nicht übertragen

Unschön

16

Out of Office Einstellungen

Wird nicht übertragen

Unschön

17

Signatur

Wird nicht übertragen

Unschön

18

Berechtigungen auf Ordner

Werden nicht übertragen

Unschön

19

Berechtigungen auf Postfach

Werden nicht übertragen

Unschön

20

Benutzer/Postfächer im Ziel anlegen, Lizenzen, Mailadressen, Quotas etc. verwalten

Nicht getestet

21

Verteiler/Mitgliedschaften im Ziel anlegen/verwalten

Nicht getestet

 

22

TargetAddress für Koexistenz/Umschaltung setzen

Nicht getestet

 

Migrationsüberlegungen

Mit dem Wissen um die Funktionsweise und Einschränkungen sehe ich eigentlich nur zwei mögliche Migrationen:

  • Switch und Nachmigration
    Sie legen die User im Ziel an, stellen den MX-Record und alle Benutzer um und nachdem in der Quelle sich nichts mehr ändert, kopieren Sie alle Elemente einmalig nach. Da darf natürlich nichts schief gehen und die Anwender warten einige Zeit, bis ihre Mails nachkommen. Sie können das etwas entschärfen, indem Sie nach dem Switch erst einmal alle Termine, Kontakte Aufgaben migrieren und z.B. die Mails der letzten 30 Tage. Die älteren Mails kann man dann später nachmigrieren.
  • Altdatenmigration, Switch, Restmigration
    Eleganter finde ich den Weg, vorab schon einmal ältere Informationen, die vermutlich nicht mehr geändert werden, ins Ziel zu übertragen. Nach der Umstellung der Clients werden dann die letzten Informationen in relativ kurzer Zeit noch nachmigriert. So haben die Anwender nur kurze Zeit eine Lücke und vor allem kann ich relativ sicher sein, dass die grundlegende Migration funktioniert.

Bei beiden Wegen wird jede Mail aber nur einmal migriert, damit keine Dubletten angelegt werden

Um die oben beschriebenen Probleme zu heilen, habe ich per PowerShell und Graph bei den Anwendern nach Rücksprache die Mails der der letzten 30-90 Tage gelöscht und dann in CodeTwo dann erneut die Mails mit einem "Reset der Migration" und einem "Neuer als"-Zeitfilter erneut migriert. Die Handarbeit und Verzögerung hat natürlich einiges an Zeit gebraucht und sollte nicht der Regelfall werden.

CodeTwo Feedback

Es dürfte nicht schwerfallen, die Einschränkungen von CodeTwo erkannt zu haben und entsprechend hätte ich ein paar Vorschläge an CodeTwo, um die Leistung doch deutlich zu verbessern:

  • DeltaSync mit Änderungen
    Wenn eine Migration nicht die Quelle "einfriert" und wir Änderungen übertragen müssen, dann muss dies ein richtiger Sync sein. CodeTwo merkt sich heute schon zu jedem Element eine Information, ich vermute die ObjectID, um Dubletten zu vermeiden. CodeTwo müsste sich einfach noch das "LastModified"-Date merken um auch Änderungen zu erkennen. Wenn es sich dann auch noch Die ObjectID und dessen Datum im Ziel merkt, könnte es auch Bestandselemente erkennen und aktualisieren/ersetzen. Das ist meine Mindestforderung, wenn ich CodeTwo jemand verwenden würde
  • Echter DeltaSync
    Um jedoch Verschiebungen von Objekten in andere Ordner, Umbenennungen von Ordnern oder sogar Löschungen zu erkennen, müsste CodeTwo entweder die die EWS, IMAP und Graph vorhandenen Funktionen nutzen, um einen SyncStatus zu ermitteln oder Quelle und Ziel besser vergleichen. Das macht Exchange bei seiner Bordmittelmigration aber auch andere Tools wie CodeTwo, Quest etc. sind hier auch noch nicht perfekt.
  •  CSV-Definition der User
    CodeTwo kann Postfächer per LDAP aus einem AD extrahieren. Das gelingt aber nicht bei Hosting mit reinem EWS-Zugriff und bei IMAP4 schon gar nicht. Dennoch könnte CodeTwo per EWS die GAL auslesen und anhand dieser Daten das Ziel provisionieren oder matchen.
  • Achtung: CSV-Löschung beim Einrichten
    Wer bei CodeTwo ist nur auf die Idee gekommen, eine importierte CSV-Datei danach zu löschen? Oft steckt viel Arbeit in der Erstellung und kein Admin erwartet diesen Schritt. Vielleicht will man die Datei ja noch ein zweites Mal verändert verwenden.
  • Parallele Ausführung
    Es kann wohl immer nur ein Migrationsjob aktiv sein. Damit ist es nicht möglich, neben dem geplanten Job z.B. einen weiteren Job für einen einzelnen Benutzer zu starten. Ich müsste einen zweiten CodeTwo-PC aufsetzen. Ich würde jede einzelne Postfach-Migration individuell betrachten und ein Migrationsjob eher als Gruppe mit einer Konfiguration definieren, die von der eigentlichen Migrationsengine dann angewendet wird
  •  Kein Zeitraum, sondern nur bis oder ab
    Bei der Filterung der zu migrierenden Objekte kann nur „Bis zum“ oder „nach dem“ als Datum angegeben werden. Ein Zeitraum ist nicht möglich. Ich kann also nicht einfach mal sage, dass CodeTwo eine bestimmte Woche oder sonstigen Bereich erneut kopieren soll.
  •  Zeitpunkt nur mittels „Received” statt „Last Modified”
    Die Beschränkung auf die Zeit orientiert sich nur am „Received“-Datum, d.h. wann das Element in Exchange erstmals „angekommen“ (Mail gesendet oder empfangen, Termine und Aufgaben wurden erstmals angelegt). Hier wäre zumindest eine Option auch ein „LastModified“-Feld zu nutzen um Änderungen zu erkennen und zu kopieren samt Entfernen eines Doppels im Ziel viel leistungsfähiger. Dann müsste nur noch die Dublette im Ziel verhindert werden
  •  Switch Support, TargetAddress/Umleitung
    Während der Migration in die bestehenden Zielpostfächer muss sichergestellt sein, dass sich kein Anwender dort anmeldet und Mails an diese Postfächer weiter an die Quelle umgeleitet werden.
    Nach dem Switch sollten Anwender nicht mehr die Quelle verwenden und Mails an die Quelle ins Ziel umgeleitet werden. CodeTwo unterstützt hier weder das Aktivieren/Deaktivieren von AD-Konten noch das Setzen/Entfernen einer Weiterleitung, z.B. über eine TargetAddress oder Weiterleitungen. Gerade die TargetAddress wäre interessant, um z.B. Autodiscover oder neue Mails in das aktuell aktive Postfach umzuleiten.
  • Besserer Provisioning-Support
    CodeTwo kann im Ziel die Postfächer anlegen, aber nicht in Verbindung mit CSV-Dateien. Ich sehe keinen Grund, warum dies nicht möglich sein könnte. Über Graph, Exchange PowerShell oder LDAP sollte es auch bei der Migration von IMAP oder Exchange Hosting per EWS doch möglich sein, alle Belange der Zielobjekte zu verwalten. Dies wäre insbesondere für das Feld TargetAddress bei Exchange wichtig, damit z.B. Mails immer zum aktiven Postfach gelangen und der Client per Autodiscover umgelenkt wir

Es gibt sicher noch andere Punkte aber diese Wünsche haben anderen Produkte schon lange realisiert.

CodeTwo, ADSync und IsExchangeCloudManaged

Wer Exchange OnPremises hat und möchte nach Exchange Online, der kann in den allermeisten Fällen einfach mit Bordmittels einen Verzeichnisabgleich (ADSync / AADConnect) und Exchange Online - Hybrid (Minimum Hybrid mit Modern Hybrid reicht) einrichten und dann Postfächer einfach in die Cloud migrieren, sauber per Delta-Sync aktuell zu halten und eingehende Mails mittels TargetAddress korrekt zuzustellen.

Dennoch durfte ich kurz nach meinem ersten Migrationstroubleshooting in einem weiteren Fall unterstützt, wo ein Dienstleister eine lokale Exchange Installation mit CodeTwo zu Exchange Online migriert hat. In der Umgebung war ebenfalls ein ADSync installiert, was mich dann erst einmal irritiert hat, denn bei korrekter Konfiguration mit Replikation der Exchange Properties sollte jeder Anwender mit einem lokalen Postfach dann in Exchange Online als "MailUser" und nicht als Mailbox definiert sein. Zudem sind Felder wie "ProxyAddresses" in Exchange Online aufgrund des aktivierten Verzeichnisabgleich nicht schreibbar. Ich habe das extra getestet und konnte mit der Exchange Online PowerShell einen MailUser nicht auf eine Mailbox umstellen.

Enable-Mailbox: Ein Azure Active Directory-Aufruf wurde ausgeführt, um die Synchronisierung eines Objekts zwischen Azure Active Directory und Exchange Online aufrechtzuerhalten. Dabei ist jedoch ein Fehler aufgetreten. Detaillierte Fehlermeldung: Unable to update the specified properties for on-premises mastered Directory Sync objects or objects currently undergoing migration. DualWrite (Graph)

Ich konnte den MailUser zu dem Zeitpunkt auch nicht mit IsExchangeCloudManaged abkoppeln, denn den Parameter gibt es nur bei Set-Mailbox. In der Umgebung musste es also über einen anderen Weg gelungen sein, ein Doppelpostfach mit Exchange Online zu konfigurieren um dann mit CodeTwo die Inhalte von den Postfächern auf dem lokalen Exchange Server zu Exchange Online zu kopieren.

Wie ich im nachhinein erfahren habe, wurden die User in der Cloud neu als CloudOnly-User ohne ADSync angelegt.

Auf jeden Fall ist das nicht das empfohlene Vorgehen und bedeutet viel mehr Handarbeit, Fehler und die Einschränkungen einer Migration mit CodeTwo, die ich oben schon beschrieben habe, gelten weiter. Eine Migration von Exchange OnPremises zu Exchange Online mit aktiviertem ADSync kann mit CodeTwo nicht funktionieren. Das muss es aber nicht, denn die Bordmittel von Exchange Online sind für diese Fälle ausgereift, schnell und kostenlos.

Wenn Sie Exchange Umgebungen migrieren wollen und sich unsicher bei der Wahl des Weges sind oder auch nur eine zweite Meinung benötigen, dann können Sie uns gerne ansprechen
Net at Work

Einschätzung

CodeTwo ist ein klassisches Migrationsprogramm der alten Schule. Es wird als Windows Desktop-Applikation auf einem PC des Migrationsadministrators installiert, verbindet sich mit Quelle und Ziel und kopiert die Daten. Es hat dabei aber einige Einschränkungen, die sie kennen sollten. Es kommt nicht an leistungsfähigere Migrationstools heran, die eine echte Delta-Synchronisation leisten oder sich auch um das Provisioning von Benutzer vor der Migration und beim Umschalten nach Abschluss der Migration kümmern. Hier bin ich von den Microsoft Tools, mit denen Postfächer nicht nur zwischen lokalen Exchange Servern sondern auch zwischen OnPremises Organisationen oder natürlich zu/von Exchange Online verschoben werden, mehr gewohnt. Selbst die IMAP4 Migration mit Exchange Online leistet hinsichtlich des Delta-Abgleichs deutlich mehr.

Wenn ich meine jahrzehntelange Erfahrung bei Migrationen anschaue, dann finde nur nur ganz wenig Sonderfälle, in denen ich CodeTwo Migration überhaupt einsetzen könnte. Selbst dann würde ich alles tun, um die Inkonsistenzen bei der Delta Migration zu minimieren, z.B. indem die Benutzer mit einem leeren Postfach im Ziel anfangen und die Mail nach migriert werden oder ich über ein "Staging" gehe, z.B. indem ich vorab nur Mails kopiere, die älter als 30-90) Tage sind und Benutzer daran kaum etwas ändern und nach dem Schwenk dann die fehlenden neueren Mails, Termine, Kontakte und Aufgaben nachhole. Bei all dem müssen die Benutzer natürlich informiert sein.

Allerdings sind andere Produkte hier schon deutlich weiter und gibt es als Cloud-Lösung, so dass gerade Migrationen zwischen Tenants oder unterschiedlichen Hostern viel einfacher, schneller und günstiger möglich sind, als der Eigenbetrieb eines lokalen Servers oder einer VM in Azure, AWS o.ä. Damit bleibt CodeTwo Migration eine Option für rein lokale Migrationen, bei denen die Server auch nicht aus der Cloud erreichbar sind und keinerlei Bordmittel funktionieren. Ich weiß nicht, wie die Roadmap von CodeTwo in der Zukunft für die Migration aussieht aber die schwache Qualität der Delta-Migration hat mich schon erschrocken

Weitere Links