Stay organized with collections Save and categorize content based on your preferences.

Modernize traditional workloads

This topic describes how to modernize VM-based workloads into containers that run on Google Kubernetes Engine (GKE), Anthos cluster, or the Cloud Run platform. You can migrate workloads from VMs running on VMware, AWS, Azure, or Compute Engine, giving you the flexibility to containerize your existing workloads.

To perform the modernization (also referred to as migration), you use a processing cluster that you created with the steps in Installing Migrate to Containers.

The basic flow to migrate a workload is similar across supported workloads types. There are some differences between workload types, so you need to identify your workload type in the sections below for an outline of the procedure and detailed information per step.

Supported workloads

Migrate a Linux VM

Migration procedure

The following diagram illustrates the migration steps for a Linux workload:

Diagram of steps to migrate with Migrate to Containers
  1. Add a migration source.

    You start a migration by configuring a source that represents the source platform from which you will be migrating. If you already have a source from a previous migration and the VMs you're migrating are from the same source, you can re-use it.

  2. Create a migration.

    Create a migration object with an initial migration plan.

  3. Migrate Linux data.

    Choose whether you want to migrate data or not.

  4. Customize your migration plan.

    Edit the migration plan for your specific requirements before executing the migration.

  5. Execute the migration.

    Execute the migration to extract the container artifacts, including the container image and Dockerfile. Use these artifacts to deploy the container to your testing environment or to production.

  6. Monitor a migration.

    Monitor the progress of a migration and inspect migration activity logs.

  7. Delete a migration.

    Delete the migration to free up any resources used by it.

Migrate a Windows IIS application

Migration procedure

The following diagram illustrates the migration steps for a Windows workload:

Diagram of steps to migrate with Migrate to Containers

The steps to migrate with Migrate to Containers are the following:

  1. Add a migration source.

    You start a migration by configuring a source that represents the source platform from which you are migrating. If you already have a source from a previous migration and the VMs you're migrating are from the same source, you can re-use it.

  2. Create a migration plan.

    Create a migration object with an initial migration plan".

  3. Customize your migration plan.

    Edit the migration plan for your specific requirements before executing the migration.

  4. Execute the migration.

    Execute the migration to extract the container artifacts, which include the Dockerfile and other files necessary to build a container image.

  5. Monitor the migration.

    Monitor the progress of a migration and inspect migration activity logs.

  6. Build a Windows container image

    Use the generated artifacts to build a Windows container that you can then deploy to a cluster.

  7. Delete a migration.

    Delete the migration to free up any resources used by it.

Supported features

Migrate to Containers: Windows currently supports migrating IIS .Net framework sites. You may split the sites into single purpose images, or group them as you wish.

To have a better indication of which sites can be migrated on a source VM, try running the mFit tool.

Migrate a Tomcat server

The following diagram illustrates the migration steps for a Tomcat workload:

Diagram of steps to migrate with Migrate to Containers

When you use Migrate to Containers to migrate your Tomcat workloads, you can leverage Tomcat's features and architecture to:

  • Automatically separate subsets of applications into individual containers.
  • Retain your Tomcat application's existing keystores, truststores, and certificates from the source VM.
  • Dynamically determine optimal memory allocation for JVM applications.
  • Copy specific data volumes and data volume claims from your source VMs.

Prerequisites

  • A Linux VM based Apache Tomcat app server v8.5 and later.
  • Determine the fit of the workload for migration by using the fit assessment tool.
  • Configure a Cloud cluster for migrating Linux VMs.

Migration procedure

The steps to migrate with Migrate to Containers are the following:

  1. Add a migration source.

    You start a migration by configuring a source that represents the source platform from which you are migrating. If you already have a source from a previous migration and the VMs you're migrating are from the same source, you can re-use it.

  2. Create a migration.

    Create a migration object with an initial migration plan".

  3. Migrate Tomcat data.

    Choose whether you want to migrate data or not.

  4. Customize your migration plan.

    Edit the migration plan for your specific requirements before executing the migration.

  5. Execute the migration.

    Execute the migration to extract the container artifacts, which include the Dockerfile and other files necessary to build a container image.

  6. Monitor the migration.

    Monitor the progress of a migration and inspect migration activity logs.

  7. Build a Tomcat container image

    Use the generated artifacts to build a container that you can then deploy to a cluster.

  8. Delete a migration.

    Delete the migration to free up any resources used by it.

Unsupported features

The following Tomcat features are not supported:

  • Clustering/Session replication.

  • Windows support for Tomcat migrations using Windows workloads.

Migrate a WebSphere server (Pre-GA)

Prerequisites

Before you begin migrating, review the following and ensure that your IBM WAS traditional environment and migration processing cluster meet the requirements.

Migration procedure

