TravelTech Startup: Manual GCP Setup to Full Terraform IaC in 3 Weeks
A flight price prediction startup had built their GCP infrastructure entirely through the console over 18 months. Spinning up a new environment took 2 days of manual configuration. The infrastructure had never been documented. A new CTO joining from Airbnb made IaC a day-one priority. We wrote the Terraform that described what they had, then cleaned it up.
The Challenge
The infrastructure existed only as running GCP resources and tribal knowledge. Three engineers who had originally set it up had left the company. When a new engineer needed to replicate the staging environment for a customer demo, it took 2 days of clicking through the GCP console, comparing screenshots with what production looked like. Two resources were misconfigured and the demo failed. The new CTO's mandate: infrastructure must be code before any new engineer joins.
The Approach
We used Terraform's import functionality to reverse-engineer the existing infrastructure into code, then refactored the imported state into reusable modules. The goal was not just code coverage but code that was readable, DRY, and safe to modify.
The Implementation
Infrastructure discovery and Terraform import
We audited all GCP projects using gcloud asset inventory to list every resource type and instance. We then imported each resource into Terraform state using terraform import, generated the corresponding resource blocks, and ran terraform plan until it showed zero changes. This took 8 days and covered 127 GCP resources.
Module refactoring and DRY structure
The imported code was flat and repetitive. We refactored it into four reusable modules: network (VPC, subnets, firewall rules), compute (GKE cluster, node pools, autoscaling), data (Cloud SQL, Redis, GCS buckets), and security (IAM, service accounts, Secret Manager). Each environment (prod, staging, dev) is an instance of these modules with different variable inputs.
CI/CD for infrastructure changes
We set up a GitHub Actions workflow for Terraform: on PR, run terraform plan and post the plan as a PR comment. On merge to main, run terraform apply. A drift detection job runs nightly comparing actual state to Terraform state and alerts if they diverge. No one touches the GCP console for infrastructure changes.
New environment validation
The test of completeness was spinning up a clean staging environment from scratch. Using the Terraform modules, a new staging environment was provisioned in 47 minutes including DNS, TLS, database seeding, and service deployment. The same process that took 2 days and still failed now took 47 minutes and worked first time.
Key Takeaways
- Terraform import is a viable path to IaC for existing infrastructure - it is not glamorous work but the result is a foundation that can be maintained
- Module refactoring after import is essential - flat imported code is not maintainable and defeats the purpose of IaC
- Nightly drift detection catches console-based changes before they accumulate into unmanageable state
- The test of any IaC implementation is whether a new engineer can spin up a working environment from code alone - if they cannot, the IaC is incomplete
Facing Similar Challenges?
Book a free 30-minute audit and I will tell you what I see.