Migrate to Containers release notes

The Migrate to Containers UI in the Google Cloud console, migctl, and CRDs that used processing clusters to migrate workloads to Google Cloud are no longer available.

To perform migrations, use the Migrate to Containers CLI on your local machine. For more information, see Migrate to Containers overview.

If you have any questions or require additional support, then reach out to m2c-external-feedback@google.com.

The Migrate to Containers UI in the Google Cloud console, migctl, and CRDs that use processing clusters to migrate workloads to Google Cloud are now deprecated. They are supported for existing users until May 2024, after which they will no longer be available. If you're new to Migrate to Containers, then use the Migrate to Containers CLI to perform migrations on your local machine. For more information, see Migrate to Containers CLI architecture.

Support for IBM WebSphere Application Server migrations has been enhanced. The websphere-container plugin now supports WebSphere Application Server traditional as a source and as a target.

The websphere-traditional plugin is now deprecated. For existing customers, it is still supported till December 2023, after which it will no longer be available. If you're new to WebSphere workload modernization, then use the websphere-container plugin with the Migrate to Containers CLI instead.

On November 29, 2023 we released version 1.4.0 of the Migrate to Containers modernization plugins.

Learn how to Upgrade Migrate to Containers plugins.

The following changes have been made to the migration plan format for Tomcat workloads:

• A new field baseImage of type object has been added that lets you do the following:

  • Specify the Docker community image or provide your own Docker image to use as the base image for the migration using the baseImage.name property of type string.

  • Specify a custom Tomcat installation path using the baseImage.catalinaHome property of type string.

• The fromImage field of type string has been replaced by the baseImage.name property.

• Two new fields userName and groupName of type string have been added that let you specify a custom user and group under which you want the application to run.

The plugins for migrating Apache, JBoss, WordPress, and IBM WebSphere traditional applications to containers are now generally available. These plugins provide a streamlined and simplified experience for migrating applications based on these frameworks.

On October 30, 2023 we released version 1.3.1 of the Migrate to Containers modernization plugins.

Learn how to Upgrade Migrate to Containers plugins.

On August 22, 2023 we released version 1.3.0 of the Migrate to Containers modernization plugins.

Learn how to Upgrade Migrate to Containers plugins.

Linux system service endpoints are no longer automatically discovered and must be manually specified while customizing the Linux migration plan.

The following changes have been made to the discovery parameters for the Tomcat plugin:

• The java-version parameter is now added as input to Tomcat migrations.
• The catalina-base parameter can now include multiple directories delimited with colons (:).
• The java-version, catalina-base and catalina-home parameters are now mandatory.

The following changes have been made to the IBM WebSphere Application Server migration:

• Renamed the plugin from websphere-container to websphere-traditional-container. This plugin now supports WebSphere Application Server Traditional as a migration source.

• Added support for WebSphere Application Server Liberty as a target.

• The was-home parameter is now mandatory.

On June 27, 2023 we released version 1.2.0 of the Migrate to Containers modernization plugins.

Learn how to Upgrade Migrate to Containers plugins.

The following issues were fixed:

• Unsupported Apache module caused the migration to get stuck in the generate artifacts phase.
• Duplicate migration warnings appeared for JBoss Wildfly workloads.
• Duplicate sensitiveDataPath entries found in JBoss Wildfly migration plan.

On May 22, 2023 we released Migrate to Containers 1.15.0.

In-place processing on Anthos on AWS is no longer supported. You cannot install new versions of Migrate to Containers on Anthos on AWS clusters. To migrate application components of VMs on AWS, you can migrate VMs from AWS to Compute Engine using Migrate to Virtual Machines v5, and then use Migrate to Containers to perform a migration from the created Compute Engine instance. For more information, see the Migrate to Virtual Machines version 5.0 documentation.

The use of migration sources based on Migrate to Virtual Machines v4 is no longer supported.

To migrate application components from VMs running on VMWare clusters, you can use Migrate to Virtual Machines v5 integration. For more information, see Adding Migrate to Virtual Machines as a migration source.

To migrate application components from AWS or Azure use Migrate to Virtual Machines v5 to migrate VMs to Compute Engine, and then use Migrate to Containers to perform a migration from the created Compute Engine instance. For more information, see the Migrate to Virtual Machines version 5.0 documentation.

In-place processing on Anthos on VMware is no longer supported. You cannot install new versions of Migrate to Containers on Anthos on VMWare clusters. Instead, you can migrate application components to GKE or Anthos clusters on bare metal using Migrate to Virtual Machines v5 or the local VMWare source respectively.

The legacy Linux runtime is now deprecated. The generated migration plan now uses the enhanced Linux runtime by default. You can choose to use the legacy Linux runtime, which is planned to be supported until August 2023, by setting the value of the v2kServiceManager flag in the migration plan to false.

To see how to convert existing migrations to the new Linux runtime, see Upgrade container workloads for enhanced runtime.

If you have migrated applications using the legacy runtime, you can install the legacy runtime support using the following command:

migctl setup install --runtime

For more information, see Before you begin deploying a Linux workload to a target cluster.

Enhanced the Windows features filtering to only allow features supported by Windows Docker images to work.

On March 27, 2023 we released version 1.1.0 of the Migrate to Containers modernization plugins.

Learn how to Upgrade Migrate to Containers plugins.

Introduced the following features for JBoss migration:

