Migrating to Kubernetes is usually more complex than expected. The hard part isn't K8s itself — it's the dozens of architectural decisions around it. Over the past 3 years, we've moved 9 different companies to K8s, from fintech to e-commerce, from 10-microservice estates to ones with over 100. Here are the 7 lessons that repeated in every project.
1. Think About Stateful Workloads Early
Databases, queues, file storage — decide at project kickoff whether to run these inside K8s or use managed services. Our default recommendation is clear: migrate the stateless services and leave the database in a managed service (RDS, Cloud SQL). K8s operators are maturing, but running a database 24/7 is a separate discipline — not something to learn in the middle of a migration.
2. Observability First, Migration Second
Don't start the migration without Prometheus, Grafana, and distributed tracing in place. The reason is simple: without baseline metrics from the old environment, you cannot answer "did the system get slower?" with data after the move — and every discussion becomes a matter of opinion. Measure first, migrate second, compare third.
3. CI/CD Will Be Rewritten
Your old deployment scripts will almost certainly be thrown away; accept this and budget time for it from the start. In our experience, rebuilding CI/CD takes roughly a third of the total migration effort. Decide on Helm vs. Kustomize early, and set up GitOps (e.g. Argo CD) from day one — if you prevent manual changes to the cluster from the beginning, config drift never becomes a problem.
4. Cost Surprises
Egress traffic, persistent volumes, control plane fees, idle nodes — model TCO before the migration, not after. The uncomfortable truth: without a cluster autoscaler and properly tuned resource requests and limits, K8s can end up more expensive than your old VM setup. For cost visibility, add namespace-level labelling and a cost tool (Kubecost or similar) in the first week.
5. Network Policy
Default deny + explicit allow. Most clusters we've reviewed went live with a flat network: compromise any one pod and you can reach every service. Set up namespace isolation and explicit allow-lists between services from day one; tightening the network after go-live carries the risk of breaking something every single time.
6. Image Sizes
Multi-stage Docker builds can shrink image sizes by more than 70%; consider distroless or alpine as the base. This isn't an aesthetic choice: small images mean fast pod startup — which means you gain precious seconds exactly when autoscaling matters most, during a traffic spike. Bonus: a smaller attack surface and faster security scans.
7. Disaster Recovery
Cluster backups with Velero and a multi-region strategy. But the real test is one question: "How many hours does it take us to rebuild this cluster from scratch?" Any DR plan whose answer hasn't been verified by an actual drill exists only on paper. If your cluster isn't described in IaC like Terraform, that number is measured in days. Your DR plan must be ready and tested before the migration completes.
Conclusion
Kubernetes is a tool, not a goal. Planned well, it buys you scalability and portability; entered unplanned, it becomes an expensive layer of complexity. Use these 7 points as a pre-flight checklist when drawing up your migration roadmap — or book a discovery call with the Avva Mobile team that has walked this road 9 times.
