Architecture · · 3 min read
Migrating legacy systems to Google Cloud — and cutting the bill by 40%
A cloud migration is a business project wearing an infrastructure costume. The playbook I use to move legacy systems to GCP without a big-bang cutover, and where the savings actually come from.
As a lead DevOps engineer I architected and led the migration of a set of legacy systems onto Google Cloud Platform. The outcome everyone remembers is the number: infrastructure cost down 40%, with better scalability than before. The part worth writing about is how you get there without betting the business on a weekend cutover.
A migration is a business project
The first mistake teams make is framing migration as “moving servers.” Leadership doesn’t care where the servers are. They care about cost, risk, speed of delivery and reliability. So the migration plan starts with those, and every technical decision is traced back to one of them.
Before touching any infrastructure, I want three things written down:
- Why we’re moving — the measurable outcomes (cost, scalability, deploy frequency, recovery time).
- What “done” looks like — including what we will deliberately not modernise yet.
- How we’ll roll back — at every stage, for every workload.
Classify every workload
Not every system deserves the same treatment. I sort workloads into buckets:
| Approach | When it fits |
|---|---|
| Rehost (lift and shift) | Stable, low-change systems where speed matters more than optimisation. |
| Replatform (containerise) | Services that change often and benefit from orchestration, autoscaling and uniform deploys. |
| Refactor | Only where the current design blocks the business goal. Expensive — use sparingly. |
| Retire | Things nobody can explain the purpose of. There are always more than you think. |
The retire bucket is the cheapest cost saving in any migration.
Build the landing zone as code
Everything — networks, IAM, projects, clusters, databases — was defined in Terraform from day one. Infrastructure as code isn’t just about repeatability. It makes the environment reviewable, gives you a diff for every change, and lets you stand up a production-like staging environment cheaply enough that people actually use it.
Containers and Kubernetes where they pay off
Services that change often moved to containers on Kubernetes, with CI/CD pipelines building, testing and deploying them the same way every time. Uniform deploys are an underrated win: once every service ships the same way, on-call gets simpler, onboarding gets faster, and the platform team stops being a bottleneck.
Migrate incrementally
No big-bang cutover. Each workload moved behind a routing layer so traffic could shift gradually — shadow, then a small percentage, then all of it — with a tested path back. Data migration was the long pole, as it always is: replicate, verify, cut over reads, then writes.
Where do the 40% savings actually come from?
The move itself rarely saves money. Savings come from what the move makes possible:
- Rightsizing. Legacy environments are sized for peak load from years ago. Measure actual usage and resize.
- Autoscaling. Pay for peak only during peak.
- Retiring and consolidating workloads nobody needed.
- Committed and sustained use discounts once the baseline is stable and predictable.
- Cheaper non-production environments that scale to zero out of hours.
- Visibility. Labelling resources by team and service makes cost attributable, and attributable cost gets managed.
What I’d tell a leader planning a migration
Treat the cloud bill as a product metric with an owner, not an invoice finance forwards to engineering.
A migration done well leaves you with more than a smaller bill. It leaves a platform where every change is code, every deploy is boring, and every rupee spent can be traced to the service that spent it. That foundation is worth more than the savings.