Cloud Native · Example engagement

Moving a SaaS platform to GKE without a big-bang cutover

B2B SaaS scale-up · 40 engineers · VM-based monolith

A growing SaaS product had outgrown hand-managed VMs. Releases were slow, scaling was manual and every change touched the whole application.

Current estateGoogle CloudLANDING ZONEApp serversApp serversDatabasesDatabasesBatch jobsBatch jobsMigration wavesCutover · rollback ready

The challenge

Where things stood.

  • A single monolith deployed to VMs by script, with weekend release windows.
  • Traffic peaks handled by over-provisioning, so cost rose faster than usage.
  • No agreed downtime target and no rehearsed rollback for a migration.

Our approach

How we would solve it.

  1. 01

    Assess the estate

    Map services, data stores and dependencies; agree a downtime target and acceptance checks per workload.

  2. 02

    Land the platform

    Build a GKE landing zone with Terraform, network boundaries, workload identity and a GitOps delivery path.

  3. 03

    Migrate in waves

    Move stateless services first, rehearse cutover and rollback, then move stateful components with replication.

  4. 04

    Hand over a golden path

    Templates, runbooks and dashboards so the product team can ship new services without a ticket.

Deliverables

What the client receives.

Services involved:

  • Workload assessment and migration wave plan
  • GKE landing zone as reviewed Terraform
  • Cutover and rollback runbooks per wave
  • Developer golden path and handover pack

Outcomes

What success looks like.

  • Releases move from weekend windows to on-demand deploys
  • Each wave cuts over against agreed acceptance checks
  • Capacity follows traffic through autoscaling, not over-provisioning
  • The product team owns the platform after handover

Example engagement: an illustrative scenario showing how DotConn approaches this kind of work. Client details and figures are not shown.