A migration is complete only when the new site handles real traffic, forms and email work, important data is current, and you can recover it. Run these checks immediately after changing DNS, then repeat the most important ones after the old TTL has expired.
1. Confirm public DNS
Check the root domain and www from more than one network or public resolver. Confirm they return the new hosting destination. If you changed nameservers, also verify MX and TXT records so the website move has not displaced email authentication or third-party verification.
2. Check HTTPS and domain variants
Open both HTTP and HTTPS versions of the root and www hostnames. Each should reach one preferred HTTPS address without a loop or long redirect chain. Check the certificate covers every public hostname and look for mixed-content warnings.
3. Test important pages and actions
- Open the home page, service pages, campaign pages, and several old bookmarks.
- Log in to the content-management or customer area.
- Test site search, filters, downloads, and protected content.
- Submit every form and confirm the success message is truthful.
- For shops, complete a test order and check stock, tax, delivery, payment callbacks, and emails.
4. Verify files and data
Compare recent articles, orders, users, form entries, comments, and uploads with the old site. Check image libraries and downloadable documents for missing files. If the site accepted changes during migration, confirm the final database synchronisation captured them.
5. Check outgoing and incoming email
Send a message to each important mailbox from an external account and reply to it. Test contact forms, password resets, order confirmations, and application alerts. Review SPF, DKIM, and DMARC results in received message headers.
6. Review redirects and search signals
If URLs changed, test representative old addresses and confirm they redirect once to the closest relevant new page. Check canonical tags, robots directives, the sitemap, and analytics or search-verification tags. A hosting move with unchanged URLs should not require blanket redirects.
7. Confirm background work
Scheduled tasks, WordPress cron, queue workers, imports, backups, and licence callbacks can fail quietly after a move. Confirm each required job exists in the new environment and observe at least one successful run.
8. Start monitoring and inspect logs
Update the uptime monitor if its target changed and watch response time, 404s, PHP errors, database errors, storage, and resource usage. Logs often reveal missing paths or blocked callbacks before a client reports them.
9. Prove the new backup
Confirm a backup has completed on the new hosting and that the correct files and database are included. For a business-critical site, arrange a restore test rather than assuming a successful job status guarantees useful data.
10. Keep the old hosting temporarily
Do not cancel the old service while cached DNS responses may still direct visitors to it. Keep a final archive and wait until the new site has operated cleanly for several days. Then remove any temporary hosts-file entries and close the old service deliberately.
Something does not match? Do not make several unrelated changes at once. Record the affected URL, time, expected result, actual result, and any error message, then open a TekLan support ticket so we can trace the request.