AT A GLANCE
Industry: Enterprise technology organisation
Migration: On-premises data centre → Google Cloud (GKE, Cloud SQL, Terraform, Cloud Build)
Services: GCP Architecture & Modernization, DevSecOps, Platform Engineering
Location: Canada
Engagement led by Amit Malhotra, Principal GCP Architect at Buoyant Cloud Inc. — Toronto, Canada
THE SITUATION
An Enterprise Platform Carrying a Decade of On-Premises Technical Debt
A Canadian enterprise technology organisation had reached the point where their on-premises infrastructure was actively constraining the business. The data centre environment had grown incrementally over more than a decade — servers added as needed, network configurations layered on top of each other, and manual processes developed for every deployment and change that was never automated because the environment never quite stabilised enough to make automation worthwhile.
The organisation had recognised for some time that cloud migration was necessary. What had prevented progress was the complexity of what they were working with: tightly coupled applications with undocumented dependencies, a network architecture that had evolved without a coherent design, and an operations team whose institutional knowledge of the environment existed almost entirely in individual memory rather than documentation. A failed first migration attempt to another cloud provider — halted after hitting unexpected integration and networking problems — had made leadership cautious about trying again.
When they engaged me, the goals were clear but the path was not: move the core platform to Google Cloud, eliminate the on-premises infrastructure dependency, and do it without a repeat of the failed first attempt. The new platform needed to be fully automated with Terraform, secure by design, and operable by the internal team without specialist migration knowledge.
THE CHALLENGE
What Made This Migration Complex
Undocumented legacy dependencies: Application components with implicit dependencies on on-premises network behaviour, DNS configurations, and shared infrastructure that had never been formally documented — meaning the migration required discovery work before any architecture decisions could be made.
No Infrastructure as Code baseline: The entire on-premises environment had been provisioned and maintained manually over many years. There was no Terraform, no configuration management, and no authoritative source of truth for what was running and how it was configured.
On-premises security model didn’t translate to cloud: The existing security model relied on network perimeter controls — firewalls and VLANs — that don’t translate directly to GCP. The IAM model, service-to-service authentication, and secrets management all needed to be redesigned from scratch for cloud-native patterns.
Zero downtime requirement: The platform supported active business operations. The migration had to be sequenced to maintain continuity throughout — no maintenance windows long enough for a cutover approach, and no tolerance for a failed deployment leaving the platform in an inconsistent state.
- Previous failed migration attempt: The team had prior experience of a migration that had to be abandoned mid-way. Rebuilding confidence in the approach and process was as important as the technical execution.
THE SOLUTION
A Phased, Architecture-First Migration to GCP
I ran the migration in three phases — discovery and architecture first, then incremental migration with parallel running, then cutover and decommission. Every phase was designed to be reversible, with the previous environment remaining available until the new platform was fully validated. The SCALE Framework provided the architectural methodology — in particular the Cloud-Native Architecture and Automation pillars that ensure the migrated platform isn’t just a cloud-hosted version of the on-premises environment, but a properly redesigned cloud-native platform.
Architecture and dependency mapping: Structured discovery phase to document all application components, their dependencies, network requirements, and data flows — producing the architecture map that the previous migration attempt had tried to skip. No migration work started until this was complete.
GCP landing zone design: Multi-project GCP organisation structure — separate projects for networking, shared services, and workload environments — with Shared VPC, Cloud Interconnect or VPN for hybrid connectivity during migration, and IAM model designed from scratch for cloud-native least-privilege rather than translated from the perimeter-based on-premises model.
Terraform foundation from day one: All GCP infrastructure provisioned through Terraform from the first resource — landing zone, networking, GKE clusters, Cloud SQL instances, and shared services. Every environment reproducible from code, with no manual provisioning at any stage of the migration.
GKE platform with containerised workloads: Application workloads containerised and deployed to GKE — with pod security standards, Workload Identity replacing service account keys, network policies enforcing service isolation, and Cloud SQL Auth Proxy for database connectivity without direct network exposure.
Zero Trust IAM and secrets migration: All service-to-service authentication redesigned around Workload Identity Federation — no static credentials, no shared service accounts. Secret Manager replacing all credential stores, with automated rotation and Workload Identity-based access from all application workloads.
- Phased cutover with parallel running: DNS-based traffic migration with the on-premises environment and GCP platform running in parallel until all validation was complete — giving the operations team confidence in the new platform before the old environment was decommissioned.
THE OUTCOMES
What Changed After the Engagement
100%
of workloads migrated to GCP — on-premises data centre fully decommissioned
Zero
migration-related production incidents during the phased cutover
100%
of infrastructure in Terraform — no manually provisioned resources in the new environment
Beyond the metrics:
The failed first migration attempt had been abandoned due to undocumented dependency complexity — the structured discovery phase in this engagement surfaced those dependencies before they became blockers
On-premises infrastructure and data centre costs eliminated — the organisation exited its data centre lease following successful platform decommission
The internal operations team can now manage the platform using Terraform and standard GCP tooling — no specialist migration knowledge required. See the GCP Architecture & Modernization service for how this type of engagement is structured.
Platform now scales on demand through GKE autoscaling and Cloud SQL read replicas — the on-premises environment had required manual capacity planning and hardware procurement lead times for any scaling event.
This engagement is representative of the Enterprise Platform Modernization work I do. See also the GCP Architecture & Modernization service for the full service detail.
This engagement is typical for Canadian enterprises carrying on-premises technical debt who need a structured, zero-downtime path to GCP. If your team has deferred cloud migration due to complexity, undocumented dependencies, or a failed first attempt, this is the approach we take.