Migrationsprozess Schritt für Schritt

Diese Seite führt Sie vollständig durch den Migrationsprozess zur Lobster Cloud: von den Voraussetzungen in Ihrer bestehenden On-Premise-Umgebung über den Profiltransfer bis zum Go-Live mit Ihren Kunden und Partnern.

Übersicht

Phase 1: On-Premise Vorbereitung

Warum ist das so wichtig?

Der Transport Manager setzt voraus, dass Quell- und Zielsystem innerhalb desselben Major Releases betrieben werden. Eine Migration von einer veralteten Version ist grundsätzlich möglich, macht den Prozess jedoch unnötig aufwändig. Die klare Empfehlung lautet daher: Bringen Sie Ihre On-Premise-Umgebung vor der Migration auf den aktuellen Versionsstand.

Lobster unterstützt Sie: Wenn Sie Unterstützung beim Upgrade Ihrer On-Premise-Umgebung benötigen, wenden Sie sich an Ihren Lobster-Ansprechpartner.

Versionsanforderungen

Alle Details zum Upgrade-Pfad und bekannten Besonderheiten finden Sie unter One-Click-Migration von älteren Systemen.

Upgrade-Strategie: Test vor Produktion

Führen Sie Upgrades immer zuerst in Ihrer Testumgebung durch und validieren Sie diese vollständig, bevor Sie Ihr Produktivsystem aktualisieren. Was dabei zu beachten ist und welche Schritte vor jedem Upgrade zwingend durchgeführt werden müssen, beschreibt die Checkliste zur Upgrade-Vorbereitung im Detail.

Migrationsstrategie festlegen

Entscheiden Sie frühzeitig, ob Sie alle Profile auf einmal migrieren oder Kunden und Partner schrittweise im Parallelbetrieb auf das neue System umstellen möchten. Eine schrittweise Migration reduziert das Risiko und ermöglicht einen kontrollierten Go-Live pro Kunde oder Partner.

Sonderfall: Eigene Datenbanktabellen, Ordner und eigene Klassen

Der Transport Manager überträgt ausschließlich Lobster-Konfigurationsobjekte wie Profile, Partner und Konfigurationsdateien. Wenn Sie in Ihren Datenbanken Tabellen betreiben, die kein offizieller Bestandteil der Lobster Software sind (z. B. eigene Lookup-Tabellen oder Stammdaten), müssen Sie für die Migration dieser Daten einen eigenen Weg finden, zum Beispiel über speziell entwickelte Profile. Das gilt auch für Ihre eigenen Ordner.

Das Gleiche gilt für alles, was Sie selbst im Dateisystem ergänzt haben: JAR-Dateien im Ordner extlib, Ihre eigenen Java-Klassen (Integration Units, Cron-Klassen, Antwortweg-Klassen, Preparser, Postexecuter) sowie Dateien, die Ihre Profile zur Laufzeit lesen. Der Transport Manager überträgt diese Dateien nicht. Ein Profil, das eine eigene Klasse verwendet, wird ohne Fehler übertragen und startet auch in der Cloud. Es scheitert erst zur Laufzeit, sobald die Klasse fehlt. Notieren Sie deshalb vor der Übertragung jede eigene Bibliothek und Klasse mit ihrem genauen Pfad und den Profilen, die sie verwenden.

Mit dem Upgrade auf die aktuelle Plattform-Version wechselt auch die Java-Laufzeitumgebung. Kompilieren Sie Ihre eigenen Klassen entsprechend neu, aktualisieren Sie deren Abhängigkeiten und prüfen Sie die JDBC-Treiber, bevor die Java-Version wechselt. Details finden Sie unter Platform update guide und den zugehörigen Unterseiten, insbesondere JDBC driver compatibility assessment.

 HINWEIS:

Sprechen Sie eigene Tabellen, Ordner und eigene Klassen früh mit Ihrem Lobster-Ansprechpartner ab, damit der Aufwand in die Migrationsplanung einfließt. Eigene Java-Klassen bleiben in Ihrer Verantwortung, einschließlich der Anpassung an eine neue Java-Version. Siehe Third-party software policy.

Phase 2: Versionssynchronisierung während der Migration

Während der gesamten Migrationsphase müssen Ihre On-Premise-Umgebung und die neue Cloud-Umgebung im selben Release-Stand bleiben. Die Lobster Cloud folgt einem festen, vorhersehbaren Wartungsplan. Alle Details zu Zeitplan und Benachrichtigungen finden Sie unter Wartungsplan und Cloud-Update-Richtlinie.

TIPP:

Führen Sie die aktive Migrationsphase (Profiltransfer) so zügig wie möglich durch, um den Aufwand für Versionssynchronisierungen gering zu halten.

Phase 3: Setup Cloud-Umgebung

