Customizing a migration plan

You should review the migration plan file resulting from creating a migration, and customize it before proceeding to executing the migration. The details of your migration plan will be used to extract the workload container artifacts from the source VM.

This section describes the migration plan's contents and the kinds of customizations you might consider before you execute the migration and generate deployment artifacts.

Before you begin

  • This topic assumes that you've already created a migration and have the resulting migration plan file.

Editing the migration plan

Edit the migration plan by using the migctl tool or the GCP Console.


You must download the migration plan before you can edit it:

  1. Download the migration plan. The migration plan is represented by WindowsGenerateArtifacts:

    migctl migration get my-migration
  2. Edit the downloaded migration plan, my-migration.yaml, in a text editor.

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

    migctl migration update my-migration
  4. Repeat these steps if more edits are necessary.


You must download the migration plan, edit it, the apply it. The migration plan is represented by WindowsGenerateArtifacts:

  1. Get the name of the WindowsGenerateArtifacts:

    kubectl get -n v2k-system my-migration -o jsonpath={}

    The name is returned in the form windows-generate-artifacts-flow-id.

  2. Get the WindowsGenerateArtifacts by name and write to a file named my-plan.yaml:

    kubectl get -n v2k-system generate-artifacts-flow-id -o yaml > my-plan.yaml
  3. Edit the migration plan as necessary.

  4. Apply the file:

    kubectl apply -f my-plan.yaml


Edit the migration plan in the UI by using the YAML editor. The migration plan is represented by WindowsGenerateArtifacts:

  1. Open the Migrate for Anthos page in the Cloud Console.

    Go to the Migrate for Anthos page

  2. Click the Migrations tab to display a table containing the available migrations.

  3. In the row for the desired migration, select Review and edit migration plan in the Next steps dropdown.

  4. Edit the migration plan as necessary.

  5. When you are done editing, you can either:

    1. Save the migration plan. You then have to manually execute the migration to generate the migration artifacts using the procedure shown in Executing a migration.

    2. Save and generate the artifacts. Execute the migration by using your edits to generate the migration artifacts. The process is the same as described in Executing a migration. You can then monitor the migration as described in Monitoring a migration.

Configuring SSL

Because you cannot easily extract SSL certificates from a source VM, and it is not recommended to install SSL certificates and private keys in a Docker image, Migrate for Anthos provides several ways of handling SSL for Windows.

Use a self-signed auto-generated certificate

By default, a Windows container with an HTTPS binding is assigned a self-signed auto-generated certificate that is generated on the initialization of the Docker container. This configuration lets you test your migrated workload but cannot be used in a production environment because the certificate is both self-signed and re-generated every time the container is run.

You can customize the bindings in the migration plan to use HTTP, and then use Cloud Load Balancing, Ingress, or Anthos Service Mesh as an HTTPS frontend to secure external access. This option let you secure external communication without including any certificates inside the cluster.

To customize the binding, edit the site definition in the WindowsGenerateArtifacts that represents the migration to set protocol to http:

  - applications:
    - path: /
        - path: /
          physicalpath: '%SystemDrive%\inetpub\wwwroot'
          - port: 8080
            protocol: http
          name: Default Web Site

You can then forward requests from the HTTPS frontend to the HTTP path and port of the Windows workload.

Advanced - store SSL certificates as Kubernetes secrets

It is recommended that you use Cloud Load Balancing, Ingress, or Anthos Service Mesh as an HTTPS frontend to secure external access. However, you can also store SSL certificates as Kubernetes secrets and mount them at runtime into the container.

To use SSL certificates stored as Kubernetes secrets, you must edit the deployment image of the container. See Deploying a Windows workload to a target cluster for more.

Setting the Cloud Storage location for deployment artifacts

During migration, Migrate for Anthos uses Cloud Storage to store files that you'll later use to deploy the container on a production cluster. Use the folder option to change the bucket and folder names to use.

  folder: folder-name-and-bucket/

Setting the apppools and sites options

Set the apppools and sites options using the same syntax as you use for setting the corresponding options in IIS. See these links for more details:

Setting the useractions options

