Customize migration plan for WebSphere traditional workloads

Important: The websphere-traditional plugin is now deprecated. For existing customers, this plugin 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.

Important: 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.

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:

   app-name.ear_MigrationReport.html

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.

      Note: Ensure that you first save a copy of the original AppXGenerateArtifactsFlow object so that you can later migrate any other apps in the VM.

      The AppXGenerateArtifactsFlow object lists all apps in the form:

      spec:
      appBinariesMigrationToolkit:
        applications:
        -  path: "PATH_TO_APP1"
          sharedLibraries:
          - sharedLibrary1
            sharedLibrary2
        -  path: "PATH_TO_APP2"
          sharedLibraries:
          - 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.

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

      MM-DD-YYYY--hh:mm:ss

      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"

      Note: Because the tag is used to cache values, ensure that the tag is unique for all CRDs.

   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.

applications:
- appName: hello-world-servlet-ear
  httpEndpoints:
  - httpPort: 9080
    httpsPort: 9443
    id: defaulthttpendpoint
  image:
    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
  httpEndpoints:
  - httpPort: 9080
    httpsPort: 9443
    id: defaulthttpendpoint
  image:
    name: commons-ejb-ear-provided-ear
  path: /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/m4a-twas-ndNode01Cell/applications/commons-ejb-ear-provided.ear
  sharedLibraries:
  - /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.

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

Note: In order to collect sensitive data, in the migration plan, under scannerOptions, modify the value of includeSensitiveData: to be true. Notice that set includeSensitiveData: true will cause uploading sensitive artifacts into the user repository. On liberty and openliberty, the sensitive data will be stored in a secret file artifact that is used when building app container.

What's next

• Learn how to execute the migration.