OpenText Migrate
Punktgenau
Veröffentlicht in Ausgabe 06/2026 - TESTS
OpenText basiert im Kern auf der Technologie von Double-Take Move sowie Carbonite Migrate. Die Software repliziert laufende Systeme bytegenau und kontinuierlich auf den Zielserver, während der Quellserver produktiv bleibt. Der eigentliche Umschaltvorgang, der sogenannte Cutover, beschränkt sich auf wenige Minuten. Für diesen Test haben wir Version 8.5.10.0 in einer Hyper-V-Umgebung unter die Lupe genommen und verschiedene Migrationsszenarien durchgeführt.
| Produkt | Plattform für Live-Servermigrationen mit kontinuierlicher bytebasierter Replikation. |
|---|---|
| Hersteller | OpenText Corporation
|
| Preis | Lizenzierung pro Quellserver und der Einstiegspreis startet bei rund 320 Euro pro Server. Zielserver sind kostenfrei. |
| Systemanforderungen | Unterstützt werden die verschiedenen Betriebssysteme, wie CentOS, CloudLinux, Debian Linux, Microsoft Windows Server, Oracle Enterprise Linux, Red Hat Enterprise Linux, Rocky Linux und SUSE Enterprise Linux. Darüber hinaus werden verschiedenste Cloudanbieter unterstützt: Alibaba Cloud, Amazon Web Services (AWS), Google Cloud Platform, Microsoft Azure, Microsoft Hyper-V, VMware ESXi, VMware vCloud Director,VMware vSphere. |
| Technische Daten |
Byte-Replikation auf Kernelebene
Das technologische Alleinstellungsmerkmal von OpenText Migrate ist die patentierte bytebasierte Replikation auf Kernelebene. Viele Migrationswerkzeuge arbeiten mit Block- oder Dateiübertragungen und übermitteln dabei ganze Blöcke oder Dateien; OpenText Migrate agiert deutlich granularer. Die Software überträgt ausschließlich die tatsächlich veränderten Bytes – exakt in der ursprünglichen Schreibreihenfolge.
Gerade bei transaktionsintensiven Anwendungen ist dieser Ansatz entscheidend. Ein SQL-Server oder ein Exchange-Server schreibt Daten über mehrere Dateien hinweg in einer definierten Abfolge; OpenText Migrate stellt genau diese Reihenfolge auf dem Zielsystem identisch wieder her und sichert so die Konsistenz der Datenbanken. Klassische blockbasierte Werkzeuge können solche Abhängigkeiten nicht abbilden und riskieren inkonsistente Zustände am Zielsystem.
OpenText basiert im Kern auf der Technologie von Double-Take Move sowie Carbonite Migrate. Die Software repliziert laufende Systeme bytegenau und kontinuierlich auf den Zielserver, während der Quellserver produktiv bleibt. Der eigentliche Umschaltvorgang, der sogenannte Cutover, beschränkt sich auf wenige Minuten. Für diesen Test haben wir Version 8.5.10.0 in einer Hyper-V-Umgebung unter die Lupe genommen und verschiedene Migrationsszenarien durchgeführt.
| Produkt | Plattform für Live-Servermigrationen mit kontinuierlicher bytebasierter Replikation. |
|---|---|
| Hersteller | OpenText Corporation
|
| Preis | Lizenzierung pro Quellserver und der Einstiegspreis startet bei rund 320 Euro pro Server. Zielserver sind kostenfrei. |
| Systemanforderungen | Unterstützt werden die verschiedenen Betriebssysteme, wie CentOS, CloudLinux, Debian Linux, Microsoft Windows Server, Oracle Enterprise Linux, Red Hat Enterprise Linux, Rocky Linux und SUSE Enterprise Linux. Darüber hinaus werden verschiedenste Cloudanbieter unterstützt: Alibaba Cloud, Amazon Web Services (AWS), Google Cloud Platform, Microsoft Azure, Microsoft Hyper-V, VMware ESXi, VMware vCloud Director,VMware vSphere. |
| Technische Daten |
Byte-Replikation auf Kernelebene
Das technologische Alleinstellungsmerkmal von OpenText Migrate ist die patentierte bytebasierte Replikation auf Kernelebene. Viele Migrationswerkzeuge arbeiten mit Block- oder Dateiübertragungen und übermitteln dabei ganze Blöcke oder Dateien; OpenText Migrate agiert deutlich granularer. Die Software überträgt ausschließlich die tatsächlich veränderten Bytes – exakt in der ursprünglichen Schreibreihenfolge.
Gerade bei transaktionsintensiven Anwendungen ist dieser Ansatz entscheidend. Ein SQL-Server oder ein Exchange-Server schreibt Daten über mehrere Dateien hinweg in einer definierten Abfolge; OpenText Migrate stellt genau diese Reihenfolge auf dem Zielsystem identisch wieder her und sichert so die Konsistenz der Datenbanken. Klassische blockbasierte Werkzeuge können solche Abhängigkeiten nicht abbilden und riskieren inkonsistente Zustände am Zielsystem.
Dazu setzt OpenText Migrate einen Kerneltreiber auf dem Quellsystem ein, der alle Dateisystem-Operationen in Echtzeit abfängt und in einer internen Queue puffert. Den Inhalt dieser Queue überträgt die Software kontinuierlich zum Zielserver. OpenText Migrate verschlüsselt die Übertragung per AES-256-Bit und lässt sie über ein integriertes Bandbreiten-Management drosseln – das eröffnet Migrationen auch über WAN-Verbindungen oder in Produktionsumgebungen mit knapper Bandbreite.
Das Lizenzmodell orientiert sich konsequent an Quellsystemen: Für jeden Server, der als Migrationsquelle dient, fällt eine Lizenz an; Zielserver bleiben lizenzfrei. Für einmalige Migrationsprojekte ist das vorteilhaft, da die Lizenzkosten direkt von der Anzahl der zu migrierenden Systeme abhängen.
Für Evaluierungszwecke stellt OpenText zeitlich begrenzte Testlizenzen bereit. Im Test nutzten wir eine 5-Tage-Lizenz, die alle Funktionen der Vollversion umfasste. Laut Herstellerangaben beginnt der Listenpreis bei rund 320 Euro pro Quellserver; für größere Projekte bietet OpenText Volumenpreise über den Direktvertrieb oder zertifizierte Partner an. Ergänzend dazu bietet OpenText Migration-as-a-Service an. Das Unternehmen übernimmt dabei Migrationsprojekte vollständig oder in Teilen und verfügt nach eigenen Angaben über umfangreiche Projekterfahrung auch in komplexen Multi-Site-Umgebungen.
Flexibilität bei Quell- und Zielumgebungen
OpenText Migrate bezeichnet sich selbst als das Schweizer Taschenmesser der Migration – und das nicht ohne Grund. Als Quelle oder Ziel akzeptiert die Software jede Kombination aus physischer Hardware, Virtualisierungsumgebung und Public Cloud (Bild 1). Welche Umgebungen Version 8.5 konkret unterstützt, finden Sie in den Systemvoraussetzungen des Produktkastens.
Laut Hersteller befindet sich darüber hinaus die Unterstützung weiterer Hypervisor-Plattformen in der Entwicklung, darunter Proxmox. Gerade vor dem Hintergrund der VMware-Übernahme durch Broadcom und den damit verbundenen Lizenzänderungen dürfte das für viele Administratoren ein relevanter Punkt sein. OpenText Migrate unterstützt mehrere Migrationsszenarien, die sich je nach Anforderung kombinieren lassen:
- Full Server Migration: Das vollständige System – Betriebssystem, Anwendungen, Konfigurationen und Daten – wandert auf ein neues Zielsystem. Am Ende des Prozesses übernimmt der Zielserver die vollständige Identität des Quellservers.
- Data-only Migration: Nur die Daten werden repliziert; Betriebssystem und Anwendungen auf dem Zielsystem bleiben unangetastet. Dieses Szenario eignet sich etwa für Konsolidierungen oder Dateiserver-Migrationen.
- SQL Server Modernization: Ein spezialisierter Workflow ermöglicht die gleichzeitige Migration und das Versionsupgrade von SQL-Serverinstanzen. Die Datenbanken werden während der laufenden Replikation konsistent übertragen und erst beim Cutover an die neue Instanz angebunden.
- Full Server to Hyper-V / VMware: Über die native Integration mit den Hypervisor-APIs lassen sich physische oder virtuelle Quellsysteme direkt in eine neue VM überführen, ohne dass Sie die Ziel-VM vorab manuell vorbereiten müssen. Auf einem Ziel-Hyper-V-Host genügt die Installation von OpenText Migrate; bei ESX übernimmt eine als Virtual Recovery Appliance bezeichnete virtuelle Maschine diese Rolle.
Auf dem Quellserver muss stets der OpenText-Migrate-Agent installiert sein. Bei Hyper-V und ESX erstellt die Software die Ziel-VMs während der Migration automatisch. Grundsätzlich ist jedoch jeder Windows- oder Linux-Server als Zielsystem verwendbar – vorausgesetzt, der Agent ist installiert. Das verschafft Administratoren plattformübergreifende Migrationsmöglichkeiten, unabhängig davon, ob das Ziel On-Premises oder bei einem Cloudprovider liegt.
Die Flexibilität von OpenText Migrate erschließt eine breite Palette an Einsatzszenarien: Hardware-Refresh physischer Server auf neuer Hardware, Hypervisor-Wechsel, Rechenzentrumskonsolidierung, Modernisierung älterer SQL-Serverinstanzen sowie die Cloudmigration physischer oder virtueller Workloads zu Azure oder AWS. Die Plattform deckt damit ein breites Spektrum ab, ohne dass für jedes Szenario ein eigenes Werkzeug erforderlich wäre.
Onboarding und einfache Inbetriebnahme
OpenText vertreibt die Software sowohl über Partner als auch im Direktkundengeschäft. In der Praxis beginnt eine Evaluierung typischerweise mit einem strukturierten Onboardinggespräch, in dem Experten des Herstellers oder eines zertifizierten Partners die Grundkonzepte der Plattform erläutern – Architektur, Replikationsmechanismen und gängige Migrationsszenarien. Einen einfachen Download einer Testversion gibt es nicht; erst nach dieser Einführung erhalten Interessenten Zugriff auf Downloadlinks, Dokumentationen und zeitlich begrenzte Testlizenzen. Auch uns wurden die Unterlagen nach einer kurzen Vorstellung bereitgestellt. Für den Test stellte OpenText eine 5-Tage-Lizenz für fünf Quellsysteme zur Verfügung. Die Lizenzzeit startet mit der Aktivierung und dem Beginn des Migrationsprozesses.
OpenText Migrate besteht aus drei zentralen Komponenten: dem Double-Take-Dienst, der auf jedem Quell- und Zielserver installiert wird, der OpenText Replication Console als zentraler Verwaltungsoberfläche sowie dem Lizenzserver für die Aktivierung. Version 8.5.10.0 haben wir über den vom Hersteller bereitgestellten Link heruntergeladen. Für Windows-Umgebungen steht ein kombiniertes Installationspaket bereit, das Agent und Konsole gemeinsam enthält.
Auf Windows-Systemen setzt OpenText Migrate das .NET Framework 4.8 sowie die zugehörigen Visual-C++-Runtime-Pakete voraus; fehlen diese, installiert sie der Installer automatisch nach. Auf Linux-Rechnern müssen Administratoren die erforderlichen Abhängigkeiten vorab über den jeweiligen Paketmanager einspielen. Für ältere Betriebssystem-Versionen stellt der Hersteller auf Anfrage ältere Versionen von OpenText Migrate bereit.
Die Installation des Agenten auf unserem Windows-Server verlief im Test reibungslos. Der Setupassistent führte schrittweise durch den Prozess und zog fehlende Abhängigkeiten automatisch nach. Folgende Punkte verdienen bei der Installation grundsätzlich Beachtung:
- Dienstkonto: Der Double-Take-Dienst benötigt ein Konto mit lokalen Administratorrechten. Empfohlen wird ein dediziertes Dienstkonto, das Mitglied der lokalen Gruppe "Double-Take Admin" ist.
- Netzwerkkonfiguration: Der Agent kommuniziert standardmäßig über die TCP-Ports 6320, 6325 und 6326. Diese Ports müssen in der Windows-Firewall und gegebenenfalls in vorgelagerten Netzwerkfirewalls freigegeben sein.
- Windows Defender: Virenscanner-Ausnahmen für Defender lassen sich direkt über den Installer setzen.
Angestaubte Managementkonsole
Zentrale Verwaltungsoberfläche ist die OpenText Replication Console. Sie folgt dem klassischen Windows-Administrationsstil mit einer Baumstruktur links und der Detailansicht rechts – vertraut aus dem Windows Server Manager oder der MMC. Wer mit diesen Werkzeugen umzugehen weiß, findet sich schnell zurecht. Voraussetzung ist, dass die eingebundenen Server über das Netzwerk erreichbar sind. Im Test betrieben wir die Konsole auf einem separaten Managementclient.
Die Konsole deckt alle zentralen Verwaltungsaufgaben ab: Registrierung und Verwaltung von Quell- und Zielservern per IP-Adresse oder FQDN, Erstellung und Konfiguration von Migrationsjobs, Echtzeitmonitoring laufender Replikationsprozesse sowie Protokollverwaltung, Benachrichtigungskonfiguration und Lizenzverwaltung.
Der Funktionsumfang des Hauptmenüs ist überschaubar: Über die Bereiche "Server", "Jobs", "License Information", "Reporting Servers" und "Options" navigieren Administratoren durch die Oberfläche. Im Serverbereich lassen sich neue Server hinzufügen, deren Details einsehen und Logs prüfen; die linke Seite erlaubt bei Bedarf eine Gruppierung der Systeme, rechts erscheint die Gesamtliste. Ein Rechtsklick auf einen Eintrag öffnet ein Kontextmenü mit weiteren Aktionen – darüber haben wir im Test auch die Migrationsjobs angestoßen.
Das Jobpanel liefert auf einen Blick alle relevanten Statusinformationen: Quell- und Zielserver, Jobtyp, aktuelle Aktivität, Replikationsstatus, Sendemodus und Betriebssystem. Warnmeldungen hebt die Konsole mit einem gelben Warndreieck hervor (unten in Bild 2 zu sehen); in unserem Test wies dieses auf eine noch laufende initiale Synchronisation hin – kein kritischer Fehler. Die Oberfläche ist funktional, wirkt aber optisch eingestaubt. Wer moderne Webkonsolen oder cloudnative Dashboards gewohnt ist, muss sich hier umstellen.
Durchdachter Wizard mit sinnvollen Automatismen
Vor dem Anlegen eines Migrationsjobs registrierten wir zunächst Quell- und Zielserver in der Konsole. Dazu wählten wir in der Werkzeugleiste "Add Servers" und gaben IP-Adresse sowie die erforderlichen Credentials an. Der angegebene Benutzer muss auf dem Zielsystem Mitglied der Gruppe "Double-Take Admin" sein, sofern der Agent bereits installiert ist – diese Gruppe richtet der Installer bei der Agenteninstallation automatisch ein. Da wir den Agenten vorab auf unseren Testservern installiert hatten, wurden die OpenText-Migrate-Details direkt angezeigt. Bei einer größeren Serveranzahl lässt sich der Agent per Kommandozeile ausrollen; das genaue Vorgehen beschreibt die Dokumentation ausführlich. Alternativ erlaubt die Konsole die Agenteninstallation direkt aus der Oberfläche heraus, wenn ein Server ohne installierten Agenten hinzugefügt wird.
Nach der Registrierung wiesen wir den Quellservern eine Lizenz zu – Pflicht, bevor ein Job startet. Dies erfolgt in den Einstellungen des jeweiligen Servers; dort findet auch die Online-Aktivierung statt, die alternativ über die OpenText-Website möglich ist. Den neuen Job starteten wir über den Kontextmenü-Eintrag "Migrate" auf dem Quellserver. Im Wizard wählten wir den Migrationstyp "Full-Server-to-Hyper-V-Migration". In diesem Modus erkannte OpenText Migrate die vorhandene Hyper-V-Umgebung auf dem Zielhost automatisch und bot an, die passende Ziel-VM mit vorausgefüllten Parametern selbständig anzulegen.
Ablageort sowie Netzwerk- und Festplatten-Konfiguration ließen sich an dieser Stelle noch anpassen. OpenText Migrate ordnete jeden erkannten Netzwerkadapter des Quellservers einem virtuellen Switch des Hyper-V-Hosts zu. Zusätzlich bietet der Wizard eine IP-Remapping-Funktion, über die sich die Netzwerkidentität der Ziel-VM bereits vorab festlegen lässt: Sie definieren, ob die VM nach dem Cutover automatisch IP-Adressen, Subnetzmasken, Gateways und DNS-Server des Quellservers übernimmt oder ob abweichende Werte gelten sollen. Beim Festplatten-Layout übernimmt Migrate standardmäßig das vollständige Partitionslayout des Quellservers; einzelne Volumes lassen sich jedoch gezielt ausschließen.
In den erweiterten Jobeinstellungen steuern Administratoren das Replikationsverhalten im Detail. Für die Übertragung stehen Komprimierung, Verschlüsselung und Bandbreitenbegrenzung zur Wahl. Die Komprimierung senkt die Netzwerk- last, beansprucht dafür die CPU des Quellservers stärker und empfiehlt sich vor allem bei WAN-Verbindungen oder knapper Bandbreite. Die optionale AES-Verschlüsselung des Replikationstraffics ist überall dort sinnvoll, wo die Übertragung unsichere Netzwerksegmente durchquert.
Erstsynchronisation ohne Hindernisse
Der Replikationsprozess gliedert sich in zwei Phasen. Zunächst führt Migrate eine vollständige Erstsynchronisation durch – den sogenannten Mirror, bei dem alle Daten des Quellservers auf die Ziel-VM übertragen werden. Anschließend wechselte der Job automatisch in den kontinuierlichen Replikationsmodus: Ab diesem Punkt erfasst der auf Kernel- ebene arbeitende Double-Take-Treiber alle Schreiboperationen auf dem Quellserver und überträgt sie in Echtzeit auf das Zielsystem. Den Fortschritt können Administratoren in den Jobdetails live verfolgen; im Hintergrund sammelt das System Kennzahlen wie "Mirror remaining", "Bytes sent" oder die Größe der Replikationsqueue.
Während der initialen Synchronisation bleibt der Quellserver vollständig produktiv. Schreiboperationen, die in dieser Phase anfallen, puffert die interne Queue und zieht sie nach Abschluss des Mirrors nach. Je nach Datenmenge kann die initiale Synchronisation entsprechend Zeit beanspruchen.
Nach dem Abschluss der initialen Synchronisation zeigte das Jobpanel den Status "Replication" – das Signal, dass der Zielserver für einen Cutover bereitsteht. Ab diesem Punkt spiegelt das Zielsystem den Stand des Quellsystems kontinuierlich wider, mit einer Verzögerung von typischerweise wenigen Sekunden.
Solides Monitoring, aber schwaches Reporting
Jeder Job führt ein eigenes Protokoll, das alle Ereignisse chronologisch dokumentiert. Im Fehlerfall liefert es Fehlercodes und Hinweise zur Ursache; geführt wird es auf dem Zielserver. Ergänzend bietet OpenText Migrate eine proaktive Betriebsüberwachung per E-Mail. Die Benachrichtigungen konfigurieren Administratoren jedoch in den Serverdetails des jeweiligen Systems – eine zentrale Steuerung ist nicht vorgesehen. Pro Server hinterlegen Sie einen separaten SMTP-Endpunkt mit Zugangsdaten, wobei ausschließlich Basisauthentifizierung unterstützt wird. Benachrichtigungen lassen sich für Informationen, Warnungen und Fehler separat aktivieren.
Das Monitoring in der Konsole ist auf die operative Steuerung laufender Migrationsjobs ausgerichtet und erfüllt diesen Zweck zuverlässig. Ein Schnellfilter in der Statusleiste erlaubt es, Jobs mit Warnungen oder Fehlern direkt herauszufiltern – das ist praktisch für die schnelle Fehlernavigation, aber kein echtes Reporting. Eine konsolidierte Auswertung über mehrere Jobs oder Zeiträume, ein grafisch aufbereitetes Fortschrittsdashboard oder Werkzeuge zur Migrationsplanung fehlen. Für weitergehende Auswertungen existiert zwar ein separater Reportingservice, der in der Konsole jedoch als Legacy-Komponente geführt und separat installiert werden muss.
Non-Disruptive Testing: Ein entscheidender Unterschied
Eines der herausragenden Merkmale von OpenText Migrate ist das sogenannte Non-Disruptive Testing (NDT). Dieses Feature erlaubt es, das Zielsystem bereits vor dem finalen Cutover zu starten und vollständig zu testen, während der Quellserver unverändert produktiv läuft.
Nach Abschluss der initialen Synchronisation stießen wir über die Konsole den Test-Cutover an. Dabei startet die Ziel-VM in einer isolierten Netzwerk-umgebung – ohne den Quellserver zu beeinflussen oder IP-Adressen umzuschalten. Die VM ließ sich problemlos starten und einloggen; die Anwendungen auf unserem Testsystem funktionierten wie erwartet.
Treten dabei Probleme auf – fehlende Treiber, fehlerhafte Netzwerkkonfiguration oder Anwendungsfehler – lässt sich der Test-Cutover jederzeit abbrechen und der Zielserver zurücksetzen. Der Quellserver wird währenddessen durchgehend weiter repliziert, und der Test lässt sich nach Behebung der Probleme beliebig oft wiederholen. Diese Möglichkeit reduziert das Risiko eines fehlgeschlagenen Cut-over erheblich. In unserem Hyper-V-Test funktionierte sie tadellos.
Kontrollierter Cutover mit Rollback-Option
Der finale Cutover ist der Moment, in dem der Zielserver dauerhaft die Rolle des Quellservers übernimmt. In der Jobkonfiguration lässt sich der Zeitpunkt flexibel steuern. Im manuellen Modus verbleibt der Job nach Abschluss des Mirrors im Status "Protecting" und repliziert den Quellserver kontinuierlich weiter, bis der Administrator den Cutover explizit über die Konsole auslöst. Alternativ lässt sich die Umstellung so konfigurieren, dass sie unmittelbar nach der Synchronisation automatisch erfolgt.
Der Vorgang läuft in mehreren Phasen ab. Zunächst führt OpenText Migrate eine abschließende Synchronisation durch, bei der alle ausstehenden Änderungen aus der Replikationsqueue übertragen werden. Anschließend fährt die Software den Quellserver herunter und stoppt laufende Anwendungen, um einen konsistenten Abschluss zu gewährleisten. Das Zielsystem übernimmt daraufhin IP-Adressen, Computernamen und Systemidentität des Quellservers und ist nach einem Neustart unter der ursprünglichen Identität erreichbar.
Laut Hersteller liegt die typische Downtime bei einer vollständigen Full-Server-Migration bei rund 20 bis 30 Minuten. In unseren Tests fiel der Wert etwas höher aus – allerdings handelte es sich um eine kleine Testumgebung, die keine repräsentativen Rückschlüsse zulässt. Für den Fall, dass nach dem Cutover Probleme auftreten, bietet OpenText Migrate eine Rollback-Funktion, über die sich das ursprüngliche Quellsystem reaktivieren lässt. Bei uns verlief die Umschaltung in beiden Phasen – Non-Disruptive Testing und finaler Cutover – fehlerfrei.
Exchange und SQL konsistent migriert
Die Migration eines Exchange-Servers gehört zu den anspruchsvollsten Szenarien in Infrastrukturprojekten. Exchange verteilt Daten über Mailbox-Datenbanken, Transportprotokolle und Konfigurationsdaten und erwartet beim Start eine konsistente Datenbasis. In der Dokumentation fanden wir dazu keine konkreten Hinweise; auf Nachfrage beim Support bestätigte OpenText, dass Migrate Exchange-Umgebungen analog zu anderen transaktionsintensiven Anwendungen behandelt.
Die bytebasierte Replikation stellt sicher, dass alle Datenbankdateien in der korrekten Schreibreihenfolge auf dem Zielsystem ankommen. Im Test mit Exchange Server SE auf Windows Server 2025 verlief die Migration stabil. Nach dem Cutover stand der Exchange-Server auf dem neuen Hyper-V-Host ohne weitere Nacharbeiten sofort zur Verfügung.
Dasselbe gilt für SQL – auch das konnten wir im Test nachvollziehen. Der SQL-Server-Workflow in OpenText Migrate geht dabei über eine reine Full-Server-Migration hinaus. Die Software erkennt SQL-Instanzen auf dem Quellserver automatisch und bietet einen spezialisierten Migrationspfad mit Cross-Version-Unterstützung an: Eine Datenbank auf SQL Server 2012 lässt sich damit direkt auf SQL Server 2022 übertragen, ohne manuelles Backup-and-Restore.
Im Replikationsbetrieb überträgt OpenText Migrate Datenbankdateien und Transaktionslogs konsistent. Beim Cutover versetzt die Software die Quelldatenbank kurz in den Single-User-Modus, repliziert die finalen Transaktionen und hängt die Datenbank am Zielsystem ab und wieder an. Anwender erleben dabei lediglich einen kurzen Verbindungsunterbrechung während dieser abschließenden Synchronisationsphase. Diesen Workflow haben wir selbst nicht getestet, er bietet jedoch einen attraktiven Migrationspfad, der auf lange Wartungsfenster verzichtet.
Fazit
OpenText Migrate präsentiert sich im Praxistest als ausgereifte, zuverlässige Plattform für anspruchsvolle Servermigrationen. Die kontinuierliche bytebasierte Replikation – das technologische Herzstück der Double-Take-Technologie – hält Systeme während des gesamten Migrationsprozesses produktiv und reduziert die eigentliche Ausfallzeit auf ein Minimum.
Die Verwaltungsoberfläche ist funktional und deckt alle notwendigen Administrationsaufgaben ab, wirkt optisch aber angestaubt. Für Administratoren, denen Funktionalität vor Ästhetik geht, ist das kein Hinderungsgrund. Besonders überzeugend sind das Non-Disruptive Testing und die Flexibilität bei der Wahl von Quell- und Zielumgebungen. Wer ein Migrationsprojekt plant, erhält mit OpenText Migrate ein Werkzeug, das den Prozess kalkulierbar macht.
Für IT-Abteilungen, die vor einem Hardware-Refresh, einem Hypervisor-Wechsel oder einer Rechenzentrumskonsolidierung stehen, ist OpenText Migrate eine ernsthafte Option – erst recht, wenn die Alternative aufwändige manuelle Migrationsprojekte mit langen Wartungsfenstern wären.
(dr)
Installation und Setup |
7 |
Replikationstechnologie |
9 |
Non-Disruptive Testing |
9 |
Bedienbarkeit des UI |
6 |
Unterstützte Systeme |
8 |
|
Die Details unserer Testmethodik finden Sie unter https://www.it-administrator.de/testmethodik |
|