The following diagram illustrates the migration steps for a WebSphere workload:

Migrate WAS apps to individual app containers.

The steps to migrate with Migrate to Containers are the following:

  1. Add a migration source.

    Add the migration source that represents the source platform.

  2. Create a migration.

    Create a migration object with an initial migration plan.

  3. Migrate WebSphere data.

    Choose whether you want to migrate data or not.

  4. Customize the migration plan.

    Edit the migration plan for your specific requirements before executing the migration. You migrate one WAS app per migration.

  5. Execute the migration.

    Execute the migration to extract the container artifacts, which include the Dockerfile and other files necessary to build a container image.

  6. Generate and review migration artifacts.

    Perform the migration to generate the app container. You can monitor the migration process, and when finished, review the artifacts in preparation for building the deployable app image.

  7. Monitor the migration.

    Monitor the progress of a migration and inspect migration activity logs.

  8. Build an app container image.

    Use the generated artifacts to build a container that you can then deploy to a cluster.

  9. Deploy an app container to a target cluster.

    Deploy the image to your target cluster.

  10. Delete a migration.

    Delete the migration to free up any resources used by it.

Migrate a JBoss server

The following diagram illustrates the migration steps for a JBoss workload:

Diagram of steps to migrate with Migrate to Containers

When you use Migrate to Containers to migrate your JBoss workloads, you can leverage the features and architecture of JBoss to copy specific data volumes and data volume claims from your source VMs.

Prerequisites

  • JBoss AS app server v8.1.0 and later, or, JBoss EAP app server v7.0.

  • Configure a Google Cloud cluster for migrating VMs.

Migration procedure

The steps to migrate with Migrate to Containers are the following:

  1. Add a migration source.

    You start a migration by configuring a source that represents the source platform from which you're migrating. If you already have a source from a previous migration and the VMs you're migrating are from the same source, you can reuse it.

  2. Create a migration.

    Create a migration object with an initial migration plan.

  3. Migrate JBoss data.

    Choose whether you want to migrate data or not.

  4. Customize your migration plan.

    Edit the migration plan for your specific requirements before executing the migration.

  5. Execute the migration.

    Execute the migration to extract the container artifacts, which include the Dockerfile and other files necessary to build a container image.

  6. Monitor the migration.

    Monitor the progress of a migration and inspect migration activity logs.

  7. Build a JBoss container image

    Use the generated artifacts to build a container that you can then deploy to a cluster.

  8. Delete a migration.

    Delete the migration to free up any resources used by it.

Unsupported features

The following JBoss features are not supported:

  • Sensitive data and secrets - Sensitive data and secrets stored inside the JBOSS_HOME/standalone directory will not be removed. This data will be included in the container image.
  • JBoss logger configuration - The logger configuration will be taken as is from the source machine. It will not be modified during the migration process unless the jbossServer.tar.gz is modified manually before building the JBoss container.
  • Memory allocation - Java Virtual Machine (JVM) resources allocation will be taken from the community container and will not depend on the source machine JVM resources.
  • Environment variables - Environment variables and JVM parameters from the source machine will not be migrated to the container image.
  • Using the fit assessment tool - Determining the fit of your JBoss workload for migration is not supported.

Migrate an Apache server

The following diagram illustrates the migration steps for an Apache workload:

Diagram of steps to migrate with Migrate to Containers

When you use Migrate to Containers to migrate your Apache workloads, you can leverage Apache's features and architecture to:

  • Copy specific data volumes and data volume claims from your source VMs.

Prerequisites

  • A Linux VM based Apache 2 Webserver.
  • Configure a Google Cloud cluster for migrating Linux VMs.

Migration procedure

The steps to migrate with Migrate to Containers are the following:

  1. Add a migration source.

    You start a migration by configuring a source that represents the source platform from which you are migrating. If you already have a source from a previous migration and the VMs you're migrating are from the same source, you can re-use it.

  2. Create a migration.

    Create a migration object with an initial migration plan.

  3. Migrate data.

    Choose whether you want to migrate data or not.

  4. Customize your migration plan.

    Edit the migration plan for your specific requirements before executing the migration.

  5. Execute the migration.

    Execute the migration to extract the container artifacts, which include the Dockerfile and other files necessary to build a container image.

  6. Monitor the migration.

    Monitor the progress of a migration and inspect migration activity logs.

  7. Build an Apache container image

    Use the generated artifacts to build a container that you can then deploy to a cluster.

  8. Delete a migration.

    Delete the migration to free up any resources used by it.

Unsupported features

Apache 1 workloads are not supported.

The following Apache features are not supported:

  • Certificates.

  • Windows support for Apache migrations using Windows workloads.

What's next

Linux

Windows

Tomcat

WebSphere (Pre-Ga)

JBoss

Apache