On-Prem to Kubernetes Landing Zone

Overview

This architecture is the foundation, the landing zone, that an organization stands up before migrating on-premises virtual-machine workloads onto Kubernetes. A landing zone establishes the networking, identity, security, governance, and delivery scaffolding once, so each migrated application drops into a consistent, compliant environment. Use it when modernizing a portfolio of VM-based applications and you want migrations to be repeatable rather than bespoke.

It pairs naturally with a strangler-fig approach: route slices of traffic to containerized services as they are migrated.

Components

• Kubernetes: Target runtime for containerized and replatformed workloads.
• Terraform: Codifies the landing zone, clusters, networking, and policy from the start.
• Vault: Centralized secrets, replacing scattered on-prem credential stores.
• Argo CD: GitOps delivery so every workload is deployed the same way.
• External DNS and cert-manager: Automate DNS records and TLS certificates.
• Prometheus and Grafana: Baseline observability for every migrated app.

Data Flow

During migration, traffic for a given application initially flows to the legacy on-prem system. As each component is containerized, an ingress and routing layer sends a growing share of requests to the Kubernetes version while the rest still reach the legacy system, the strangler-fig pattern. Migrated services use Vault for secrets, External DNS for discovery, and the shared observability stack from day one. Data migration follows expand-and-contract so both old and new can read and write during transition. Once a workload is fully cut over, the legacy path is retired.

Scaling and Resilience

The landing zone provides multi-zone clusters and autoscaling out of the box, so migrated workloads gain elasticity they lacked on fixed VMs. Standardized health checks, pod disruption budgets, and rolling deployments come for free. Because every app uses the same delivery and observability patterns, operational maturity rises across the portfolio. The strangler approach lets teams roll back a migration by shifting routing weights, reducing cutover risk.

Security

The landing zone bakes in least-privilege identity, network segmentation, Pod Security Standards, and policy-as-code guardrails before any workload arrives, so security is the default rather than an afterthought. Vault replaces ad-hoc credentials, cert-manager ensures TLS everywhere, and image signing plus admission control keep untrusted workloads out. Centralized audit logging supports compliance for the whole portfolio.

Trade-offs and Alternatives

A landing zone front-loads effort: you invest in shared scaffolding before delivering migrated business value, which requires organizational patience. Not every VM workload belongs on Kubernetes, stateful or licensing-bound systems may be better rehosted or replatformed onto managed services. A pure lift-and-shift to cloud VMs is faster but forgoes modernization benefits. Choose a Kubernetes landing zone when migrating many applications and the long-term gains in consistency, elasticity, and governance outweigh the upfront investment.