Production Migration Readiness Checklist
Do not schedule production cutover until six readiness gates have named owners, current evidence and a rollback path that still works when you need it.
The readiness rule
A migration is ready when the team can explain the workload, prove the destination, rehearse the move, recognize failure, restore service and validate the business outcome. A copied server is not the same thing as a controlled migration.
For working sessions only; answers are not stored or submitted.
Score evidence, not confidence
Use this checklist in a working session with the people who operate, own and validate the workload. Mark an item complete only when someone can show current evidence—not when the answer sounds likely.
The 48 questions are intentionally vendor-neutral. They apply to a WordPress host move, a Linux/VPS or Docker deployment, an application migration, and a larger AWS, Azure, GCP or hybrid cutover. The tooling changes; the control questions do not.
Outcome, scope and ownership
Can everyone describe what is moving, why it is moving, and who can stop the change?
A technically sound move can still fail when the success criteria, maintenance window or decision authority are ambiguous.
Evidence checklist
A one-page scope, RACI or owner list, approved window and signed-off success criteria.
Do not book a cutover when nobody has authority to declare go, no-go, rollback or success.
Source inventory and dependencies
Do you understand the live system well enough to predict what will notice the move?
The visible server or website is rarely the whole workload. Identity, DNS, certificates, mail, scheduled jobs, payment callbacks and private routes often fail outside the main test path.
Evidence checklist
A dependency map plus an inventory that another engineer could use to explain the workload.
Stop when critical traffic flows are still described as “probably” or “should be automatic.”
Destination readiness
Is the target a production environment, or merely a place where the files happen to run?
A successful copy is not a production-ready destination. Capacity, identity, networking, security, backups, monitoring and operational access must exist before traffic moves.
Evidence checklist
A target build record, connectivity tests, restore evidence, monitoring screenshots and access-owner confirmation.
Do not use the cutover window to discover whether production identities, routes or backups work.
Data movement and synchronization
Can you move every changing byte without losing, duplicating or corrupting business data?
Files and databases do not necessarily become consistent at the same instant. The plan must define write handling, final synchronization and integrity evidence.
Evidence checklist
Timed transfer tests, replication health, reconciliation results and a written final-sync procedure.
Stop if both source and target can accept writes without a tested reconciliation plan.
Rehearsal, cutover and rollback
Has the change been rehearsed, timed and converted into an executable runbook?
A rollback plan is not “change DNS back.” It must specify the trigger, decision-maker, last safe point, data treatment and exact restoration steps.
Evidence checklist
A timed rehearsal record and a runbook that can be followed without relying on the author’s memory.
Do not proceed when rollback exists only as a heading or requires credentials that have not been tested.
Validation and stabilization
How will you prove the business service works—and keep proving it after the call ends?
A homepage returning HTTP 200 does not validate authentication, transactions, background jobs, mail, backups, integrations or user experience.
Evidence checklist
A signed validation record, monitoring window, open-issue list and explicit acceptance/decommission decision.
Do not declare success because traffic moved. Declare it when the agreed service outcomes are proven.
Three common environments, fifteen extra checks
The six gates are the common control plane. Add the relevant checks below; none replaces platform-specific testing or vendor guidance.
WordPress and hosting
- Serialized URLs and search/replace method
- Uploads, cache and generated-file exclusions
- PHP version, extensions and server limits
- Cron, SMTP, forms, payments and webhooks
- Admin login, media, redirects and canonical behavior
Linux/VPS and applications
- System services, timers and startup ordering
- Runtime, package and container-image versions
- Environment variables, secrets and mounted storage
- Database, queue and worker dependencies
- Logs, health checks and deployment rollback
Cloud and hybrid
- Account/subscription/project and landing-zone ownership
- IAM, federation, service identities and key rotation
- Routing, VPN/private circuits, DNS and egress paths
- Quotas, policy, region and data-residency constraints
- Cross-environment monitoring, backup and cost visibility
What the checklist is protecting
Rollback is evaluated at every step, not added after the runbook is finished. Once new writes, identity changes or source decommissioning make return unsafe, that boundary must be visible to the decision-maker.
Make one explicit cutover decision
GO
All six gates have named owners and current evidence. Rehearsal passed. Rollback remains viable through the agreed decision point.
CONDITIONAL GO
Only bounded, understood gaps remain. Each has an owner, a deadline and an approved risk treatment before the irreversible step.
NO-GO
A critical dependency, restore path, validation test, decision owner or rollback step is missing—or the rehearsal produced unexplained results.
A conditional go is not a softer name for hope. If the condition is not closed before its deadline, the decision becomes no-go.
Bring the source, destination, deadline and what cannot break.
The most useful first conversation is bounded: confirm the workload, expose unknown dependencies, identify the riskiest assumption and decide whether the next step is discovery, a rehearsal, recovery work or a scoped migration plan.
Discuss a migration assessmentReadiness questions worth resolving early
How early should migration readiness work begin?
Begin before the cutover date is treated as fixed. The inventory, dependency map, target build, transfer timing and rehearsal can expose work that changes the feasible window.
Does a successful test migration mean production is ready?
Not by itself. A useful test also proves representative data, integrations, identity, traffic paths, operational monitoring, validation and rollback—not only that the application starts.
What is the minimum useful rollback plan?
It names the trigger, decision-maker, last safe decision time, traffic-restoration steps, treatment of post-cutover writes, required credentials and the validation required after rollback.
Should modernization happen during the migration?
Only when it is deliberately scoped and tested. Combining a platform move with major application, database or architecture changes increases the number of variables and can make rollback harder.
Primary references
Layer7’s checklist is vendor-neutral. These current vendor frameworks independently reinforce assessment, dependency discovery, target preparation, controlled execution, validation and fallback.
- AWS Prescriptive Guidance — Evaluating migration readiness
- Microsoft Cloud Adoption Framework — Migrate workloads to Azure
- Google Cloud Architecture Center — Migrate to Google Cloud
- Cloudflare DNS — Time to Live and change propagation
Reviewed and published August 30, 2026. Update the date only after substantive review.
