From the console

1. Open the migration wizard. Go to Migration hub > Clusters > Eligible clusters and click Open wizard for your Classic cluster. Alternatively, go to Containers > Clusters and select Migrate to VPC in the row actions.
2. On the Assess step, under Assessment, select your Cloud Object Storage instance from the dropdown. If you do not have a COS instance, click Create + to provision one.
3. Click Assess configurations. The button changes to a spinner with the message Running assessment while the metadata is being generated.
4. When the assessment completes, the status updates to Assessment complete. If the assessment fails, a banner displays the error — resolve the indicated IAM permissions issue and click Assess configurations again.
5. Review the VPC cluster preview panel. It shows the proposed values for Infrastructure, Worker Pools, Private & Public Endpoint, Outbound traffic, CIDR (IP range), and Resource group.
6. Optionally, click Compare clusters to open a side-by-side comparison of your Classic cluster and the proposed VPC cluster configuration.
7. Before you create the VPC cluster, review Plan your VPC environment.

From the CLI

Run the following commands to generate and inspect the VPC metadata for your Classic cluster.

1. Generate the VPC metadata for your Classic cluster. Replace CLUSTER_ID with your Classic cluster ID and COS_CRN with the CRN of your COS instance.

   ibmcloud oc replatform cluster assess --cluster-id CLUSTER_ID --cos-instance-crn COS_CRN
   

   When the command completes, the metadata files are written to your COS instance.

2. Review the generated VPC configuration. Replace CLUSTER_ID with your Classic cluster ID.

   ibmcloud oc replatform cluster get --cluster-id CLUSTER_ID
   

   Example output:

   VPC name:        mig-my-classic-cluster
   Region:          us-south
   Worker pools:
     default        bx2.4x16   2/zone   us-south-1, us-south-2
   Add-ons:
     cluster-autoscaler   1.2.1
   KMS instance CRN:  (none)
   

   Confirm that the region, worker pool flavors, add-ons, and KMS settings match your expectations before you proceed.

From the API

1. Call the generateVPCMetadata mutation. Replace CLUSTER_ID with your Classic cluster ID and COS_INSTANCE_ID with the ID from your COS instance CRN.

   mutation GenerateMeta($input: GenerateVPCMetadataInput!) {
     generateVPCMetadata(input: $input) {
       classic {
         ID name region masterVersion numberOfWorkers
         workerZones state status EOS
       }
       vpcMeta {
         VPCID name region version type
         vpcSubnetIDs { key value }
         workerPools {
           name machineType sizePerZone operatingSystem zones
           secondaryStorageOption secondaryStorageSize
         }
         addOns { name version }
         disablePSE
         keyManagementService {
           desiredInstanceCRN desiredRootKeyID
         }
       }
     }
   }
   

   {
     "input": {
       "clusterID":      "CLUSTER_ID",
       "cosInstanceCRN": "crn:v1:bluemix:public:cloud-object-storage:global:a/ACCOUNT_ID:COS_INSTANCE_ID::"
     }
   }
   

   Send the request:

   curl -X POST https://REGION.containers.cloud.ibm.com/graphql \
     -H "Authorization: Bearer $(ibmcloud iam oauth-tokens --output json | jq -r '.iam_token')" \
     -H "Content-Type: application/json" \
     -d '{"query":"mutation GenerateMeta($input:GenerateVPCMetadataInput!){generateVPCMetadata(input:$input){classic{ID name region masterVersion}vpcMeta{name region}}}","variables":{"input":{"clusterID":"CLUSTER_ID","cosInstanceCRN":"COS_CRN"}}}'
   

   Example response:

   {
     "data": {
       "generateVPCMetadata": {
         "classic": {
           "ID": "abc123xyz456",
           "name": "my-classic-cluster",
           "region": "us-south",
           "masterVersion": "1.34.1_1601"
         },
         "vpcMeta": {
           "name": "mig-my-classic-cluster",
           "region": "us-south"
         }
       }
     }
   }
   

