Customize migration plan for WebSphere traditional workloads

Review application migration reports

You can review the application migration report generated by the IBM WebSphere Application Server Migration Toolkit for Application Binaries. The toolkit generates an HTML report for each app in the source VM. View the HTML file to evaluate the app migration.

To review the application migration report:

  1. Open the Cloud Storage browser in the Google Cloud console:

    Open the Cloud Storage browser

  2. Navigate to the /output folder in the migration artifacts bucket on Google Cloud Storage.

  3. For each app discovered in the VM you will see an HTML file named:


  4. Select the HTML file to view it, or download it locally, to evaluate the migration.

Edit the migration plan

To edit the migration plan, download the migration plan, edit it, then update it using migctl. The migration plan is represented by the AppXGenerateArtifactsFlow CRD:

  1. Download the migration plan. The migration plan is represented by a AppXGenerateArtifactsFlow object:

    migctl migration get my-migration
  2. Because you are going to edit this file, first make a copy so that you can recover it:

    cp my-migration.yaml my-migration-original.yaml
  3. Edit the downloaded migration plan, my-migration.yaml, in a text editor.

    1. Ensure that you only have one path property.

      The AppXGenerateArtifactsFlow object contains a path property for every app that Migrate to Containers discovered in the WAS traditional VM. Delete all but one path definition, and any sharedLibraries specifications, so that only one app is specified. This edit ensures that each app has its own container image.

      The AppXGenerateArtifactsFlow object lists all apps in the form:

        -  path: "PATH_TO_APP1"
          - sharedLibrary1
        -  path: "PATH_TO_APP2"
          - sharedLibrary1
        -  path: "PATH_TO_APP3" 
    2. Ensure that the app_name is unique for each app.

      The deployment field specifies the name of the app used in the deployment_spec.yaml file. Set this field to a unique value for each app in the CRD. You must ensure that you deploy each app container with its own unique app name.

       appName: app-name
    3. Set the tag name of the image.

      The image field value defines the name and location of images created from a migrated VM. By default, a tag corresponding to the timestamp of the migration is automatically applied to the "image_name" value. This tag is in the form:


      You can use the timestamp to differentiate migrations. Alternatively, you can apply your own tag. For example, edit the CRD and add the rev1 tag as shown below:

      name: "image_name:rev1"

    4. Set any other properties you want to customize.

    5. Save the file.

  4. When your edits are complete, upload the edited migration plan:

    migctl migration update my-migration --main-config my-migration.yaml

You can now migrate the app. After you complete the migration for one app, edit the AppXGenerateArtifactsFlow object for each additional app in the VM that you want to migrate.

Select applications

On the migration plan, the application field represents the applications to migrate. If you do not want to migrate all applications, you can remove them.

- appName: hello-world-servlet-ear
  - httpPort: 9080
    httpsPort: 9443
    id: defaulthttpendpoint
    name: hello-world-servlet-ear
  path: /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/m4a-twas-ndNode01Cell/applications/Hello-World-Servlet.ear
- appName: commons-ejb-ear-provided-ear
  - httpPort: 9080
    httpsPort: 9443
    id: defaulthttpendpoint
    name: commons-ejb-ear-provided-ear
  path: /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/m4a-twas-ndNode01Cell/applications/commons-ejb-ear-provided.ear
  - /opt/IBM/WebSphere/AppServer/sharedJars/commons-io-2.8.0.jar

Set the scanner options

In the migration plan, the scannerOptions field represents the argument to pass to the IBM WebSphere Application Server Migration Toolkit for Application Binaries. You can edit the arguments.

  # Setting 'includeSensitiveData: true' will upload sensitive data, if exists, such as private keys, to the artifacts repository
  includeSensitiveData: false
  sourceAppServer: was90

What's next