Eine vollständige Beschreibung der bereitgestellten Infrastruktur und der Aufgabenteilung finden Sie unter Standardarchitektur und Migrationsübersicht.

 WICHTIG: 

Eigene JDBC-Treiber für Ihre eigenen Datenbankanbindungen sind möglich. Den PostgreSQL-Treiber für die Hub-Datenbank stellt Lobster bereit, er darf nicht ersetzt werden!

Phase 4: Profil- und Konfigurationsübertragung

Dies ist der Kern des Migrationsprozesses. Lobster stellt zwei integrierte Werkzeuge bereit, die direkt in der Plattform verfügbar sind.

 WICHTIG: 

Direkte Datenbankimporte, Datenbank-Dumps und Dateisystemtransfers werden nicht unterstützt. Ausschließlich die profilbasierte Migration über Transport Manager und Meta Exchange ist der offizielle Weg.

Transport Manager

Das zentrale Werkzeug für den Transfer von Profilen, Partnern, Konfigurationsdateien und weiteren Objekten zwischen zwei Lobster-Instanzen. Er ermöglicht eine schrittweise Migration im laufenden Parallelbetrieb: Sie können Kunden und Partner nacheinander auf das neue System umstellen, ohne den laufenden Betrieb zu unterbrechen. Alle Informationen zur Einrichtung und Nutzung finden Sie unter Transport Manager.

Meta Exchange

Ergänzt den Transport Manager für komplexe Konfigurationen, insbesondere bei Orchestration-Systemen (_pro). Meta Exchange löst beim Export automatisch alle Abhängigkeiten auf und bündelt diese in einer .xar-Exportdatei. Alle Details zu Export, Import und Übertragung finden Sie unter Meta Exchange.

HA-Umgebungen: nicht jede Datei liegt auf allen Nodes

Eine hochverfügbare Umgebung (HA) besteht aus einem Node Controller und einem oder mehreren Worker Nodes. Profile, Partner und Konfigurationsdateien stehen nach der Übertragung durch den Transport Manager auf allen Nodes zur Verfügung, weil sie im gemeinsamen Repository liegen. Dateien, die Sie selbst im Installationsverzeichnis einer Node ergänzt haben, wandern nicht mit: Bibliotheken im Ordner extlib, eigene Klassen und Dateien, die über einen absoluten Pfad angesprochen werden.

Ob ein solches Verzeichnis geteilt wird, hängt von Ihrer Umgebung ab. HA-Umgebungen in der Lobster Cloud nutzen ein gemeinsames Dateisystem (EFS oder FSx, siehe Third-party software policy); für Verzeichnisse, die dort liegen, genügt eine Kopie. In Ihrer eigenen HA-Installation hat jede Node eigene Verzeichnisse, sofern Sie diese nicht aus einem gemeinsamen Speicher eingebunden haben.

HINWEIS:

Klären Sie vor dem Kopieren von Bibliotheken und eigenen Klassen, welche Verzeichnisse Ihre Umgebung gemeinsam nutzt. Für Cloud-Umgebungen wenden Sie sich an support@lobstersoftware.com. Wo ein Verzeichnis lokal zu einer Node gehört, legen Sie die Dateien auf dem Node Controller und auf jedem Worker Node ab. Load Balancing und Failover können einen Job auf jede Node verlagern. Eine Bibliothek, die nur auf einer Node vorhanden ist, führt deshalb zu Fehlern, die sporadisch auftreten und sich nur schwer auf eine fehlende Datei zurückführen lassen.

Bibliotheken im Ordner extlib und selbst entwickelte Java-Klassen sind keine Konfigurationsdateien. Der Transport Manager nimmt sie nicht in eine Übertragung auf, Sie müssen sie separat auf das Zielsystem bringen.

Phase 5: Konfiguration und Tests

Alle Informationen zur Netzwerkkonfiguration finden Sie unter Netzwerk und Konnektivität und den zugehörigen Unterseiten.

DNS-Migrations-Workflow

Wenn Sie eine bestehende Domain von Ihrem alten System auf die neue Cloud-Umgebung umleiten, führen Sie diese Schritte in der angegebenen Reihenfolge aus:

Schließen Sie die Migration vollständig ab und testen Sie gründlich, bevor Sie das DNS umleiten. Dies minimiert das Risiko von Ausfallzeiten während der Umstellung.

Unterstützung durch Lobster

Eigene Java-Klassen und Bibliotheken

Eigene Java-Klassen und Bibliotheken sind nicht Teil des Lobster Supports. Lobster unterstützt die Lobster Data Platform selbst; Wartung, Weiterentwicklung, Test und Fehlerbehebung Ihrer eigenen Klassen liegen bei Ihnen, ebenso deren Anpassung bei einem Wechsel der Java-Version. Was das in der Lobster Cloud bedeutet, ist unter Third-party software policy beschrieben.

