TL;DR

An AWS-to-GCP migration required us to expand an existing analytics environment into a governed cloud foundation. I led the landing zone effort, using Cloud Foundation Fabric FAST for bootstrap, then built a Terraform project factory that three teams in my department could operate through configuration files and plan review. The broader migration met its deadline and reduced costs. The factory cut hands-on effort per project from about an hour to ten minutes, and existing application workloads continued running throughout the transition.

The Problem

What we inherited

Our GCP organization existed for one reason: Google Analytics for our applications. The application development team had created it, owned it, and used it well for their purposes. The migration introduced broader requirements for platform ownership, access governance, and repeatable provisioning.

When I assessed it, here’s what I found:

  • About ten projects, created by hand at the organization root, without consistent naming, structure, or a project ownership model.
  • IAM needed review. Access had accumulated without a consistent review process. Some bindings needed narrower scope or removal, and ongoing access governance needed an owner.
  • A single flat VPC, requiring a new network design for the migration.
  • A single billing account, which would remain the case.
  • Manual provisioning, with no infrastructure-as-code workflow.

Why now

The trigger was financial. The business decided to migrate a substantial set of workloads from AWS to GCP, primarily to reduce cost. Leadership assigned engineering to own the GCP organization, assess it, and prepare it for the incoming production workloads.

That reframed the whole thing. This wasn’t a cleanup project. It was a migration prerequisite with a hard date attached.

The constraints that shaped every decision

Greenfield would have been easier. It wasn’t an option.

Constraint Consequence
Fixed migration deadline Ruled out building a fresh org and migrating the application development team into it. We had to reuse the existing organization.
The application development team’s projects were business-critical We deferred hierarchy changes to limit disruption to existing workloads.
Single billing account Project provisioning had to use the existing billing arrangement.
Limited Terraform skills across teams Provisioning needed a supported configuration interface that engineers could use without authoring modules.
Distributed ownership Networking, security, and application teams owned different layers. The operating model had to work across those boundaries.

The last two constraints turned out to matter more than any technical one.

What I Built

Choosing Fabric FAST

I worked directly with our Google account team to evaluate landing zone approaches. Our stated goal was to automate the entire deployment, not just document it, and to leave the organization in a state where IaC was the default going forward. Cloud Foundation Fabric FAST was the best fit for that goal: opinionated, stage-based, and Terraform end to end.

How we used FAST

We used FAST to establish the foundation in weeks within an organization that already hosted business-critical projects. These were the main parts of that work.

Organization bootstrap. This gave us the foundation: automation service accounts, state buckets, the organization-level IAM baseline, and the folder skeleton.

Organization policies: established a baseline. We adopted FAST’s recommended set and added constraints identified with our security team.

During the organization-level rollout, the application team experienced a console-access disruption. Production workloads continued running, and no analytics data was lost. We worked with the team to establish appropriately scoped access. Preserving workload availability was essential, but the administrative disruption mattered too. My lesson was to include administrative workflows and access recovery explicitly in rollout planning alongside workload continuity.

Networking: shaped by the network team’s design. The topology and operating tradeoffs are described below.

Project factory: used briefly, then replaced. We chose to use FAST for bootstrap and a separate factory for ongoing project provisioning. The FAST operating model we evaluated needed sustained Terraform ownership across foundation layers. Our organization had distributed ownership and uneven Terraform experience, so we narrowed the ongoing automation scope to what my department could maintain.

I initially advocated for broader adoption and offered cross-training. The decision clarified an important requirement: automation needed an enduring operating owner. I focused on building a project factory my department could support and training engineers to use it.

The custom project factory

I wrote a module-based Terraform project factory scoped to the provisioning my department owned. Provisioning engineers supplied project configuration and reviewed plans; module maintainers owned the implementation.

