Kubernetes Migration Risk Checklist: 7 Pre-Cutover Checks

The biggest risks in a Kubernetes migration are rarely about the cluster itself — they're stateful data that doesn't survive a pod reschedule, secrets that are base64-encoded but not encrypted, DNS cutovers executed without lowering TTLs first, and rollback paths nobody has actually tested. Work through these seven checks before the first production workload moves, not after.

How to Use This Checklist

Kubernetes migration risk is concentrated less in YAML and more in operations: backups you haven't restored, on-call runbooks that don't exist yet, and traffic cutovers with no reverse gear. Work through each section below in order, and treat any unresolved red flag as a blocker to cutover, not a follow-up ticket.

This checklist assumes two decisions are already made. If you haven't settled on an orchestrator, read our ECS vs. EKS comparison first — the platform changes which of these risks you own versus which AWS manages for you. If you haven't decided how much of the application to change during the move, our lift-and-shift vs. re-architect breakdown covers that trade-off. Both are upstream of this checklist, part of our broader container adoption guidance, and pick up once you've committed to Kubernetes and are staring down an actual cutover date.

Stateful Workloads

Databases, queues, and caches are the highest-risk workloads to move onto Kubernetes because a rescheduled pod doesn't inherently keep its data. Before migrating anything stateful, confirm it actually belongs in-cluster, and that backups have been restored — not just taken — against a fresh cluster.

• Confirm the workload even belongs in-cluster. Many teams deliberately keep primary datastores on managed services — RDS, ElastiCache, MSK — rather than running them as StatefulSets, to avoid owning stateful operations on top of Kubernetes. If nobody can say why a database needs to run in-cluster, revisit that before migration, not during it.
• Verify backup and restore, not just backup. A cron job that snapshots a PersistentVolumeClaim proves nothing. Restore into a scratch namespace and confirm the app comes up clean. Red flag: nobody has restored this workload's data in the last quarter.
• Check the StorageClass and PV reclaim policy. Confirm the reclaim policy is set intentionally (Retain vs. Delete) so a deleted PVC doesn't silently take production data with it, and that the StorageClass matches the workload's performance needs.
• Test volume zone affinity. Block storage volumes are often zone-locked; if the scheduler places a pod in a different zone than its volume, it won't start. Confirm topology-aware scheduling before relying on it during an incident.
• Validate ordered startup and failover timing. StatefulSets guarantee ordering, not graceful handling of a slow or partial failover. Time an actual pod-kill-and-recover cycle against your recovery time objective.

Networking and DNS

In-cluster networking is a different failure surface than a traditional VPC — CoreDNS resolves service names, NetworkPolicies are default-allow unless you add them, and IP-per-pod CNI models can exhaust address space quietly. External DNS cutover needs its own separate plan.

• Lower external DNS TTLs well before cutover. A 24-hour TTL means you're stuck for up to a day if something goes wrong. Drop TTLs to minutes at least 48 hours ahead, and confirm the change has actually propagated.
• Confirm ingress and TLS are wired end-to-end. Whether you're running an NGINX ingress controller or the AWS Load Balancer Controller, verify certificates issue and renew correctly — cert-manager is the common path — before real traffic hits it.
• Add explicit NetworkPolicies. Kubernetes networking is default-allow between pods unless you lock it down. East-west traffic wide open is a real security gap. Red flag: the cluster has zero NetworkPolicy objects and every namespace can talk to every other.
• Size pod and service CIDRs for growth, not day one. With the AWS VPC CNI, each pod consumes a real VPC IP. Undersized subnets cause scheduling failures that look like capacity problems but are actually address exhaustion.
• Plan the actual cutover mechanics. Decide whether DNS or a load balancer moves traffic, and whether externalDNS will automate record management. Have a tested way to shift traffic back if the new environment misbehaves.

Secrets Management

Kubernetes Secrets are base64-encoded, not encrypted, by default — treating them as a secure store without additional configuration is one of the most common migration mistakes. Confirm encryption-at-rest and an external secrets store are wired in before anything sensitive moves onto the cluster.

• Enable encryption-at-rest on etcd. A KMS-backed encryption provider protects Secret contents in the underlying datastore. Without it, anyone with etcd access can read every Secret as plain base64 — trivially decoded, not encrypted.
• Wire in an external secrets store. AWS Secrets Manager or HashiCorp Vault, surfaced via the External Secrets Operator or a CSI secrets driver, keeps the source of truth outside the cluster and gives you rotation and audit trails native Secrets don't.
• Audit for secrets baked into images, ConfigMaps, or git history. The single most common failure is a credential committed to a repo or hardcoded into a Dockerfile early on and never removed. Scan image layers and git history explicitly rather than assuming it's clean.
• Lock down RBAC to least privilege. Confirm only the service accounts that need a given Secret can read it. Red flag: a default service account or a wildcard RBAC rule has read access to Secrets across the whole namespace or cluster.

Observability

Observability tooling should be in place before the first service moves to production, not added after something breaks. That means metrics, centralized logs, and distributed tracing working together, plus correctly configured health probes and resource limits so the scheduler and the cluster behave predictably under load.