Ihre Migrations-Checkliste

Phase 1: On-Premise Vorbereitung

• Aktuelle Softwareversion der On-Premise-Umgebung geprüft

• Versionskompatibilität mit der Ziel-Cloud-Version bestätigt

• Bei Bedarf: Upgrade-Pfad gemäß Migration von älteren Systemen geplant

• Checkliste zur Upgrade-Vorbereitung vollständig durchgearbeitet

• Testumgebung auf Zielversionsstand aktualisiert und vollständig validiert

• Produktionsumgebung auf Zielversionsstand aktualisiert und vollständig validiert

• Migrationsstrategie festgelegt (Vollmigration oder schrittweise nach Kunden/Partnern)

• Eigene Datenbanktabellen (die nicht Teil der Standardkonfiguration der Software sind) identifizieren

• Eigene Ordnerstrukturen (die nicht Teil der Standardkonfiguration der Software sind) identifizieren

• Eigene Java-Klassen und Fremdbibliotheken erfasst (JAR-Dateien in extlib, eigene Integration Units, Cron-Klassen, Antwortweg-Klassen, Preparser, Postexecuter), inklusive Pfad und der Profile, die sie verwenden.

• Eigene Klassen und Bibliotheken gegen die Ziel-Java-Version neu kompiliert und im Testsystem geprüft (Platform update guide).

• JDBC-Treiber geprüft und aktualisiert, bevor die Java-Version wechselt (JDBC driver compatibility assessment).

• Zuständigkeit für jede eigene Klasse intern geklärt (Third-party software policy).

 WICHTIG: 

Für Ihre eigenen Datenbankanbindungen können Sie eigene JDBC-Treiber mitbringen. Ein Treiber ist davon ausgenommen: Den PostgreSQL-Treiber für die Verbindung zur Hub-Datenbank stellt Lobster bereit und passt ihn auf Ihre Cloud-Umgebung ab. Ersetzen oder aktualisieren Sie diesen Treiber nicht, auch nicht durch eine neuere PostgreSQL-Version. Ein ausgetauschter Treiber kann die Umgebung funktionsunfähig machen. Wenn eine Ihrer eigenen Anbindungen eine andere PostgreSQL-Treiberversion benötigt, wenden Sie sich an support@lobstersoftware.com.

Phase 3: Setup Cloud-Umgebung

• Gewünschten privaten Netzwerkbereich für die VPC festgelegt (darf sich nicht mit On-Premise überschneiden)

• VPN-Anforderungen geklärt (falls benötigt)

• Port 8020 zwischen On-Premise und Cloud-Umgebung freigeschaltet

• Transport Manager Verbindung eingerichtet und getestet

Phase 4: Profil- und Konfigurationsübertragung

• Zeitplan für die Migrationsphase definiert (Wartungsplan beachten)

• Profile, Partner und Konfigurationen über Transport Manager übertragen

• Orchestration-Konfigurationen über Meta Exchange übertragen (falls zutreffend)

• Eigene Datenmigrations-Profile entwickelt und getestet (falls eigene Datenbanktabellen vorhanden)

• Bei Bedarf eigenes Datenbank-Schema und Tabellen anlegen (SQL-Tool)

• Bei Bedarf eigene Ordnerstruktur anlegen und Dateien übertragen (Admin-Konsole)

• Bibliotheken aus extlib und eigene Klassen in die Cloud-Umgebung übertragen.

• Bei HA-Umgebungen: geklärt, welche Installationsverzeichnisse die Nodes gemeinsam nutzen.

• Bei Bedarf eigene Ordnerstruktur anlegen und Dateien übertragen (Admin-Konsole). In einer HA-Umgebung auf jeder Node wiederholen, deren Zielverzeichnis nicht im gemeinsamen Dateisystem liegt.

Phase 5: Konfiguration und Tests

• Alle migrierten Profile in der Cloud-Umgebung getestet und validiert

• Verbindungen und Kommunikationsprotokolle (SFTP, OFTP, AS2, Datenbanken etc.) geprüft

• Pro eigener Klasse mindestens ein Job auf jeder Node der Cloud-Umgebung erfolgreich ausgeführt.

• DNS konfiguriert (A-Record auf neue öffentliche IP, oder CNAME für HA)

• SSL-Zertifikat installiert (falls eigene DNS-Namen genutzt werden)

• Firewall-Regeln in der Cloud für alle erforderlichen IP-Adressen eingerichtet

• Liste aller Kunden und Partner erstellt, die über IP-Adresse (statt DNS) kommunizieren

• Alle betroffenen Kunden und Partner über Adressänderungen informiert

• Für jeden Kunden/Partner: Testlauf in der Cloud-Umgebung durchgeführt und validiert

Weiterführende Dokumentation