One of the migration patterns that shows up reliably on the Professional Cloud Architect exam is the question that pits two competing goals against each other. You want to get on-prem VMs into Google Cloud quickly. You also want them ending up in separate projects with proper network isolation. Trying to do both at once is where migrations go off the rails.
The expected answer in this kind of question is a phased migration. Move the workloads first into a single project with a single VPC. Reorganize into a Shared VPC topology with separate service projects after the workloads are stable. The Professional Cloud Architect exam treats this two-phase approach as the canonical pattern for handling the conflict between speed and isolation.
The temptation in a migration is to land in the target architecture on day one. Every workload in its correct project, every network boundary set up the way it will look in production, IAM and firewall rules already aligned with the long-term design. That is appealing on paper. In practice it stretches the migration timeline because you are doing two hard things at the same time: lifting workloads off the source environment, and standing up a new multi-project network architecture in the target.
A phased migration acknowledges that those are two different problems. The first phase is operational: get the VMs out of the data center and running on Google Cloud with as little new complexity as possible. The second phase is architectural: now that the workloads are stable, reorganize them into the target Shared VPC topology without touching the actual network configuration that they depend on.
When the exam describes this kind of scenario, it is usually testing whether you recognize that splitting these phases is the right move. The wrong answers will typically have you doing the full Shared VPC setup before the workloads have arrived, which conflates the two problems.
In Phase One you create a single Google Cloud project with a VPC network inside it. Every workload coming over from on-prem lands in that project on that VPC. Workload A, Workload B, Workload C all sit together in one place. Subnets, firewall rules, routes are all defined once.
This is intentionally simple. The migration team focuses on the actual lift: replicating disks, cutting over DNS, validating that applications run correctly on Google Cloud. They do not have to also decide which workload belongs in which project, how to route traffic between projects, how IAM should be split. Those decisions get deferred to Phase Two.
The exam wording for Phase One is usually some version of getting workloads to the cloud quickly with minimal complexity. If you see that phrase or close to it in a question, the answer is going to involve a single project and a flat VPC, not a multi-project topology.
The reorganization in Phase Two is more elegant than it sounds. The original project does not get torn down. It gets converted into the Shared VPC host project. The VPC network inside it stays exactly as it was. Subnets are preserved. Firewall rules are preserved. Routes are preserved. None of the network plumbing that the workloads depend on changes.
What does change is where the VM workloads live. You create new service projects, one per workload or per environment depending on the design. Workload A moves to Service Project A. Workload B moves to Service Project B. Workload C moves to Service Project C. Each service project attaches to the host project's VPC, so the workloads still see the same network they were running on before. The boundary that gets introduced is at the project level: separate IAM, separate quotas, separate billing visibility, separate blast radius for project-level mistakes.
The reason this works cleanly is that Shared VPC was designed for exactly this pattern. Service projects share the host project's network without owning it. From inside a VM, the network looks the same whether the VM lives in the host project or in a service project that is attached to it. So you can rearrange the project structure without touching the network configuration that applications and connectivity depend on.
The shape of the question is consistent. A company is migrating a set of workloads from on-prem to Google Cloud. They want to eventually have separate environments or separate projects with proper isolation. They are also under time pressure and need the migration done. What should they do?
The correct answer pairs the two phases. Migrate into a single project first to get the workloads onto Google Cloud. Then reorganize into a Shared VPC architecture with service projects. The distractors usually fall into one of two buckets. Some try to do the full multi-project Shared VPC setup as part of the initial migration, which is the slow option. Others skip the reorganization entirely and leave everything in a single project forever, which fails the long-term isolation requirement.
Both distractors miss the point that you can have both, just not at the same time. Speed first, then isolation. The phased approach is the answer because it is the only one that satisfies both constraints.
The Phase Two move is sometimes described as creating new projects and setting up the Shared VPC from scratch, with the workloads then redeployed into the new architecture. That framing is wrong for this exam pattern. You do not redeploy. The host project is the original migration project, with the same VPC. The service projects are new, but the workloads move into them rather than being rebuilt. That is what makes the reorganization low-risk: the network does not change, and the workloads do not get redeployed, so there is nothing in the cutover that should break a running application.
If a question's correct-looking answer has you tearing down the network and rebuilding it as part of Phase Two, that is a flag. The expected answer preserves the VPC and just changes the project topology around it.
My Professional Cloud Architect course covers Shared VPC phased migrations alongside the rest of the advanced architecture material.
