Step 1: Confirm the VPC and subnets

You select the VPC and subnets for the VPC cluster. If you do not select a VPC, a new VPC is created in the same region as your Classic cluster during the Create step. If you want to use a specific VPC or different subnets per zone, note the IDs now — you will pass them as overrides in the Create phase.

Step 2: Confirm worker pool flavors

The metadata generator maps each Classic worker pool flavor to an equivalent VPC flavor. Review the workerPools[].machineType fields in the VPC metadata that was generated in the assess phase to verify the proposed mappings are appropriate for your workloads. The metadata is stored in your COS instance as {clusterID}_vpc.json.

1. List available VPC flavors in your target zone to compare against the proposed mapping:

   ibmcloud oc flavors --zone VPC_ZONE --provider vpc-gen2
   

   Example output:

   Name        Cores   Memory   Network Speed   OS             Server Type   Storage   Secondary Storage   Provider
   bx2.2x8     2       8GB      24Gbps          UBUNTU_20_64   virtual       100GB     -                   vpc-gen2
   bx2.4x16    4       16GB     24Gbps          UBUNTU_20_64   virtual       100GB     -                   vpc-gen2
   bx2.8x32    8       32GB     24Gbps          UBUNTU_20_64   virtual       100GB     -                   vpc-gen2
   bx2.16x64   16      64GB     24Gbps          UBUNTU_20_64   virtual       100GB     -                   vpc-gen2
   

If you need a different flavor for a worker pool, note the pool name and the desired flavor — you will supply this as a workerPoolOverride in the create step.

Step 3: Review your network policies

The migration service does not migrate Global Network Policies (GNPs). Moving them to VPC security groups is your responsibility. The migration service migrates only namespace-scoped Kubernetes and Calico network policies, as part of the workload migration step. Review your policies now so you can plan any manual steps.

1. List the Global Network Policies on your Classic cluster so that you can re-create them as VPC security group rules:

   oc get globalnetworkpolicies -o yaml
   

For more information, see Which network policies are migrated?. To create equivalent rules in VPC, see Controlling traffic with VPC security groups.

VPC security groups have a maximum of 250 rules. Consolidate rules as needed when you re-create your GNPs.

Step 4: Plan private connectivity

The migration service does not migrate on-premises network connectivity. If your Classic cluster connects to on-premises networks using Classic VPN or Direct Link 1.0, you must set up the equivalent VPC connectivity before you start workload migration so that pods on the VPC cluster can reach on-premises resources immediately after migration.

Review the following VPC equivalents and complete the setup independently before proceeding to the Create step:

If your application load balancers rely on source IP preservation (for example, for IP allowlisting), only VPC NLBs support source IP preservation in VPC. Plan to annotate the relevant Services with service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb on the VPC cluster.

Step 5: Plan the Ingress migration

Classic clusters use an IBM-managed Ingress subdomain under containers.appdomain.cloud. VPC clusters use a separate subdomain. The migration plan (created in the Migrate step) generates the VPC Ingress host mappings for each existing Ingress resource. Plan to update your external DNS records at cutover time.

At cutover, update all of the following that reference the Classic Ingress hostname:

• Kubernetes Ingress resources on the VPC cluster
• Application configuration files and environment variables
• CI/CD pipeline configurations (for example, GitHub Actions workflows, Tekton pipelines)
• Any external monitoring or synthetic test endpoints

Lower your external DNS TTLs to 60–300 seconds before the planned cutover window so propagation is fast.

Next steps

Create the VPC cluster