Moving containerised workloads to managed Kubernetes is well documented. The problems that actually consume the timeline are operational, not technical.
Standing up a cluster and deploying a workload is an afternoon. Migrating a real estate — dozens of services, established deployment habits, an on-call rota built around the old platform — is where the schedule goes.
What consumes the time
- Identity mapping — moving from node-level credentials to per-workload identity touches every service and every policy
- Ingress and DNS cutover, which is the only genuinely risky moment and deserves a rehearsal
- Persistent state: stateless services move easily, anything with a volume needs a plan and a maintenance window
- Logging and metrics pipelines, which teams consistently leave until last and then discover they are blind in the new platform
- Retraining the humans — new debugging workflows, new failure modes, new escalation paths
What we do differently
Migrate a low-traffic service that is nonetheless real, and run it in production for a fortnight before moving anything else. Synthetic pilots do not surface the operational gaps; a real service with real users does, and it does so while the blast radius is small.
The trap
Running both platforms in parallel is more expensive and more complex than either alone, so there is pressure to shorten the overlap. Resist enough to keep a genuine rollback path through the first few migrations — but set an end date, because a parallel period without a deadline becomes permanent, and then you are operating two platforms forever.