2. Query the generated VPC configuration and confirm that region, workerPools, addOns, and keyManagementService match your expectations. Replace CLUSTER_ID with your Classic cluster ID.

   query GetVPCMeta($id: ID!) {
     node(id: $id) {
       id
       ... on KubernetesCluster {
         vpcMigration {
           vpcMeta {
             VPCID name region version
             vpcSubnetIDs { key value }
             workerPools {
               name machineType sizePerZone operatingSystem zones
             }
             addOns { name version }
             keyManagementService { desiredInstanceCRN desiredRootKeyID }
           }
         }
       }
     }
   }
   

   { "id": "CLUSTER_ID" }
   

   Example response:

   {
     "data": {
       "node": {
         "id": "abc123xyz456",
         "vpcMigration": {
           "vpcMeta": {
             "VPCID": "r006-1a2b3c4d-5e6f-7890-abcd-ef1234567890",
             "name": "mig-my-classic-cluster",
             "region": "us-south",
             "version": "1.34",
             "vpcSubnetIDs": [
               { "key": "us-south-1", "value": "0717-subnet-aaa" },
               { "key": "us-south-2", "value": "0727-subnet-bbb" }
             ],
             "workerPools": [
               {
                 "name": "default",
                 "machineType": "bx2.4x16",
                 "sizePerZone": 2,
                 "operatingSystem": "REDHAT_8_64",
                 "zones": ["us-south-1", "us-south-2"]
               }
             ],
             "addOns": [
               { "name": "cluster-autoscaler", "version": "1.2.1" }
             ],
             "keyManagementService": {
               "desiredInstanceCRN": "",
               "desiredRootKeyID": ""
             }
           }
         }
       }
     }
   }
   

From the console

After the assessment completes, the VPC cluster preview panel shows the Worker Pools count. To see the full list of add-ons detected on your Classic cluster, click Compare clusters and review the Add-ons section in the side-by-side comparison panel. Compare the add-ons listed against the add-on migration behavior table.

From the CLI

1. List the add-ons installed on your Classic cluster:

   ibmcloud oc cluster addon ls --cluster CLUSTER
   

   Example output:

   Name                   Version   Health State   Health Status
   cluster-autoscaler     1.2.1     normal         Addon Ready
   image-key-synchronizer 4.16.0    normal         Addon Ready
   static-route           1.0.0     normal         Addon Ready
   

2. Compare the installed add-ons against the add-on migration behavior table.

From the API

The generateVPCMetadata response includes an addOns array in the vpcMeta object. Compare the add-ons listed in that response against the add-on migration behavior table.

From the console

1. From the IBM Cloud console, click your Classic cluster.
2. Click Storage in the left navigation menu.
3. Review the list of persistent volume claims. Note the Storage class for each PVC — you will map each Classic storage class to a VPC equivalent when you create the migration plan.

From the CLI

List all PVCs on your Classic cluster so that you can plan your storage class mappings before the Migrate step.

1. List all PVCs across namespaces. Note the storage class of each PVC — you will map each Classic storage class to a VPC equivalent in the Migrate step.

   oc get pvc --all-namespaces
   

   Example output:

   NAMESPACE    NAME              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS        AGE
   production   my-block-pvc      Bound    pvc-a1b2c3d4-e5f6-7890-abcd-ef1234567890   20Gi       RWO            ibmc-block-gold     45d
   production   my-file-pvc       Bound    pvc-b2c3d4e5-f6a7-8901-bcde-f12345678901   10Gi       RWX            ibmc-file-silver    45d
   staging      app-data-pvc      Bound    pvc-c3d4e5f6-a7b8-9012-cdef-123456789012   50Gi       RWO            ibmc-block-bronze   12d
   

The migration plan generated in Migrate workloads provides the storage class mappings, which you can override per PVC.

From the API

List all PVCs on your Classic cluster so that you can plan your storage class mappings before calling startWorkloadMigration.

1. List all PVCs across namespaces on your Classic cluster. Note the storage class of each PVC — you will pass storage class mappings in the startWorkloadMigration mutation during the Migrate step.

   curl -X GET https://REGION.containers.cloud.ibm.com/v1/clusters/CLASSIC_CLUSTER_ID/config \
     -H "Authorization: Bearer $(ibmcloud iam oauth-tokens --output json | jq -r '.iam_token')"
   

   Alternatively, query the cluster directly using kubectl with the retrieved kubeconfig:

   oc get pvc --all-namespaces --output json | jq '[.items[] | {namespace: .metadata.namespace, name: .metadata.name, storageClass: .spec.storageClassName, capacity: .spec.resources.requests.storage}]'
   

   Example output:

   [
     { "namespace": "production", "name": "my-block-pvc", "storageClass": "ibmc-block-gold",   "capacity": "20Gi" },
     { "namespace": "production", "name": "my-file-pvc",  "storageClass": "ibmc-file-silver",  "capacity": "10Gi" },
     { "namespace": "staging",    "name": "app-data-pvc", "storageClass": "ibmc-block-bronze",  "capacity": "50Gi" }
   ]
   

The createMigrationPlan response includes proposed storageClassNameMappings for each PVC. You can override any mapping when calling startWorkloadMigration.