The starting point.
The platform was a set of connected components for document processing and AI-assisted workflows. Its environments did not share one dependable setup path. A deployment that worked in one place could still be difficult to reproduce in the next.
Calling this a cloud migration would only describe the destination. The real job was to replace one-off infrastructure and delivery steps with a model that could be read, reviewed and repeated.
What the design had to solve.
The new platform model needed to make four things explicit:
- Multiple application components had to follow the same delivery logic.
- Environment differences needed to be configuration, not undocumented setup work.
- Infrastructure changes had to be visible before they reached a live environment.
- Application workloads and managed cloud services needed a clear operational boundary.
The diagnosis.
The fragile part was not a single service. It was the path from source code to a running environment. When that path varies by environment, every change carries hidden assumptions.
I treated reproducibility as the central requirement. Infrastructure definitions, cluster workloads and environment values needed separate responsibilities, while still moving through one delivery path.
The resulting platform model.
GitLab CI/CD provides the delivery path. Terraform defines the Google Cloud foundation, GKE provides the workload layer, and managed services handle platform concerns that do not belong inside the application containers.
Decisions that mattered.
The migration became dependable because the boundaries were deliberate.
Reuse modules, vary inputs
Reusable Terraform keeps the foundation consistent. Environment-specific values stay visible as inputs instead of turning into copied infrastructure.
This asks for stricter module contracts, which is exactly where the discipline belongs.
Give workloads one runtime model
GKE gives the application components a consistent deployment target and makes their runtime configuration easier to reason about together.
A shared cluster model still needs clear ownership for namespaces, configuration and rollout behaviour.
Use managed services on purpose
Managed Google Cloud services take platform responsibilities out of custom workloads where that boundary is useful.
The gain in operability comes with provider-specific choices that need to remain explicit in the architecture.
Delivery and verification.
The delivery model puts infrastructure and workload changes on an inspectable route through GitLab CI/CD. Terraform makes the intended cloud state reviewable; the GKE deployment model gives application components a common target.
Verification follows the same boundary: first the infrastructure definition, then the platform resources, then the workloads that run on them. That sequence makes failures easier to locate than an environment-specific deployment script.
The qualitative result.
Infrastructure and delivery now follow one repeatable, auditable path. The platform can be discussed as a system rather than as a collection of environment exceptions.
The most useful outcome is not that the system runs on Google Cloud. It is that the route to a running environment is encoded, reviewable and consistent.