• Support for JBoss versions has been extended and Migrate to Containers now supports migration of JBoss EAP versions 7.0 - 7.4 to equivalent Wildfly community based container images, besides migrations of Wildfly versions 8.1.0 - 26.1.1.
• Secrets are now automatically created from extracted security realms configuration and key-stores. This new feature fixes potential security risks and lets you update secrets without having to recreate images.
• The targetImageHome property has been added to the migration plan to allow users to specify an alternative container image with a different JBOSS_HOME location.
• The ExcludeFiles property has been added to the migration plan, which lets you explicitly exclude files and directories from the container image.
• The data migration feature now automates the creation and mounting of a Persistent Volume Claim (PVC) for the $JBOSS_HOME/standalone/data directory. This directory is available for use by services that require storing content in the file system.

Preview: Added support for refactoring WordPress Servers running on Apache2 Linux to containers, which lets you deploy WordPress sites as containers on GKE, GKE Autopilot clusters, Anthos clusters, and Cloud Run.

For more information, see Migrate a WordPress site.

Filtering out files located at /tmp when discovering Tomcat application dependencies.

Docker images may contain broken symlinks. Ensure that the tar archive artifacts added to dockerfile don't contain symlinks that don't resolve to another file in the archive. If they do, either retrieve the files from the source VM and add them to the dockerfile manually, or replace the symlinks in the source VM and perform extraction again.

On March 20, 2023 we released Migrate to Containers 1.14.1.

Migrate to Containers now supports Workforce identity federation.

Documentation restructured to provide better visibility of high-level tasks.

Using Anthos for VMware processing clusters for containerisation of VMware sources is now deprecated and is planned to be supported till July 2023.

The following are open issues:

• migctl migration status sometimes prints an error message before the migration table. This message does not indicate a concrete problem and can be ignored.
• The UI fails when performing "Processing Cluster Add" having Resource Location Org Policy. To overcome that the processing cluster installation should be done using migctl and the target region should be provided using --gcp-region.
• Creation of multiple source providers at the same time might cause timeouts. If this happens, delete and recreate source provider objects that failed to be created.
• Replicated VM deletion might hang depending on other object deletion. To prevent this from happening, delete the Migrate to Virtual Machines (M2VM) source after deleting the corresponding Migration objects. Otherwise, if this happens, delete the M2VM replications manually.
• Generated Kubernetes deployment specifications might contain invalid (non-DNS1123 compliant) container names when such names appear in the source VM. To prevent this from happening, go over the migration plan before generating artifacts and change the names to be DNS1123 compliant.

The following issues were fixed:

• migctl setup uninstall failure - source snapshot is not deleted. This is happening when the corresponding source provider was already deleted.
• Starting a migration from the UI page "Sources & Candidates" might get stuck on a "retrying" step.

On Dec 6, 2022 we released Migrate to Containers 1.14.0.

Enhanced control on the verbosity of backend logs. You can now use the migctl logging set-verbosity <verbosity> command, where verbosity 0 corresponds to info logs only and verbosity 1 shows debug logs. See migctl reference.

Support for refactoring Apache 2 Linux based applications to containers, which lets you deploy Apache 2 application components as containers on GKE, GKE Autopilot clusters, Anthos clusters, and Cloud Run, released for Public Preview. See Migrate Apache 2 Servers.

Support for refactoring applications running on JBoss Enterprise Application Platform or WildFly application platform to containers, which lets you deploy the application as containers on GKE, GKE Autopilot clusters, Anthos clusters, and Cloud Run, released for Public Preview. See Migrate JBoss Servers.

Containerization from AWS, Azure, and local vSphere (Anthos on vSphere) sources and local processing in AWS clusters are now deprecated and planned to be supported until April 2023.

The following issues were fixed:

• Windows IIS modernization - In case IIS files are not accessible to BUILTIN/Administrators, the discovery phase of IIS modernization will fail.
• Support migration of Windows IIS sites where Administrator user has no permissions to access the IIS configuration files.
• On Linux migrations, if the migration plan YAML is missing the Image section, the task will fail with a panic instead of an indicative message.

The following are open issues:

• migctl migration status sometimes prints an error message before the migration table. This message does not indicate a concrete problem and can be ignored.
• UI fails when performing "Processing Cluster Add" having Resource Location Org Policy. To overcome that, the processing cluster installation should be done using migctl and the target region should be provided using --gcp-region.
• Two migrations from different M2VM sources on the same VM can affect each other. When using M2VM sources, users should avoid creating multiple Migration objects from different sources at the same time for the same VM.
• Creation of multiple source providers at the same time may cause timeouts. If this happens users should delete and recreate source provider objects that failed to be created.
• Replicated VM deletion can hang depending on other object deletion. To prevent this from happening users should delete M2VM source after deleting the corresponding Migration objects. Otherwise, if this happens users should delete the M2VM replications manually.
• migctl setup uninstall failure - source snapshot is not deleted. This is happening when the corresponding source provider was already deleted. If this happens users should recreate the corresponding source provider and after migrations are removed to proceed with uninstalling.
• Starting a migration from the UI page "Sources & Candidates" might get stuck on a "retrying" step. If this happens users should create a Migration using the VM name as input.

On Sep 20, 2022 we released Migrate to Containers 1.13.0

Support for refactoring Tomcat applications to containers, which lets you deploy Tomcat application components as containers on GKE, GKE Autopilot clusters, Anthos clusters and Cloud Run, has moved from the Public Preview stage to General Availability.

Added Kubevirt UEFI support. Virtual machines with UEFI firmware can now be migrated without user interaction. Migrations to Anthos VM Runtime that previously failed due to this limitation will need to be recreated.

Added periodic health checks for migration sources to assure migration source availability and health. Migrate for Containers periodically checks the status of the source providers to reflect potential problems such as missing service accounts or lack of permissions. This enhancement helps ensure smooth operation and alerts you of failure cases.

New progress indication to Migrate to Containers CLI tool - Running migctl migration status displays the progress of snapshot creation stage, upload progress of generate artifact stage, and for Linux migration, the progress of packing the image file.