From Docker Compose to Kubernetes — the migration that doesn't have to be painful

Most "migrate from Compose to Kubernetes" guides skip the question of whether you should — then they botch the how. They tell you to run kompose convert, push the YAML into a cluster, and call it done.

The real migration covers four concerns: when to migrate, what to migrate first, what doesn't translate cleanly, and how to phase the cutover.

Should you migrate at all? Not always. A five-service Compose stack on a beefy VM, deployed via SSH and a git pull, will outlive most Kubernetes clusters with one-tenth the operational cost. Migrate when you need autoscaling that Compose can't provide, finer-grained access control between services, or a fleet beyond ~3 nodes.

What translates cleanly — and what doesn't

# Compose → Kubernetes mapping
services      → Deployment / StatefulSet
ports         → Service (ClusterIP / LoadBalancer)
depends_on    → Init containers + readiness probes
volumes       → PVC + storageClass
healthcheck   → livenessProbe + readinessProbe

The 20% that needs rethinking: depends_on: service_healthy (your app needs retry-on-startup), shared volumes across replicas (most cloud block storage is ReadWriteOnce), and network_mode: host.

The full write-up covers:

• The four-stage migration plan (lift-and-shift → parity → cutover → earn the K8s features)
• depends_on patterns and the app retry logic that fixes them
• ReadWriteOnce storage pain and the three escape routes
• The DNS/TTL prep work the week before cutover
• Keeping the Compose stack warm as a rollback path for 72 hours
• The features to not add in week one (Istio, etc.)

Reach out if you're about to take this on.