“We are moving to Kubernetes” is a strategy statement that usually lacks a strategy. I have seen enterprises spend millions on Kubernetes migrations that delivered no business value because they containerized legacy applications that should have been retired.
This guide provides the framework for making good migration decisions.
The 6R Framework for Kubernetes
Adapted from the classic cloud migration framework:
| Strategy | Action | When to Use |
|---|---|---|
| Rehost | Containerize as-is, deploy to K8s | Lift-and-shift for quick wins |
| Replatform | Containerize with minor optimizations | Add health checks, config externalization |
| Refactor | Redesign as microservices | High-value apps that benefit from K8s features |
| Repurchase | Replace with SaaS | Off-the-shelf functionality (CRM, HR, email) |
| Retire | Decommission | Apps with no business value |
| Retain | Keep on current platform | Mainframes, tightly coupled legacy, end-of-life |
The mistake most enterprises make: Refactoring everything. Rehosting 80% and refactoring 20% delivers results 3× faster.
Migration Readiness Assessment
Score each application (1-5):
| Criterion | Score |
|---|---|
| Has a Dockerfile or can be containerized | |
| Stateless or can externalize state | |
| Uses environment variables for configuration | |
| Has health check endpoints | |
| Logs to stdout/stderr | |
| Team has Kubernetes experience | |
| Has automated tests | |
| Has CI/CD pipeline | |
| Business criticality justifies migration effort | |
| Dependency on other migrating services |
35+/50: Ready to migrate 25-34: Needs preparation work Under 25: Consider Retain or Retire
Migration Phases
Phase 1: Foundation (Month 1-3)
- Build Kubernetes platform (networking, security, observability)
- Establish GitOps pipeline with ArgoCD
- Create container image build pipeline
- Deploy first non-critical workload
Phase 2: Quick Wins (Month 3-6)
- Migrate stateless web applications (Rehost)
- Migrate API services (Replatform)
- Establish monitoring and alerting
- Train development teams
Phase 3: Core Workloads (Month 6-12)
- Migrate databases to K8s operators or managed services
- Migrate message queues and event systems
- Implement service mesh for complex service interactions
- Progressive delivery for critical services
Phase 4: Optimization (Month 12-18)
- Refactor high-value applications for cloud-native patterns
- Implement autoscaling and cost optimization
- Establish multi-cluster strategy for DR
- Decommission legacy infrastructure
Common Pitfalls
Migrating databases to Kubernetes first. Start with stateless apps. Stateful workloads on Kubernetes require operators, persistent volumes, backup strategies, and deep expertise. Get the platform stable before adding complexity.
No team training. Kubernetes has a steep learning curve. Budget 2-4 weeks of training per team before expecting productive development.
Ignoring networking. On-premises applications often assume flat networking. Kubernetes networking (CNI, services, ingress, network policies) is fundamentally different.
No rollback plan. Every migrated workload needs a documented rollback procedure to the previous platform. Test it before you need it.
Migrating everything at once. Batch migrations create compounding risk. Migrate one service at a time, validate, then move to the next.
Related Resources
- Kubernetes Multi-Cluster Management
- Platform Engineering Metrics
- Backstage Developer Portal
- Enterprise GitOps Maturity Model
- Kubernetes Security Hardening
- Helm vs Kustomize
About the Author
I am Luca Berton, AI and Cloud Advisor. I lead Kubernetes migration programs for enterprises. Book a consultation.
