Here you will find an overview of all migrations. The overview is divided into assigned, prepared or already completed migrations. With "Comment/Description" you can freely leave your notes on this migration or leave instructions for the assigned person. Click on "Details" to access the migration and continue with it.

Open

Start a Migration

In the migrations overview you can see all prepared, assigned and already performed migrations.
You can also start migrations from here.

Open

Migration Sources

Each migration is associated with a migration source, which can be a Layer7 gateway, an XML bundle uploaded to the Gateway Manager, or bundles stored in a git repository. It's important to note that bundle upload and repository-based migrations are currently only available for managed services.

Migration Targets

The migration targets represent the gateways you are migrating into, which can be individual gateways, clusters, or entire environments. If you have multiple production environments with several clusters each, the APIIDA API Gateway Manager enables you to update all those gateways in a single migration run. Alternatively, you can choose to update one cluster initially, verify that everything is functioning correctly, and then repeat the migration for the remaining clusters.

On the mappings page, you can link various targets so that any edits you make to the next action are applied to all target tabs.

After the migration is complete, each target generates its own results, and a summary indicates which targets were updated successfully and which ones encountered failures.

Mappings

The mappings function with the same semantics as those found in Layer7's own tooling. A mapping links a resource from the source to its counterpart on the target. Depending on how the resource was created on the target, it may have a different ID. The mapping facilitates the translation of these differing IDs during migration. Moreover, you can specify the action to be taken for a particular resource during migration.

Mappings include the resources you intend to migrate (selected either from a managed service or any resource in the resource explorer) along with all of their first-level dependencies. The action chosen by the Gateway Manager during migration preparation is determined by suggestions from the Layer7 gateway and the default settings you've configured for each resource type (e.g., NewOrExisting for all JDBC connections) in the configuration. You also have the option to set a preferred action as the default on a per-resource basis.

A green highlight on any mapping indicates a difference in the hash of the source object compared to the hash of the target object. This serves as an indication of whether an object has changed.
Conversely, objects NOT highlighted in green are considered identical between the source and target, and therefore do not require migration.

Auto-Map

Layer7 identifies its resources based on an ID. However, the same resource may have different IDs on different gateways. When using pure GMU to conduct a migration, you must know these different IDs in advance and instruct GMU to perform the mapping. The APIIDA API Gateway Manager simplifies this process by automatically mapping those resources for you. If a resource is auto-mapped, a notification badge appears next to the resource, allowing you to review the automatic mapping

Previewing and Changing Mapping Actions

Rather than relying solely on Layer7's dry run feature, the APIIDA API Gateway Manager provides real-time insights into the potential outcomes of migrating resources as you prepare for migration. This feature enables you to ensure accuracy from the outset. All errors and potential failures are clearly identified in the mapping table, accompanied by mitigation hints on how to resolve each error. Additionally, modifying the action of a mapping automatically updates the associated mitigation hint, streamlining the resolution process.

Testing a Migration

If you wish to conduct a dry run of your migration, you can do so by clicking the “Test” button provided on the migration screen. During this process, you may be prompted to determine whether folders should be created on the target. In some cases, creating folders is necessary for a successful test, especially in multi-directory hierarchies.

Please note: Folders created during the test are not removed afterward and remain available for the actual migration process.

Following the test, you can initiate the actual migration from the test's result screen or by returning to the migration screen.

Performing a Migration

Executing your prepared migration may take some time, depending on the volume of data you're migrating. The process operates in the background, ensuring that the migration continues even if you close your browser window, preventing any interruptions.
If you navigate back, the migration will continue, allowing you to perform other tasks. You can recall the existing migration by clicking the progress icon, which appears at the top right of the screen..

Once the migration is complete, its results are presented in a condensed format. The result screen allows you to review the changes made to the gateway, as well as any error messages returned by the gateway. You also have the opportunity to examine the logs and download the raw XML return messages from the gateway.

Rolling Back a Migration

Before initiating a migration, assuming backups have been enabled in the Features section of the configuration, the APIIDA API Gateway Manager generates a backup of all components slated for modification. While services and policies enable you to revert to a previous version seamlessly, this backup functionality empowers us to rollback any modifications made to the gateway.