Migration process step by step

This page guides you through the complete migration process to Lobster Cloud: from the requirements in your existing on-premise environment, through profile transfer, to go-live with your customers and partners.

Overview

Phase 1: On-premise preparation

Why is this so important?

The Transport Manager requires that source and target systems run within the same major release. Migrating from an outdated version is technically possible, but makes the process unnecessarily complex. The clear recommendation is therefore: bring your on-premise environment up to the current version before starting the migration.

NOTE:

Lobster supports you: If you need assistance upgrading your on-premise environment, please reach out to your Lobster contact.

Version requirements

Full details on the upgrade path and known specifics can be found under One-click migration from older systems.

Upgrade strategy: Test before production

Always upgrade your test environment first and validate it fully before updating your production system. All required steps and important considerations are described in detail in the Before starting an upgrade.

Define your migration strategy

Decide early whether you want to migrate all profiles at once or gradually transition customers and partners to the new system in parallel operation. A phased migration reduces risk and allows for a controlled go-live per customer or partner.

Special case: Custom database tables, folders, and custom classes

The Transport Manager transfers Lobster configuration objects only, such as profiles, partners, and Configuration Files. If your databases contain tables that are not an official part of the Lobster software (e.g., custom lookup tables or master data), you will need to find your own approach for migrating that data, for example, through specifically developed profiles. This also applies to your own folders.

The same applies to everything you added to the file system yourself: JAR files in the extlib folder, your own Java classes (Integration Units, cron classes, response classes, preparser, post-editors), and files your profiles read at runtime. The Transport Manager does not transfer them. A profile that references a custom class transfers and starts without an error in the cloud and fails at runtime once the class is missing. Note every custom library and class with its exact path and the profiles that use it before you start the transfer.

The upgrade to the current platform version also changes the Java runtime. Recompile your custom classes and update their dependencies accordingly, and check the JDBC drivers before the Java version changes. See Platform update guide and its sub-pages, in particular JDBC driver compatibility assessment.

NOTE:  Raise custom tables, folders, and custom classes with your Lobster contact early, so the effort can be factored into the migration planning. Custom Java classes remain your responsibility, including their adaptation to a new Java version; see Third-party software policy.

Phase 2: Version synchronization during migration

Throughout the entire migration phase, your on-premise environment and the new cloud environment must remain on the same release level. Lobster Cloud follows a fixed, predictable maintenance schedule. All details on scheduling and notifications can be found under Maintenance schedule and Cloud update policy.

TIP

It is recommended that you complete the active migration phase (profile transfer) as promptly as possible to minimize the overhead of version synchronization.

Phase 3: Cloud Environment Setup

A full description of the provisioned infrastructure and the division of responsibilities can be found under Standard architecture and Migration overview.

IMPORTANT:

Own JDBC drivers for your own database connections are possible. The PostgreSQL driver for the hub database is provided by Lobster and must not be replaced!

Phase 4: Profile and Configuration Transfer

This is the core of the migration process. Lobster provides two built-in tools available directly within the platform.

IMPORTANT:  

Direct database imports, database dumps, and file system transfers are not supported. Profile-based migration via Transport Manager and Meta Exchange is the only supported approach.

Transport Manager

The central tool for transferring profiles, partners, configuration files, and other objects between two Lobster instances. It enables a phased migration in live parallel operation: you can transition customers and partners to the new system one by one without interrupting ongoing operations. All information on setup and usage can be found under Transport Manager.

Meta exchange

Complements the Transport Manager for complex configurations, particularly for Orchestration systems (_pro). Meta exchange automatically resolves all dependencies during export and packages them into a .xar export file. All details on export, import, and transfer can be found under Meta exchange.

HA environments: not every file is shared between nodes

A high-availability environment (HA) consists of a Node Controller and one or more Worker Nodes. Profiles, partners, and configuration files reach every node once the Transport Manager has transferred them because they live in the shared repository. Files you added to the installation directory of a node do not travel with them: extlib libraries, custom classes, and files addressed through an absolute path.

Whether such a directory is shared depends on your environment. An HA environment in the Lobster Cloud uses a shared file system (EFS or FSx, see Third-party software policy); for directories that reside there, one copy is enough. In your own HA installation, each node has its own directories unless you mount them from shared storage.

