Every landing zone tutorial starts the same way: a pristine, empty organization. Real life rarely cooperates. Most teams arrive at the landing zone conversation two or three years in, with a dozen projects created by hand, a flat resource hierarchy, service account keys scattered across CI systems, and a production GKE cluster nobody wants to touch. This is the brownfield problem — and the good news is that retrofitting a landing zone onto a live estate is entirely doable if you respect one rule: the folder move is the easy part; the inheritance is where things break.

What a Landing Zone Actually Changes

Strip away the vendor language and a landing zone is four things: a folder hierarchy that separates prod from everything else, org policies that act as guardrails, group-based IAM that flows down from folders, and a Shared VPC (or hub network) that workloads attach to instead of owning their own networking. None of these are exotic — but every one of them changes behavior the moment an existing project moves into the hierarchy. That is what makes brownfield migration a sequencing problem rather than a technology problem.

Step 1: Audit Before You Move Anything

Moving a project into a folder is a single command. What happens next is that every org policy and IAM binding on that folder chain applies to the project immediately. So before touching anything, build a diff of what will change. Three policies cause the vast majority of brownfield pain:

  • iam.disableServiceAccountKeyCreation — existing keys keep working, but nothing can mint new ones. Any workload that rotates its own keys silently breaks on the next rotation. Inventory keys first: gcloud iam service-accounts keys list across every SA, and hunt down what created them.
  • iam.allowedPolicyMemberDomains — existing external members survive the move, but you can never re-grant them. If a contractor on a personal Gmail account holds access, the first IAM change after migration turns into an incident.
  • compute.requireOsLogin — instantly changes how humans SSH into existing VMs. If the team relies on project-wide SSH keys, access patterns break the moment inheritance kicks in.

Diff the effective IAM too. Folder bindings mean developers may suddenly gain editor on nonprod or lose direct access to prod. That is usually the goal — but it should happen on a date everyone knows about, not as a surprise.

Step 2: The Move Itself Is One Command

Once the audit is clean, the mechanics are almost anticlimactic:

gcloud beta projects move MY_PROJECT \
    --folder=FOLDER_ID

You need resourcemanager.projectMover on both the source and the destination. Cross-organization moves are a different beast entirely — heavier permissions, both orgs involved, and a formal migration flow — so this article assumes you are reorganizing within one org, which covers most brownfield cases.

Immediately after the move, import the project into Terraform so it never drifts back to hand-managed:

terraform import google_project.legacy_app MY_PROJECT

Step 3: Networking Is the Real Migration

Here is the part the diagrams gloss over: moving a project into a folder does nothing to its network. The legacy VPC, its subnets, its firewall rules — all still there, still owned by the project. Getting onto the Shared VPC is a workload migration, not a flag flip.

The pattern that works: attach the legacy project to the Shared VPC host as a service project, so it can see both networks at once.

resource "google_compute_shared_vpc_service_project" "legacy" {
  host_project    = "acme-net-prod"
  service_project = "legacy-app-prod"
}

Then migrate by workload type, in order of difficulty:

  • Plain VMs — a stopped instance can switch its NIC to a Shared VPC subnet. Downtime is minutes per VM. Watch for hardcoded internal IPs.
  • Managed instance groups — roll a new template pointing at the shared subnet and let the MIG replace instances gradually. Near-zero downtime.
  • GKE clusters — the hard one. A cluster's network is immutable. The only path is a new cluster on the Shared VPC subnets (with secondary ranges planned for pods and services) and a blue/green cutover via DNS or your ingress layer. If you are running GitOps, this is where ArgoCD ApplicationSets earn their keep: point them at the new cluster and let the entire workload graph rebuild itself.

One planning detail that saves months later: make sure the Shared VPC ranges do not overlap the legacy VPC ranges. During the transition you will want VPC peering or at least routes between old and new, and overlapping CIDRs kill that option instantly.

Step 4: Decommission Deliberately

The legacy VPC does not die on cutover day. Internal DNS entries, firewall rules referencing old ranges, VPN tunnels terminating on old gateways — these linger. Give the old network a formal end-of-life date, alert on any remaining traffic through it (VPC Flow Logs make this trivial), and only delete it when the flow logs have been silent for a full business cycle. Deleting a "dead" VPC that still carries one forgotten batch job is a rite of passage nobody needs.

A Realistic Sequencing Plan

  1. Stand up the landing zone skeleton — folders, org policies, Shared VPC — with zero existing projects in it
  2. Run the org-policy and IAM audit against every legacy project; fix key rotation and external members first
  3. Move the lowest-risk nonprod project, watch it for a week
  4. Move remaining nonprod, then prod projects — folder moves only, no network changes yet
  5. Attach projects to the Shared VPC and migrate workloads: VMs, then MIGs, then GKE blue/green
  6. Decommission legacy VPCs on evidence, not optimism

Each step is independently reversible except the GKE cutover — which is exactly why it goes last, after the team has built confidence with everything else.

Conclusion

A brownfield landing zone migration is not one project — it is two. The first is organizational: folders, policies, and IAM, which lands in days if the audit is honest. The second is a network migration wearing a landing zone costume, and it deserves the same respect as any production network change. Teams that treat these as separate workstreams with separate timelines ship both. Teams that treat "move to the landing zone" as one big-bang ticket end up rolling back on a Friday night. Sequence it, audit first, and let the folder hierarchy do its job — the guardrails are worth every bit of the effort.