Enterprise SaaS · Multi-cloud consolidation
Consolidating dozens of services without recreating old complexity
A phased migration from Azure Kubernetes Service to Google Kubernetes Engine — dependency mapping, repeatable infrastructure, controlled cutover and platform standardisation.
52
microservices migrated
~2.8 TB
of application data transferred
27%
lower infrastructure cost
<20 min
final production disruption
In brief
A SaaS organisation ran a distributed microservices platform on Azure, where deployment workflows, service configuration and ingress rules had evolved independently. A direct lift-and-shift would have reproduced the same inconsistencies on Google Cloud, so ClimsTech designed a phased programme: dependency discovery, GKE architecture, Terraform modules, managed networking, CI/CD standardisation, data transfer, validation and controlled production cutover.
Working constraints
- More than fifty interconnected microservices
- Existing AKS production workloads
- Multiple databases and data dependencies
- Environment-specific configuration
- Mixed deployment practices
- Limited tolerance for production downtime
- Different networking models across clouds
- Need for rollback during each migration wave
The problem
What was actually going wrong
The platform supported multiple customer-facing services, internal APIs, asynchronous workers, and persistent data components. Availability and release continuity had to be protected throughout the transition. The migration therefore had to be treated as a platform transformation rather than a simple hosting change.
What discovery surfaced
- 1Service ownership and dependency information was incomplete.
- 2Some application services relied on hidden environment assumptions.
- 3Load balancing and ingress rules had grown organically.
- 4Infrastructure creation was only partially automated.
- 5Secrets and environment variables were managed differently across teams.
- 6Several services could be migrated independently, while others required coordinated cutover.
The engineering
What we built and changed
1Dependency and migration mapping
ClimsTech documented service communication, persistent storage, external integrations, secrets, ingress paths, and sequencing constraints. Services were grouped into migration waves according to business risk and technical dependency.
2GKE foundation
The target environment was created through Terraform, with modules covering networking, GKE clusters, node pools, service accounts, monitoring, storage, and environment configuration.
3Delivery standardisation
Bitbucket Pipelines automated container build, validation, image publication, and deployment; common templates reduced variation between service teams.
4Data migration
Application data was classified by size, write frequency, and acceptable interruption; replication, staged transfer, and final synchronisation were used according to workload requirements.
5Controlled cutover
Each wave followed pre-migration checks, deployment, functional validation, performance review, traffic shift, and rollback readiness.
Teams moved from environment-specific deployment knowledge to shared pipelines, reusable infrastructure, and clearer service ownership.
The architecture
Before and after
- Users
- Azure ingress and proxy layer
- AKS cluster
- Customer and internal services
- Workers
- Data services
- Mixed deployment pipelines
- Users
- Google managed load balancing
- GKE platform
- Customer-facing services
- Shared platform services
- Background workers
- Managed data layer
- Central monitoring and logging
Judgement calls
Decisions that shaped the outcome
Why phased migration?
A single cutover would have increased operational risk and reduced the ability to isolate failures. Migration waves allowed learning and validation before critical services moved.
Why managed load balancing?
Managed networking reduced the operational burden of maintaining proxy components and improved alignment with the target cloud platform.
Why Infrastructure as Code before final cutover?
Creating the target platform through code ensured that the new environment would not depend on undocumented manual configuration.
Verified outcomes
What changed for the business
- 52 microservices migrated
- Approximately 2.8 TB of data transferred
- Production cutover completed with less than 20 minutes of disruption
- Infrastructure cost reduced by 27%
- Deployment duration reduced by 55%
- Environment-related release failures reduced by 61%
- Programme completed within 14 weeks
What this engagement proves
Cloud migration succeeds when the target platform removes old operational inconsistency rather than reproducing it in a different provider.
Field notes on this class of problem
All field notesAWS to GCP: what actually changes (and when not to move)
A re-platforming exercise with a service-mapping problem — including the case for staying.
20 min read
Cloud architectureMicroservices or a modular monolith? The question to ask first
The distributed-systems tax, itemised — and when microservices actually justify it.
18 min read
Cloud architectureDo you actually need a service mesh?
Know whether you have the problems a mesh solves before taking on the ones it creates.
17 min read