• Confirm all three observability pillars are live. Metrics (Prometheus or a managed equivalent), centralized log aggregation (Loki, CloudWatch, or ELK, since containers log to stdout by convention), and distributed tracing via OpenTelemetry should already be collecting data from a staging workload, not configured for the first time during cutover.
• Get liveness, readiness, and startup probes right. A misconfigured liveness probe causes crash-loop restarts on a healthy pod; a missing or too-permissive readiness probe sends live traffic to a pod that isn't ready. Both look like "Kubernetes is unstable" when the real cause is probe configuration.
• Set resource requests and limits deliberately. Without requests, the scheduler can't place pods sensibly. Without limits, a workload can trigger OOMKills or CPU-throttle its neighbors. Red flag: any production workload running with no requests or limits set at all.
• Build dashboards and alerts for cluster and application health alike. Node pressure, pod restart counts, and API server latency need the same visibility as application error rates and request latency.
• Run a diagnosis drill. On-call should be able to diagnose a simulated incident — a crash-looping pod, a slow query, a bad deploy — using only the observability stack, no SSH required. If someone reaches for kubectl exec to figure out what's wrong, observability isn't done yet.

Rollback Strategy

Every migration needs a tested, fast way back — for both application code and database schema. A rollback strategy that's never been exercised isn't a strategy, it's a hope. Confirm the reverse path works before you need it under pressure.

• Pick a deployment strategy deliberately. Rolling update is the default, but blue-green or canary (via a tool like Argo Rollouts) may fit better depending on how much traffic risk you can tolerate during a bad release. Know exactly how it behaves when a rollout is interrupted mid-way.
• Test the actual revert command, not just its existence. Run kubectl rollout undo or helm rollback against a staging deploy and confirm the previous version comes back healthy inside your recovery window.
• Keep database schema changes backward-compatible. An expand/contract pattern — add new columns before removing old ones, deploy code that tolerates both shapes — means rolling back application code doesn't break against an already-migrated schema. Red flag: a migration the previous app version can't run against at all.
• Keep the old environment warm until the new one is proven. Don't decommission it the moment the new one looks fine. Keep traffic-shift reversible until the new environment has handled a real production cycle — a deploy, a scale event, and at least one incident.
• Set PodDisruptionBudgets. Without them, a node drain or cluster upgrade can take down more replicas at once than the application tolerates, turning routine maintenance into an incident.

$ kubectl rollout undo deployment/checkout-service
$ kubectl rollout status deployment/checkout-service --timeout=120s
$ helm rollback checkout-service 4

Organizational Readiness

This is where Kubernetes migrations most often fail — not on the manifests, but on the team around them. Confirm there's a named platform owner, real runbooks, least-privilege RBAC, an owner for the ongoing upgrade cadence, and a plan for cost governance before cutover.

• Name a platform-engineering owner. Someone specific needs to own cluster health, upgrades, and incident response — not "the backend team" collectively. Diffuse ownership is how clusters drift out of support unnoticed.
• Write on-call runbooks before you need them. Common failure modes — crash loops, node pressure, a stuck rollout — should have a documented first response, not tribal knowledge in one engineer's head.
• Lock down RBAC and deploy access. Least-privilege access control and a disciplined deploy process — GitOps or an equivalent reviewed pipeline — prevent both accidental production changes and unclear blast radius.
• Assign an owner for the upgrade cadence. Kubernetes has a roughly annual upgrade rhythm, and falling behind compounds — skipped versions make the eventual upgrade riskier. Someone needs to own scheduling and testing those upgrades on a recurring basis.
• Put cost governance in place. Kubernetes makes over-provisioning easy — generous resource requests across many services add up fast, and nobody notices until the bill does. Set up cost monitoring per namespace before, not after, workloads move in.
• Train the team, and expect Conway's law. The cluster's structure ends up mirroring your organization's communication structure. Unclear ownership boundaries in the org chart show up as unclear namespace and RBAC boundaries in the cluster.

The Go/No-Go Gate

Treat every open item above as a blocker, not a nice-to-have, until it's resolved. The table below consolidates each risk area into a single go/no-go signal — if any row is a "no," hold the cutover rather than proceeding on a partial checklist.

Risk area	Go signal
Stateful workloads	Backup has been restored into a fresh cluster and validated, not just taken
Networking and DNS	TTLs lowered ahead of time, NetworkPolicies in place, cutover mechanics tested
Secrets management	Encryption-at-rest enabled, external secrets store wired in, no secrets in images or git
Observability	On-call can diagnose a simulated incident using only dashboards and logs, no SSH
Rollback strategy	Both app rollback and schema rollback tested; old environment still warm
Organizational readiness	Named owners exist for platform, on-call, and the upgrade cadence

If every row reads "go," you're ready to move a real workload. If even one doesn't, the fix belongs before cutover — the cost of resolving it after go-live, mid-incident, is always higher.

Get a Second Set of Eyes on Your Cutover Plan

A checklist catches known failure modes; it won't catch the ones specific to your architecture, your data volumes, or your team's current gaps. Before you commit to a cutover date, it's worth having someone who has run these migrations before review the plan.

Our legacy modernization team has walked organizations through exactly this kind of cutover — stateful workloads, secrets, rollback plans, and the organizational gaps an incident finds first. If you want a second opinion on your migration risk before setting a date, get in touch and we'll look at where your plan actually stands.