What is migration in Local Edition
Migration is the process of moving an existing Local Edition (LE) deployment configuration and runtime data from the version currently deployed in the customer's environment (for example, 5.x.x) to the new Local Edition release version (for example, 6.x.x) they want to install.
Migration and upgrade both move a Local Edition deployment to a newer release version, carrying forward existing configuration and runtime data. The difference is in the version scope and deployment mode:
- Upgrade: This is a minor version change, where you upgrade between the same deployment mode. For example, tethered 6.1.0 → tethered 6.3.0.
- Migration: This is a major version change, where you can optionally change deployment mode (untethered ↔ tethered), or move between the same modes across major versions For example, 5.x.x → 6.x.x.
Both processes preserve existing configuration and runtime data, ensuring nothing is lost during data transfer.
Local Edition Deployment modes
Every Local Edition deployment runs in one of two modes:
-
Untethered: This deployment mode is a fully self-managed, where the customer stores and maintains configuration data locally, with no dependency on the Cloud API Management (SaaS).
-
Tethered: This deployment is connected to Cloud API Management (SaaS), which owns and manages the configuration data, and the local deployment or Local Edition only serves traffic.
The migration type is determined by the Local Edition source and target modes. Therefore, identify the source and target Local Edition modes first, as these choices determine the tooling, the data path, and the prerequisites for the entire migration.
Migration Types
Same deployment mode (untethered → untethered or tethered → tethered)
Migration within the same deployment mode — from untethered to untethered or from tethered to tethered uses a database-to-database approach to transfer both configuration and runtime data directly between source and target databases.
Different deployment mode (untethered → tethered)
Migration between the different deployment modes — from untethered to tethered — moves data from a self-managed, untethered Local Edition deployment to a Boomi-managed, tethered Cloud API Management (SaaS) environment. This migration uses an API-based approach, where the migration pod fetches data from the existing deployment's Platform API and transfers it to the Cloud API Management (SaaS) environment. A database-to-database approach is also used for identities and the truststore, even on this path.
Supported migration paths
Migration (major version change)
The following table lists every supported source-to-target combination deployment modes for a migration (major version change).
| Source version (mode) | Target version (mode) | Notes |
|---|---|---|
| 5.x.x (untethered) | 6.3.0 (tethered) | Change of mode |
| 6.3.0 (untethered) | ||
| 6.2.1/6.2.0 (untethered) | previous release | |
| 5.x.x (tethered) | 6.3.0 (tethered) | |
| 6.2.1/6.2.0 (tethered) | previous release | |
| 4.x.x (tethered) | 6.3.0 (tethered) | |
| 6.2.1/6.2.0 (tethered) | previous release |
Upgrade (minor version change)
While upgrading, the deployment mode is always preserved, untethered stays untethered, tethered stays tethered. The following table lists every supported source-to-target combination for an upgrade (minor version change).
| Source version (mode) | Target version (mode) | Notes |
|---|---|---|
| 6.1.0, 6.2.0, 6.2.1 (tethered) | 6.3.0 (tethered) | |
| 6.0.0, 6.1.0, 6.2.0, 6.2.1 (untethered) | 6.3.0 (untethered) | |
| 6.1.0, 6.2.0 (tethered) | 6.2.1 or 6.2.0 (tethered) | previous release |
| 6.0.0, 6.1.0, 6.2.0 (untethered) | 6.2.1 or 6.2.0 (untethered) | previous release |
