--- name: openshift-vpc-migrate-plan title: Plan your VPC environment description: Review and adjust the VPC configuration generated by the assessment before you provision the VPC cluster. In most cases the auto-generated configuration is ready to use without modification. Use this topic to verify the proposed topology, understand how network policies are handled, plan private connectivity, and lower DNS TTLs before cutover. last-updated: 2026-11-02 --- > ## Documentation Index > The table of contents for this documentation set is at https://cloud.ibm.com/docs/openshift?format=markdown > The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt > Use these files to discover more information as needed. # Plan your VPC environment {: #vpc-migrate-plan} [Classic infrastructure]{: tag-classic-inf} Review and adjust the VPC configuration generated by the assessment before you provision the VPC cluster. In most cases the auto-generated configuration is ready to use without modification. Use this topic to verify the proposed topology, understand how network policies are handled, plan private connectivity, and lower DNS TTLs before cutover. {: shortdesc} The assessment step generates a proposed VPC configuration based on your Classic cluster. Review the following areas before you click **Create VPC cluster** in the migration wizard, and make any adjustments directly in the cluster creation form if needed. ## Step 1: Confirm the VPC and subnets {: #vpc-migrate-plan-vpc} 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](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-migrate-create&format=markdown). ### From the console {: #vpc-migrate-plan-vpc-ui} {: ui} In the migration wizard, you select the VPC and subnets in the **Create VPC cluster** form. If you do not select a VPC, a new VPC is created in the same region as your Classic cluster. 1. In the wizard, navigate to the **Create** step and click **Create VPC cluster** to open the cluster creation form. 2. Under **Networking**, select the **Virtual private cloud** and the **Subnet** for each zone. 3. To use an existing VPC or subnet, click the dropdown for that field and select from the available options. Only VPCs and subnets in the same region as your Classic cluster are shown. 4. For high availability, ensure subnets are selected in at least two zones. For a multizone cluster, you need one subnet per zone. ### From the CLI {: #vpc-migrate-plan-vpc-cli} {: cli} 1. List the available VPCs in your account: ```sh ibmcloud is vpcs ``` {: pre} Example output: ```text ID Name Status Classic access Default network ACL Default security group Resource group r006-1a2b3c4d-5e6f-7890-abcd-ef1234567890 my-migration-vpc available false acl-a1b2c3d4 sg-b2c3d4e5 default r006-2b3c4d5e-6f7a-8901-bcde-f12345678901 another-vpc available false acl-b2c3d4e5 sg-c3d4e5f6 production ``` {: screen} 2. List available subnets, filtering by your resource group: ```sh ibmcloud is subnets --resource-group-name RESOURCE_GROUP ``` {: pre} Example output: ```text ID Name Status Subnet CIDR Addresses ACL Public gateway VPC Zone 0717-aaaa1111-bbbb-2222-cccc-3333dddd4444 subnet-us-south-1 available 10.240.0.0/24 245/256 acl-a1b2c3d4 - my-migration-vpc us-south-1 0727-bbbb2222-cccc-3333-dddd-4444eeee5555 subnet-us-south-2 available 10.240.64.0/24 245/256 acl-a1b2c3d4 - my-migration-vpc us-south-2 ``` {: screen} For high availability, ensure subnets exist in at least two zones. For a multizone cluster, you need one subnet per zone. Use the following minimum recommended subnet sizing: - `/26` (64 addresses) per zone for small clusters - `/24` (256 addresses) per zone for production workloads ## Step 2: Confirm worker pool flavors {: #vpc-migrate-plan-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: ```sh ibmcloud oc flavors --zone VPC_ZONE --provider vpc-gen2 ``` {: pre} Example output: ```text 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 ``` {: screen} 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 {: #vpc-migrate-plan-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: ```sh oc get globalnetworkpolicies -o yaml ``` {: pre} For more information, see [Which network policies are migrated?](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-migrate-overview&format=markdown#vpc-migrate-overview-limitations-networking). To create equivalent rules in VPC, see [Controlling traffic with VPC security groups](https://cloud.ibm.com/docs/vpc?topic=vpc-using-security-groups&format=markdown){: external}. VPC security groups have a maximum of 250 rules. Consolidate rules as needed when you re-create your GNPs. {: note} ## Step 4: Plan private connectivity {: #vpc-migrate-plan-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: | Classic | VPC equivalent | |---------|---------------| | Classic VPN | [VPC VPN gateway](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-create-gateway&format=markdown) | | Direct Link 1.0 | [Direct Link 2.0](https://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dl&format=markdown) | | Multiple classic clusters on same private VLAN | Multiple VPC clusters in the same VPC (native private connectivity) | | Hybrid classic + VPC connectivity | [Transit Gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-getting-started&format=markdown) | {: caption="Classic to VPC private connectivity equivalents" caption-side="bottom"} 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. {: note} ## Step 5: Plan the Ingress migration {: #vpc-migrate-plan-ingress} 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 {: #vpc-migrate-plan-next} [Create the VPC cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-migrate-create&format=markdown)