An agency has copied a client site and plans to switch DNS on Friday evening. The files are present, but nobody owns the content freeze, payment test, TTL change, final database sync, or decision to return traffic if the new host fails.
This guide turns the migration checklist into a working cutover plan: each critical item has an owner, evidence, a deadline, and a clear decision if the new host is not ready.
What a migration checklist should do
A useful migration checklist is an acceptance record, not a collection of generic boxes. It links every prerequisite and test to an owner, due time, expected result, evidence, and action if the check fails. It covers preparation, destination testing, the final data transfer, traffic cutover, observation, and handover.
- Include hosting, WordPress, DNS, TLS, mail, cron, payments, analytics, storage, and external integrations.
- Distinguish “completed” from “verified on the destination” and record who made that judgment.
- Define the last safe rollback time before the maintenance window begins.
A realistic WordPress example
An agency plans a Friday-evening DNS switch. The project lead assigns the developer to the final database synchronization, the account manager to the content freeze and client communication, and a tester to checkout and form submissions. The DNS operator records the old and new values and remains available for rollback. When the payment test fails, the list identifies both the person who can stop the cutover and the condition that must pass before work resumes.
Why it matters and when to use it
Use a checklist for every production move, but scale its detail to the site's risk. A brochure site may need a short list; a store needs explicit ownership of orders, payment callbacks, mail, and the final synchronization. The checklist prevents a technically correct copy from going live before the surrounding services and decision makers are ready.
A straightforward route for beginners
- Define scope, excluded data, responsible people, maintenance window, communication path, recovery objectives, and the last safe rollback time.
- Inventory versions, extensions, credentials ownership, DNS, certificate, mail, cron, redirects, integrations, storage, backups, and critical user journeys.
- Restore and test the destination under the real domain through a local mapping, with outbound mail and live payment side effects controlled.
- At cutover, enforce the agreed write freeze or final synchronization, compare critical counts, then change routing and record the exact time.
- After the switch, test from external networks and monitor errors, performance, jobs, forms, mail, payments, webhooks, indexing controls, and analytics.
The advanced route
Write measurable go/no-go criteria for package integrity, destination health, data parity, certificate validity, and critical workflows. For each criterion, state who evaluates it and how long the team will attempt a fix before rolling back. Keep routing rollback separate from data rollback: once both hosts accept writes, DNS alone cannot merge their records.
- Track the last source write included in the destination and verify recent records after the final synchronization.
- Record screenshots, log links, timestamps, defects, decisions, and the end of the observation period beside the relevant check.
- Make source decommissioning a separate approval after monitoring and handover, not an automatic step after DNS changes.
Risks, common mistakes, backup, and rollback
- A checked box without evidence may mean the item was assumed rather than tested.
- Lowering TTL immediately before cutover does not remove DNS caches created under the previous value.
- Testing mail or payments without containing side effects can contact customers or create live transactions.
- Cancelling the old host before the observation window ends removes the simplest routing rollback.
Prepare both a routing plan and a data plan. If the destination has not accepted unique writes, traffic can return to the old host. If it has, stop new changes and preserve those records before deciding how they will be reconciled.
How AIOWS helps
AIOWS Backup Manager
AIOWS Backup Manager supports the checklist item that prepares and verifies the recovery package for the move. Record the package identifier, file and database scope, destination, creation time, and restore-test result before the cutover is approved.
The module does not own DNS, certificates, mail, payment callbacks, or the final business decision to proceed. Those items remain on the wider migration checklist. Keep the package available throughout the observation period so the team has a known recovery point if the destination fails.
After cutover, confirm that the restored content and media match the approved package while newer records from the final synchronization are present. Mark the backup item complete only when both the package and the live result have been checked.
Related AIOWS articles
- WordPress Migration: Move a Site to a New Host Safely
- WordPress Site Broken After Migration? Complete Fix Guide
- Change WordPress URLs After Migration: Safe Guide
Conclusion and recommended route
Turn the checklist into an acceptance record with owners and evidence. Prove the destination, close the final data gap, execute go/no-go criteria, and keep routing plus data rollback workable. The migration ends after observation and handover, not when the copy command finishes.
