From Lift-and-Shift to Cloud-Native: A Kubernetes Modernization Playbook
A practical path for turning lifted VM workloads into real cloud-native systems: stateless redesign, strangler fig pattern, KEDA autoscaling, and modernization sequencing.
Placing a lifted workload inside a Deployment manifest does not make it cloud-native — it's merely lift-and-shift at the container level. This piece outlines the architectural path for genuinely modernizing VM-based workloads once they move to Kubernetes. The first step is triaging workloads into four categories — stateless, extractable stateful, tightly coupled monolith, and low-ROI legacy — each requiring a distinct strategy: direct containerization, state externalization first, the strangler fig pattern, or replacement with a managed service.
The article explains why externalizing in-process session state, file storage, and scheduled jobs (to Redis, object storage, and CronJobs) is non-negotiable under Kubernetes's disposable-pod model, and details the strangler fig pattern as the only proven way to decompose a monolith without a rewrite. It also covers baseline readiness criteria — meaningful health probes, resource limits from real profiling, and graceful shutdown — plus why CPU-based autoscaling is a poor load signal for most lifted workloads, with KEDA offering more accurate, scale-to-zero autoscaling for queue-driven services.
Finally, it lays out a sequencing model that keeps shipping uninterrupted by dedicating 20-30% of each sprint to modernization, starting with stateless redesign, then observability, then managed service substitutions, and finally the strangler fig extraction phases — observability coming second because you can't safely extract what you can't observe. For engineers, the takeaway is that Kubernetes migration alone guarantees nothing architecturally; disciplined, ordered modernization is what actually delivers cloud-native benefits.