Published: 2026-10-15 · Updated: 2026-10-15
Moving a website is easier to manage when the current setup is documented before anything changes. Use this checklist to plan the work, agree on a rollback point, and verify the new environment after launch.
Inventory the current setup
Record where the domain is registered, which DNS provider is authoritative, how the site is hosted, and where its source code, database, uploads and scheduled jobs live. Note the versions and settings the destination will need. Keep credentials in a secure password manager; do not put secrets in a public migration document.
Walk through the main user journeys on the existing site. Save a list of important URLs, forms, redirects and integrations so you can compare them after the move. Confirm who can approve DNS changes and who can restore the old environment.
Back up and prepare a rollback
Take a fresh copy of the database, uploaded files and configuration before the migration. Check that each backup completed and that you know how to restore it. If possible, test the restore in a separate environment before the production change.
Agree on a rollback condition in advance. For example, decide which broken journeys or error levels mean the old site should be restored. Keep the previous hosting available until the new site has passed its checks and the agreed observation period is over.
Check DNS and email records
Copy the required web records, such as A, AAAA or CNAME records, and review any TXT records used for verification or email. Mail may depend on MX, SPF, DKIM and DMARC records even when the website itself is moving. Do not replace a DNS zone with only the web records unless you have confirmed that no other services depend on it.
If your DNS provider allows it and the schedule is known, a lower TTL before the change can help some resolvers pick up the new destination sooner. It does not remove caching everywhere, so plan for a period when visitors may reach either environment.
Test the destination before cutover
Use a temporary hostname or another controlled preview path to review the new environment. Check page rendering, navigation, images, forms, HTTPS, redirects and any external integrations. Confirm that staging pages are not meant to appear in search results and that production metadata, canonical URLs, robots rules and sitemap point to the intended domain.
Make sure the content and database are current at the moment of cutover. If people can create or change data on the old site, plan how to pause writes or synchronize the final changes so nothing is lost.
Verify the site after launch
After changing DNS, test the important journeys again on the public hostname: load key pages, submit a controlled form, inspect redirects and confirm that HTTPS is valid. Review server and browser errors, and ask someone outside the deployment network to check access.
Keep the previous environment and its backups until the new site is stable. Then update any documented integration URLs, remove temporary access carefully, and record the final DNS and hosting arrangement for the site owner.
Back to resources