THE CONNECTIONS BEHIND YOUR BUSINESS
Website Migration Checklist: Before, During and After
A practical migration runbook covering files, databases, DNS, email, testing and rollback.
Use this website migration checklist to plan what moves, test the destination and protect your email. Work through the before, during and after stages with a clear rollback boundary.
Start here: define what is moving
A hosting move is not necessarily a domain transfer, nameserver move or email migration. Write down which services change and which remain. This checklist coordinates the work; use the separate WordPress and email guides for those procedures.
Choose a responsible owner, a quiet window and a rollback decision time. If the site takes orders, bookings or submissions, identify every writer: web requests, scheduled jobs, integrations and administrators. An old database copied while writes continue can miss real customer activity.
Before: inventory and recoverability
- Record the domain’s authoritative nameservers, A/AAAA, www, MX and mail-authentication records.
- List document roots, application versions, databases, uploads, scheduled tasks and external services.
- Make files, database and configuration backups. Download and test their integrity; confirm the host’s restore procedure.
- Preserve current redirects and HTTPS behavior, including any proxy or CDN configuration.
- Prepare matching domains, application requirements and HTTPS on the destination.
If changing DNS, lower relevant TTLs ahead of time where appropriate, then allow the old TTL to elapse. Lowering a TTL at cutover does not remove already cached answers.
Before: test the destination
Use a provider-supported preview or a controlled local hosts-file override. Verify the real hostname with a trusted certificate; a temporary preview URL may not reproduce redirects or cookies.
Check home and internal pages, images, downloads, search and mobile navigation. Confirm forms reach the right mailbox and authorized test submissions persist. On transactional sites, use the application’s approved sandbox; do not create live charges to test a migration.
During: synchronize and switch
- Announce any approved write pause and stop all relevant writers, not just browser traffic.
- Take the final supported data copy or application-specific synchronization.
- Recheck the destination’s configuration and dependencies.
- Change only the intended routing or DNS records.
- Keep the old environment available and prevent it accepting conflicting new writes.
Do not combine a hosting migration with an unnecessary CMS upgrade or URL redesign. If URLs must change, use a reviewed one-to-one redirect map.
After: compare expected and actual results
| Check | Expected result | If it fails |
|---|---|---|
| DNS and HTTPS | Intended destination, correct hostname certificate | Compare authority, recursive cache and proxy routing |
| Pages and assets | Real content, no broken paths | Check document root, case and build output |
| Forms and database writes | Test saved once and notification delivered | Inspect application logs and mail routing |
| Inbound/outbound email | Both directions work externally | Check MX, routing and authentication independently |
| Redirects | Relevant destination without loops | Restore the affected reviewed rule |
Monitor both old and new systems during the overlap. A visitor reaching the old server through cached DNS is not proof that the new server failed.
Rollback boundary
Record the original routing values and restore instructions before switching. If new writes have reached the destination, switching back blindly can lose them. Pause and reconcile data with the application owner first. Retire the old account only after service checks, cache overlap, backups and retention requirements are satisfied.
Official references
Documentation checked 2026-10-18. Examples use reserved names and addresses; replace placeholders only for systems you are authorized to manage. Interfaces and included features depend on your provider and account.