Set options under useractions in the form:

        - source: DRIVE:\FOLDER-OR-FILE-PATH
          target: DRIVE:\FOLDER-OR-FILE-PATH
        - source: C:\myfolder
          target: C:\myfolder
        - source: D:\myfile
          target: D:\myfile
        - source: D:\myfile
          target: C:\myfile
          - path: KEY
          - path: KEY

For files, the path to the file or folder on the migrated container is determined by the target DRIVE specification:

  • If the target drive is C, then the path is:

  • If the target drive is any value other than C, then the path is:


    For example:


The paths specified for currentcontrolset and software are to keys in the HKEY_LOCAL_MACHINE\System\CurrentControlSet registry hive or in the HKEY_LOCAL_MACHINE\Software registry hive.

Configuring migrated workloads to use gMSA

Windows VM workloads are often Active Directory (AD) joined and operate using domain identities. When migrating these VMs to containers, the containers themselves are not domain-joined, but rather their host Kubernetes cluster nodes can be domain-joined.

When you deploy your migrated containers to a cluster, you can use a Group Managed Service Account (gMSA) to execute the container under a specific service account identity. You attach a gMSA in the Kubernetes cluster as part of the pod configuration rather than as a static identity configuration inside the container image.

To support gMSA in a migrated Windows container, you must:

  1. Edit the migration plan to set the necessary properties to configure the migrated container to use a gMSA. This configuration process is described below.

  2. Configure the processing cluster that hosts the deployed container to support gMSA. See Deploying a Windows workload to a target cluster for more.

About gMSA

You can find a more information about gMSA in the Google Cloud documentation and in other documentation sets. For example, see:

Supporting gMSA in Migrate for Anthos

When migrating workloads from VMs to Windows containers, you must transform any IIS configuration and other Windows services configured to use AD identities. This transformation is required for each Windows source VM.

Migrate for Anthos helps you in the process of transforming your workloads by automatically discovering the configuration of IIS application pools and adding recommendations to the generated migration plan. You can then evaluate these recommendations and modify them for your specific environment and requirements.

If Migrate for Anthos determines that the configuration of an application pool does not require a gMSA, then it maintains the original application pool configuration. For example, when it uses a built-in account types such as ApplicationPoolIdentity, NetworkService, LocalSystem, or LocalService.

Editing the migration plan to configure gMSA

Migrate for Anthos adds the following properties, with recommended values, to the generated migration plan. You can then modify them as necessary to control gMSA:

  • enablegmsa: Supported values:

    • auto (default): Convert the migrated container to use gMSA if Migrate for Anthos determines that its current configuration is not allowed.
    • all: Always convert the migrated container to use gMSA and ignore the setting of identitytype. In this case, identitytype is always interpreted as being set to NetworkService.
  • identitytype: Specifies the IIS identity of an application pool as either ApplicationPoolIdentity (default), NetworkService, LocalSystem, or LocalService. See Understanding identities in IIS and Application Pool Identities for more.

    A container is typically given a single gMSA. This means you typically set identitytype to NetworkService to use the gMSA identity. See Configure your app to use a gMSA for more.

Shown below is an example migration plan containing enablegmsa and identitytype:

        # Allowed values include: auto (default), all
        enablegmsa: auto|all
          - name: DefaultAppPool
            # Allowed values include: ApplicationPoolIdentity (default), NetworkService, LocalSystem, LocalService
          - managedruntimeversion: v4.0
            name: .NET v4.5 Classic
          - managedruntimeversion: v4.0
            name: .NET v4.5

Generating artifacts for supporting gMSA

When you execute the migration plan to generates the container artifacts, Migrate for Anthos automatically adds the necessary Dockerfile directives to assign the NetworkService account as described in Configure your app to use a gMSA.

For example, if you set identitytype to NetworkService the directive is in the form:

RUN c:\windows\system32\inetsrv\appcmd.exe set apppool \"DefaultAppPool\" \"/-processModel.identityType:NetworkService\";

For the application file system items, such as directories and files, where the original application identity account was specified either by inheritance or explicitly, Migrate for Anthos automatically adds read ACL directives to the site's folders according to the target identitytype, and for the IUSR built-in user. See Setting ACLs for more on setting ACLs.

Next Steps