Write the scope before scheduling the move
List the domains, application files, databases, uploads, scheduled jobs, email dependencies, and external services involved. For each, record its owner and how it will be checked. This is a planning checklist, not a command sequence: the right migration steps depend on the stack and the provider's process.
Separate copying the site from sending public traffic to the copy. Liquid Web's migration-testing documentation recommends checking the destination and comparing functionality with the source. Ask your migration contact how to preview the destination correctly for your setup. Do not change public DNS merely to find out whether the new copy works.
Test a complete business task
The table describes checks to perform, not completed tests. Adapt it to the site; a static brochure does not need an order workflow. Avoid sending test notifications to real customers. Give the person checking the destination enough context to recognize missing data, not just visual differences.
| Area | Proposed check | Record |
|---|---|---|
| Visitor pages | Open important URLs and follow their links | URL, result, and unexpected redirects |
| Account or form | Use an approved test account or safe test submission | Expected destination and actual result |
| Commerce | Agree a test method that avoids real unwanted charges | Order, notification, and inventory behavior |
| Scheduled work | Confirm how the responsible operator will verify jobs | Owner and evidence location |
What we observed on our own domain: DNS and redirects
On 2 October 2026 we made read-only observations of migration.editorialdeskmedia.com, a Cloudflare-served host we administer, with dig 9.10.6 and curl 8.7.1. No DNS record was changed, so this is not a timed cutover test.
DNS: the authoritative Cloudflare nameservers and two public resolvers (1.1.1.1 and 8.8.8.8) all returned a TTL of 300 seconds. Asked again 20 seconds later, both public resolvers still returned 300, so watching one resolver count down is not a reliable way to judge when a change has spread. The public A and AAAA answers were Cloudflare addresses, not an origin server address. Behind a proxy like this, an origin move may not change public DNS at all; plan the cutover where the traffic is actually routed. The host also answers over IPv6, so a cutover that only checks the A record is incomplete.
Redirects: every old address form reached the canonical page in exactly one hop, and the page with a tracking parameter served 200 with a canonical tag that drops the parameter. Record this chain before a move and compare it after: a new host that adds a second hop or drops a rule changes what old links and bookmarks do.
- Record TTL, A and AAAA answers from the authoritative nameserver and from at least two public resolvers before the change.
- Save the redirect chain for HTTP, .html, trailing-slash and index forms of key pages, and repeat it after the move.
- Pair these with a preflight that reaches the new host directly, such as curl
--resolve, before changing anything public.
| Request | First response | Final page |
|---|---|---|
| http:// guide address | 301 to https | 200 after 1 hop |
| Guide address ending .html | 308 to the clean address | 200 after 1 hop |
| Guide address with a trailing slash | 308 to the clean address | 200 after 1 hop |
| /guides without a slash | 308 to /guides/ | 200 after 1 hop |
| /index.html and /guides/index.html | 308 to / and /guides/ | 200 after 1 hop |
| Guide address with ?utm_source=x | 200, no redirect | Canonical tag omits the parameter |
Plan for data created during the move
A store or membership site can change after its first copy is made. Ask the migration owner how orders, uploads, and account changes will reach the final destination, and when any pause is needed. Record which system will be authoritative at each stage. Do not improvise database reconciliation from a generic checklist.
Define a rollback trigger before the change: for example, an agreed critical workflow fails and cannot be resolved within the scheduled window. A rollback also needs a data plan. Sending traffic back does not by itself reconcile transactions that occurred on the destination. Ask the responsible operator to explain this before approving the cutover.
Close the move deliberately
Preserve the checklist with dated observations and unresolved issues. Do not label a planned rollback as a tested recovery process. If a provider includes migration assistance, ask which testing and sign-off responsibilities remain yours.
- Name the cutover owner and a reachable backup contact.
- Record the agreed preview, final synchronization, and public-switch sequence.
- Confirm recovery access and the location of independent backups.
- Repeat critical checks after public traffic reaches the destination.
- Retire the old service only after the agreed verification and retention period.
Check for staging indexing rules after cutover — Website Builders Compared — If the approved public site was copied from staging, check page and response-header noindex rules separately from robots.txt before closing the migration.
Questions before you decide
Is a working homepage enough to approve a migration?
No. Check the actual workflows the site exists to support, such as forms, account access, or orders. Record results on the destination and repeat the critical checks after cutover.
Can I cancel my old hosting as soon as the files copy?
Keep it available until the agreed destination, cutover, and recovery checks are complete. Coordinate the retention period with the migration owner; this guide does not prescribe one period for every application.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- Nexcess (Liquid Web family): migration testing best practices Accessed 29 Oct 2026
- curl project: testing a hostname at a specified destination before DNS cutover Accessed 13 Sep 2026
- Original local WordPress restore: incomplete restore failure and recovery checks Accessed 14 Sep 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.