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 |
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.
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.
- Liquid Web: migration testing best practices Accessed 2026-09-13
- curl project: testing a hostname at a specified destination before DNS cutover Accessed 2026-09-13
- Original local WordPress restore: incomplete restore failure and recovery checks Accessed 2026-09-14
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.