Kubernetes Migration Plan: 6-Month Roadmap, Waves and Cutover Steps
8 min read ยท 2026-10-25
A Kubernetes migration plan sets out how you will move applications from virtual machines, a PaaS or another container platform onto Kubernetes clusters: which services move first, what the platform needs before anything lands on it, how each service is cut over, how you roll back and when the old environment is switched off. A good plan moves services in waves, starting with low-risk stateless ones, and proves the platform with a pilot before the critical systems move.
Most plans cover the technical steps and skip the rest. Migrations slip because the platform team builds clusters but nobody owns the developer workflow, because stateful services were sized like stateless ones, or because nobody wrote down how to roll back at 2 a.m. The 6-month roadmap below covers the full sequence with a milestone per phase. It then gives a filled-in example, who owns what, a cutover checklist, the metrics to watch and how to present progress to your CTO.
The roadmap at a glance
Goal: By month 6, all in-scope production services run on Kubernetes with monitoring, autoscaling and GitOps deployments in place, and the old hosts are decommissioned. Duration: 24 weeks (6 months)
Assessment and wave plan (Weeks 1-3)
Know what you are moving, why, and in what order.
- Write down the goals in measurable terms, such as faster deploys, better resource use or one platform for all teams.
- Inventory every service: runtime, dependencies, state, traffic, owners, config and secrets, and how it is deployed today.
- Classify each service: ready to containerize, needs changes (local files, sticky sessions, hard-coded IPs), or stays where it is.
- Group services into waves, starting with stateless internal services and leaving databases and the most critical paths for last or out of scope.
Milestone: A signed-off inventory and wave plan with an owner and a target month for every in-scope service.
Platform foundation (Weeks 2-8)
Build clusters that are secure, observable and ready for real workloads.
- Choose managed Kubernetes (such as EKS, GKE or AKS) or self-managed, and define cluster layout by environment.
- Set up networking, ingress, DNS, certificates and a secrets approach.
- Configure namespaces per team, RBAC, network policies, resource quotas and pod security settings.
- Install monitoring, logging and alerting, plus backup for cluster state and persistent volumes.
- Set up the delivery pipeline: image build and scanning, Helm charts or Kustomize, and GitOps with a tool such as Argo CD or Flux.
Milestone: Production-grade clusters pass a readiness review covering security, observability, backup and a test restore.
Pilot migration (Weeks 7-10)
Prove the platform and the migration runbook on one real service.
- Pick a stateless service with real traffic, a willing team and an easy rollback.
- Containerize it, add readiness and liveness probes, and set resource requests and limits.
- Shift traffic gradually with weighted DNS or load balancer rules while watching error rates and latency.
- Hold a retrospective and update the runbook, templates and platform docs.
Milestone: The pilot service runs fully on Kubernetes in production for two weeks with error rates and latency at or better than baseline.
Migration waves (Weeks 10-20)
Move the remaining services in planned waves, with each team owning its own service.
- Give each wave a kickoff, a shared migration board and a fixed cutover window.
- Provide a starter Helm chart or template so teams do not start from scratch.
- Pair a platform engineer with each team for its first service.
- Set autoscaling (Horizontal Pod Autoscaler) and PodDisruptionBudgets for services that need them.
- Run load tests before cutover for high-traffic services.
Milestone: Every wave closes with its services in production on Kubernetes and no open severity-one issues.
Stateful services and cutover (Weeks 16-22)
Handle databases, queues and storage-heavy services with the care they need.
- Decide per stateful system: managed cloud service, StatefulSet on Kubernetes, or stay on current hosts.
- Rehearse data migration and rollback in staging with production-sized data.
- Plan cutover windows with business owners and freeze changes around them.
- Run each cutover from a written runbook with go and no-go checkpoints.
Milestone: All in-scope stateful systems cut over with data checks passed and rollback not needed.
Decommission and handover (Weeks 20-24)
Switch off the old environment and hand the platform to steady-state ownership.
- Keep old hosts in standby for an agreed period, then shut them down and remove DNS records and access.
- Right-size resource requests from real usage data.
- Hand over on-call runbooks, platform docs and a support model for application teams.
- Hold a final review against the goals set in the assessment.
Milestone: Old hosts decommissioned, cost and reliability compared with baseline, and the platform run by its steady-state owners.
Lift and shift vs refactor
Not every service should be rewritten to move. A lift-and-shift containerizes the app as it is, with minimal changes, and is quick for stateless services that already read config from environment variables. Refactoring changes the app to suit Kubernetes better: externalizing sessions, writing logs to stdout, splitting a monolith or handling graceful shutdown.
Most plans mix both. Lift and shift where the app already behaves well in containers, and refactor only what blocks the move or what Kubernetes cannot run safely. Write the decision per service in the inventory, so nobody starts a rewrite in the middle of a wave.
Example: a filled-in plan for a SaaS company on virtual machines
Picture a SaaS company with about 40 services on virtual machines, deployed with scripts, plus a Postgres cluster and a message queue. The CTO wants faster, safer deploys and one platform for all teams. Here is how the six months could look.
Note that the database moved to a managed service, not into the cluster. The team kept the migration focused on what Kubernetes does best.
- Weeks 1-3, assessment: 40 services inventoried, 34 in scope, three waves planned, Postgres moving to a managed database. Owner: platform lead. Milestone: wave plan approved by the CTO.
- Weeks 2-8, platform: managed clusters for staging and production, ingress, cert management, Prometheus and Grafana, Argo CD. Owner: platform team. Milestone: readiness review passed.
- Weeks 7-10, pilot: notification service moved with a weighted DNS shift over a week. Owner: notifications team with a platform engineer. Milestone: two weeks stable.
- Weeks 10-20, waves: internal tools, then customer-facing APIs, then the billing services. Owner: each service team. Milestone: each wave closed with no open severity-one issues.
- Weeks 16-22, stateful: Postgres moved to the managed service in a planned weekend window, queue moved to a managed offering. Owner: data platform lead. Milestone: data checks passed.
- Weeks 20-24, decommission: old virtual machines off after a standby period, requests tuned. Owner: platform lead. Milestone: final review with the CTO.
Who owns what
A Kubernetes migration fails when the platform team tries to move every service itself. They become a bottleneck and learn every app badly. The better split: the platform team owns the clusters, templates and guardrails, and each application team owns moving its own services.
Write a RACI before the first wave and review it at each wave kickoff.
- Engineering sponsor (CTO or VP engineering): goals, priorities between product work and migration, final go and no-go on critical cutovers.
- Platform lead: cluster design, security baseline, templates, migration runbook and the readiness review.
- SRE or operations: monitoring, alerting, on-call readiness and incident response on the new platform.
- Service owners (team leads): containerizing, testing and cutting over their services.
- Security engineer: image scanning, RBAC, network policy and secrets review.
- Data platform lead or DBA: stateful systems and data migration.
- Program or project manager: wave plan, migration board, risks and status reports.
Cutover checklist for each service
Use the same checklist for every service so the tenth cutover is as careful as the first. Keep it in the runbook and tick it in the migration ticket.
Decide the rollback trigger before you start. For example, error rate above baseline for 10 minutes, or any data mismatch. When the trigger fires, roll back first and investigate after.
- Container image built, scanned and tagged, deployed through the GitOps pipeline.
- Readiness and liveness probes, resource requests and limits set.
- Config and secrets moved, with no secrets in the image or the repository.
- Dashboards and alerts live for the service on the new platform.
- Load test passed for high-traffic services.
- Traffic shift plan written: percentages, timing and who watches.
- Rollback steps tested in staging, with the old environment kept warm.
Metrics to track
Set baselines on the old platform before you migrate anything. Without them, you cannot show that the migration made things better, and every incident will be blamed on Kubernetes.
Report progress weekly to the sponsor and outcomes monthly.
- Migration progress: services migrated against the wave plan.
- Reliability: error rate, latency and availability per service, before and after.
- Deployment frequency and lead time: from your CI/CD data, before and after.
- Change failure rate: deploys that caused an incident or rollback.
- Resource use and cost: requested versus used CPU and memory, and cloud cost per environment.
- Incidents on the new platform: count and severity, with root cause in the platform or the app.
How to present it to your CTO
Show one slide with the six phases on a timeline and the waves inside phase 4, each with its services and status color. Add three numbers: services migrated out of total, reliability against baseline and the date the old hosts go off. Put the RACI and the cutover checklist in the appendix.
Be clear about what the migration does not fix. Kubernetes will not cure a slow database or flaky tests. Stating that early keeps expectations honest and helps you defend the plan when someone asks why deploys are not instant yet.
Common mistakes to avoid
- Building clusters without a security and observability baseline lets problems reach production, so pass a readiness review before the pilot.
- Moving the most critical service first puts the business at risk, so pilot with a stateless service and an easy rollback.
- Skipping resource requests and limits causes noisy neighbors and evictions, so require them in the template and review them after cutover.
- Moving databases into the cluster by default adds risk without a clear gain, so decide per stateful system and consider managed services.
- Letting the platform team migrate every service creates a bottleneck, so have each team migrate its own services with a platform engineer paired in.
- Switching off old hosts on cutover day leaves no way back, so keep them on standby for an agreed period.
Frequently asked questions
How long does a Kubernetes migration take?
It depends on the number of services, how container-ready they are and whether stateful systems move. A mid-size company with a few dozen services often plans several months. Running a pilot early gives you real data to adjust the estimate.
What should be migrated to Kubernetes first?
Start with a stateless service that has real traffic, a willing team and an easy rollback. Internal tools and APIs without local state are good candidates. Leave databases and the most critical paths for later waves.
Should databases run on Kubernetes?
They can, using StatefulSets and persistent volumes, but it adds operational work. Many teams move databases to a managed cloud service instead and run only stateless apps in the cluster. Decide per system based on your team's skills and the reliability you need.
What is a migration wave?
It is a group of services moved together within a set time window. Waves let you spread the work, learn from each group and keep the risk of each cutover small. Each wave has its own kickoff, board and cutover dates.
How do you roll back a Kubernetes migration?
Keep the old environment running and shift traffic gradually with weighted DNS or load balancer rules. If metrics cross the rollback trigger, send traffic back to the old hosts. Test the rollback in staging before every cutover.