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

Migrate a VM

This topic describes how to migrate VMs to GKE with Migrate to Containers. To perform the migration, you use a processing cluster you created with the steps in Installing Migrate to Containers.

The basic diagram to migrate a workload is similar across most supported workloads types. However, the following steps are distinct between each workload type:

  • Customize your migration plan
  • Build a container image

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 execuing 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:

  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 soure 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 your workload's fit 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:

  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.

Migrating 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:

  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.

What's next

Linux

Windows

Tomcat

WebSphere (Pre-Ga)