How a team consumes it:

  1. A GitLab project is created from a template that references the project factory modules.
  2. Provisioning engineers fill out a tfvars file, the configuration interface for requesting a project.
  3. A GitLab CI pipeline runs terraform plan. Engineers I cross-trained review the plan output and confirm the resources match the request.
  4. Only after plan review does apply run.

What each project gets, automatically:

  • Project creation and billing account assignment
  • Service account and IAM bindings
  • Shared VPC attachment
  • Required API enablement
  • Workload Identity Federation configuration for authentication without service account keys
  • Project-level organization policies

The design principle was deliberate: centralize implementation in the modules and expose project configuration through tfvars. The constrained interface reduced configuration variability, while plan review provided a checkpoint before changes were applied. Module correctness and reviewer judgment still mattered. This let engineers provision through a supported interface without having to author Terraform modules.

Networking: balancing delivery and ongoing operations

Our network department owned the design. They chose a hub-and-spoke topology with a network virtual appliance (NVA) providing centralized inspection for north-south and east-west traffic. Dedicated Interconnect provided connectivity to our on-premises sites. The design prioritized existing operational expertise and inspection tooling.

The factory attached projects to Shared VPC. The design discussion centered on routing and inspection: I advocated for native routing and managed controls such as Cloud NGFW where inspection was needed. The selected design retained centralized appliance inspection to support migration readiness and the network team’s operating model.

Our implementation required extensive static routing and custom configuration to steer traffic through the appliance. That added integration work when onboarding cloud services. Those costs belong to the implementation we selected; they are not inherent to every NVA-based architecture.

My responsibility was to deliver within that design and document the integration costs for future architecture reviews. The experience reinforced that operational familiarity, delivery dates, and ongoing maintenance all belong in the same design decision.

The Result

Metric Outcome
Migration deadline Met
Cost of migrated workloads Reduced
Projects provisioned through the factory Hundreds
Hands-on effort per project provisioned ~1 hour → ~10 minutes
Organization policies enforced Dozens
Access governance Reviewed existing access and established scoped permissions
Teams within my department provisioning through the factory 3
Existing application workload downtime during the transition None

The migration deadline and cost reduction were shared outcomes of the broader migration effort. My direct contribution was the landing zone and provisioning capability that supported it.

The provisioning improvement is the result I can most directly connect to the factory. Reducing hands-on effort from about an hour to ten minutes per project removed repeated manual work across hundreds of projects. Three teams in my department adopted the workflow, with positive feedback on the configuration interface.

What I’d Do Differently, and What’s Still Unfinished

I’d evaluate the Enterprise foundations blueprint earlier

Knowing what I know now, I would evaluate the Enterprise foundations blueprint earlier when planning the foundation and its operating model. I return to its architecture guidance frequently as we plan further automation. FAST was useful for our bootstrap; the Blueprint has been useful as a reference for planning work across independently owned layers.

Remaining work

Further work will focus on extending automation across foundation layers and bringing legacy projects into the target hierarchy. The goal is to build on the factory’s repeatable provisioning model with clear ownership and a supported change process for each layer.

Creating resources with Terraform during bootstrap is only the beginning. Sustaining that foundation requires teams to own its ongoing IaC workflow. Documenting integration and maintenance costs also provides evidence for future architecture reviews.

Takeaways

  1. Brownfield means your constraints are the architecture. Every decision here traces back to a deadline, an existing tenant, or a skills gap. Document those as carefully as the technical design.
  2. Bootstrap opinionated; operate pragmatically. FAST gave us a strong foundation in weeks. A simpler, module-based factory was what our teams could actually run.
  3. Design for the people operating the platform. A configuration interface and plan review made repeatable provisioning accessible to engineers who do not author Terraform modules.
  4. Own delivery across architectural tradeoffs. Support the selected design and document its operating costs so future decisions have evidence.

Stack: GCP, Cloud Foundation Fabric FAST, Terraform, GitLab CI, Workload Identity Federation, Organization Policy, Shared VPC, Dedicated Interconnect.