Note

Before you copy libraries or custom classes, confirm which directories your environment shares. For cloud environments, ask support@lobstersoftware.com. Where a directory is local to a node, add the files on the Node Controller and on every Worker Node. Load balancing and failover can move a job to any node, so a library present on one node only causes failures that appear sporadically and are hard to trace back to a missing file.

Custom libraries in extlib and your own Java classes are not configuration files and are not part of a Transport Manager transfer.

Phase 5: Configuration and testing

All information on network configuration can be found under Network and connectivity and its sub-pages.

DNS migration workflow

If you are redirecting an existing domain from your old system to the new cloud environment, follow these steps in the order listed:

NOTE:  Complete your migration and test thoroughly before updating your DNS records. This minimizes the risk of downtime during the cutover.

Lobster Support

Custom Java classes and libraries

Custom Java classes and libraries are not part of Lobster support. Lobster supports the Lobster Data Platform itself, while maintenance, further development, testing, and bug fixing of classes you developed remain with you, including their adaptation when the Java version changes. What this means in the Lobster Cloud is described under Third-party software policy.

Your migration checklist

Phase 1: On-premise preparation

• Current software version of the on-premise environment verified.

• Version compatibility with the target cloud version confirmed.

• If required: upgrade path planned according to One-click migration from older systems.

• Pre-upgrade checklist fully completed (see Before starting an upgrade).

• Test environment updated to target version and fully validated.

• Production environment updated to target version and fully validated.

• Migration strategy defined (full migration or phased by customer/partner).

• Identify custom folder structures (not part of the software's default setup).

• Identify custom database tables (not part of the software's default setup).

• Identify custom Java classes and third-party libraries (JAR files in extlib, custom Integration Units, cron classes, response classes, preparsers, post-executors), including their paths and the profiles that use them.

• Custom classes and libraries recompiled against the target Java version and validated in the test environment (Platform update guide).

• JDBC drivers checked and updated before the Java version is switched (JDBC driver compatibility assessment).

• Ownership of every custom class clarified on your side (Third-party software policy).

IMPORTANT:

You can add your own JDBC drivers for your own database connections. One driver is excluded: the PostgreSQL driver used for the hub database connection is provided by Lobster and matched to your cloud environment. Do not replace or update it, not even with a newer PostgreSQL version. The platform depends on it, and an exchanged driver can leave the environment inoperable. If one of your own connections requires a different PostgreSQL driver version, contact support@lobstersoftware.com rather than replacing the existing file.

Phase 3: Cloud Environment Setup

• Desired private network range for the VPC defined (must not overlap with on-premise network)

• VPN requirements clarified (if needed)

• Port 8020 opened between on-premise and cloud environment

• Transport Manager connection established and tested

Phase 4: Profile and Configuration Transfer

• Migration timeline defined (refer to Maintenance schedule).

• Profiles, partners, and configurations transferred via Transport Manager.

• Orchestration configurations transferred via Meta exchange (if applicable).

• Custom data migration profiles developed and tested (if non-standard database tables are present).

• If required, create your own database schema and tables (SQL tool).

• If required, create your own folder structure and transfer files (Admin console).

• extlib libraries and custom classes transferred to the cloud environment.

• For HA environments: clarified which installation directories are shared between the nodes.

• If required, create your own folder structure and transfer files (Admin console). In an HA environment, repeat this on every node whose target directory is not on the shared file system.

Phase 5: Configuration and Testing

• All migrated profiles were tested and validated in the cloud environment.

• Connections and communication protocols verified (SFTP, OFTP, AS2, databases, etc.).

• At least one job per custom class executed successfully on every node of the cloud environment.

• DNS configuration configured (A-record to new public IP, or CNAME for HA).

• SSL/TLS certificates installed (if custom DNS names are used).

• Firewall rules in the cloud are configured for all required IP addresses.

• List of all customers and partners communicating via IP address (rather than DNS) compiled.

• All affected customers and partners were notified of address changes.

• For each customer/partner: test run in the cloud environment completed and validated.

Further Documentation