Cloud & DevOps
Kubernetes in Production: A Readiness Checklist
Getting a Kubernetes cluster running takes an afternoon. Running it safely in production takes discipline. A checklist for security, reliability and operations.
Key takeaways
- Classify every workload with one of the 7 Rs before moving anything.
- Discovery and dependency mapping prevent most migration failures.
- Build the landing zone first — security and governance cannot be retrofitted cheaply.
- Track business outcomes, not just servers migrated.
The 7 Rs
| Strategy | What it means | When to use |
|---|---|---|
| Retire | Decommission | Unused or redundant applications |
| Retain | Keep on-premises for now | Regulatory, latency or recent investment reasons |
| Rehost | Lift and shift to cloud VMs | Speed matters; limited change appetite |
| Relocate | Move a virtualised platform as-is | Large VMware estates needing a quick exit |
| Replatform | Small optimisations, e.g. managed database | Quick wins without a rewrite |
| Repurchase | Move to SaaS | Commodity capabilities such as HR or CRM |
| Refactor | Re-architect for cloud-native | Strategic applications needing scale and agility |
Discovery comes first
Use discovery tools and interviews to build an inventory of servers, applications, data stores and their dependencies. Undocumented dependencies — a batch job calling a legacy database, a hard-coded IP address — are the most common cause of failed cutovers.
Compliance and data location
Confirm data protection obligations, customer contracts and industry rules before selecting regions and services, particularly for personal and payment data.
Build the landing zone
A landing zone provides identity, network, security, logging, policy and cost management foundations for every workload. Building it first avoids each migration team inventing its own approach.
Plan migration waves
Group applications by dependency and risk. Start with low-risk workloads to prove tooling and processes, then move to business-critical systems. Each wave includes testing, cutover planning, rollback criteria and hypercare.
Cost management from day one
Right-size instances, use reservations or savings plans for steady workloads, switch off non-production out of hours and tag everything for cost allocation. Migration without FinOps often leads to cloud bills higher than the data centre being replaced.
Measuring success
Track business outcomes: release frequency, availability, recovery capability, cost per transaction and data-centre exit milestones.
Next step: read our Azure vs AWS vs Google Cloud vs OCI comparison or talk to our Cloud & DevOps team.
Frequently asked questions
Is lift and shift a bad idea?
Not necessarily. Rehosting is a valid first step when speed matters, provided optimisation follows.
How long does a cloud migration take?
A few dozen applications can move in three to six months; large estates take one to three years in waves.
Which cloud provider should we choose?
It depends on workloads, skills, existing licensing and regulatory needs. See our neutral comparison of Azure, AWS, Google Cloud and OCI.
NAZZTEC Editorial TeamWritten and reviewed by NAZZTEC practitioners. This briefing is general guidance, not legal advice.
