Website Migration Checklist: How to Move a Domain, Hosting Account, or WordPress Site Safely

Overview

Website migration is a broad term. You may be moving a site to a new hosting provider, changing the domain name, switching from shared hosting to cloud hosting, rebuilding a WordPress installation, or changing DNS providers while keeping the same server. Each scenario has different risks, but the safest process follows the same pattern: inventory the current setup, create a tested backup, build and verify the destination, change traffic gradually, and keep a rollback option until the new system is stable.

Start by deciding exactly what is changing. A hosting migration normally keeps the domain and public URLs the same. A domain change affects URLs, redirects, canonical references, email addresses, analytics, and search engines. A WordPress migration may involve both the application and the database. A DNS-only change can be technically small but still interrupt web traffic or email if records are incomplete.

Before planning the move, document the current domain and hosting arrangement. Record the registrar, nameservers, DNS records, hosting account, server address, SSL configuration, email provider, CDN, analytics tools, scheduled jobs, backups, and third-party integrations. If you need background on how these systems connect, review this domain and hosting setup guide and the practical explanation of DNS records.

Use a maintenance window only when necessary. Many migrations can be completed with limited disruption by copying the site first, reducing DNS uncertainty, and switching traffic after testing. Keep the old hosting account active until you have confirmed the new site, email, redirects, backups, and monitoring.

Checklist by scenario

Moving a website to a new host

1. Inventory the current site. List domains, subdomains, databases, media directories, configuration files, cron jobs, server-side redirects, PHP or runtime requirements, and external services.
2. Check the destination. Confirm that the new environment supports the application version, database engine, required extensions, storage needs, scheduled tasks, and traffic pattern. If you are comparing environments, the guide to shared hosting versus cloud hosting can help frame the decision.
3. Create independent backups. Export the database and copy all site files, uploads, themes, plugins, configuration files, and deployment scripts. Store at least one copy outside the current hosting account.
4. Restore the backup on the new host. Import the database, copy files, update environment settings, and confirm file ownership and permissions. Do not assume a successful file transfer means the application works.
5. Test privately. Use a temporary hostname, hosts-file entry, staging URL, or provider preview address. Check representative pages, forms, logins, search, media, downloads, and any authenticated workflows.
6. Prepare DNS and SSL. Confirm the new server address, DNS records, certificate method, redirects from HTTP to HTTPS, and coverage for the root domain and required subdomains.
7. Change traffic. Update the relevant A, AAAA, CNAME, or nameserver records according to the migration plan. Keep the old site available while DNS changes propagate across different resolvers.
8. Verify from outside your network. Test the site using more than one connection or DNS lookup method. Check both the root domain and the www version, if both are intended to work.

Moving a WordPress site

1. Put the site into a controlled state before the final copy. Record the time of the backup and note any content, order, membership, or form submissions that occur during the move.
2. Copy the WordPress files and database together. The database contains settings, content, users, and references to media; the files contain the core installation, themes, plugins, and uploads.
3. Review the site URL and home URL settings. If the domain is changing, plan a controlled search-and-replace process rather than editing database values indiscriminately. Serialized data requires tools that understand serialized structures.
4. Test plugins, themes, forms, caching, image delivery, ecommerce functions, user accounts, and scheduled tasks on the new environment.
5. Clear application and server caches after the cutover. Confirm that the new cache is not serving old content or an incorrect domain.
6. Check the robots.txt response, XML sitemap, canonical URLs, structured data, internal links, and redirects. For a domain change, map every important old URL to its closest relevant new URL.

Changing the domain name

1. Register and control the new domain before making changes. Keep access to the old registrar and domain for the full transition.
2. Build a URL map covering important pages, media URLs, feeds, downloadable files, and legacy paths. Avoid sending every old URL to the new homepage.
3. Install and test an SSL certificate for the new domain, including the preferred hostname and any necessary subdomains.
4. Update internal links, canonical tags, Open Graph URLs, structured data, feeds, analytics settings, advertising destinations, and third-party integrations.
5. Implement permanent redirects from old URLs to their relevant new equivalents. Test redirect chains, loops, mixed-content warnings, and both HTTP and HTTPS versions.
6. Keep the old domain registered and configured long enough for users, crawlers, bookmarks, and external systems to follow the new paths.

Transferring a domain or changing DNS providers

1. Export or document every DNS record before changing nameservers. Include MX, SPF, DKIM, DMARC, TXT verification records, subdomains, service records, and any records used by a CDN or monitoring tool.
2. Confirm that the domain is unlocked for transfer when required and that the administrative contact and transfer credentials are accessible. Exact transfer requirements vary by registrar and registry.
3. Recreate DNS records at the new provider before changing delegation. Missing mail records can interrupt email even when the website remains online.
4. Lower DNS TTL values ahead of a planned change where the provider allows it, but remember that cached responses may still persist according to previous TTL values.
5. After the change, verify website resolution, email delivery, certificate validation, domain verification records, subdomains, and third-party services.

What to double-check

Backups and rollback: A backup is useful only if it can be restored. Open a sample of copied files, inspect the database export, and document how to restore the old host or point DNS back if the new environment fails.

Email: Identify who hosts email before changing nameservers. Preserve MX records and authentication records, and test inbound and outbound messages using more than one mailbox. Website migration and email migration are separate projects unless you intentionally move both.

DNS: Compare the old and new DNS zones line by line. Check the root record, www record, application subdomains, verification TXT records, mail records, and any IPv6 address. Use a DNS lookup tool from multiple resolvers when results appear inconsistent.

SSL and security: Confirm that the certificate is valid for every hostname visitors use. Check HTTP-to-HTTPS redirects, security headers, firewall rules, access controls, administrator accounts, secrets, and file permissions. Rotate credentials if they were exposed during the migration process.

SEO: Crawl the new site or inspect a representative URL set. Look for five common problems: accidental noindex directives, blocked resources, broken internal links, missing redirects, and canonical tags pointing to the old host. Monitor crawl errors and indexed pages after launch rather than relying only on a browser test.

Performance: Compare response time, caching, image delivery, database behavior, and key page templates before and after the move. A new host can require different cache, CDN, DNS, or compression settings. The website speed optimization guide provides a useful review sequence.

Monitoring: Set up uptime checks for the main domain and important subdomains. Watch server errors, application logs, certificate expiry, DNS changes, form submissions, email delivery, and analytics data. Monitoring helps distinguish a real outage from a local cache or DNS issue.

Common mistakes

• Changing nameservers before copying the DNS zone: This can remove mail, verification, and subdomain records that were never recreated.
• Testing only the homepage: Broken forms, login pages, media files, checkout paths, and downloads may remain hidden until users encounter them.
• Deleting the old hosting account immediately: Keeping it available provides a practical fallback and a reference for comparing files and records.
• Forgetting scheduled tasks: Cron jobs may send email, publish content, process orders, create backups, or synchronize data. Recreate and test them deliberately.
• Using a temporary staging URL without checking URL behavior: Applications may generate incorrect canonical links, redirects, cookies, or absolute asset paths.
• Replacing every old URL with a homepage redirect: This weakens the user experience and makes it harder for search engines to understand the new site structure.
• Assuming DNS changes are instant: Different networks can resolve old and new destinations during the transition, so both environments should be safe to receive requests.
• Ignoring analytics and consent tools: A migration can silently remove tracking scripts, change referral data, or break integrations even when the pages look correct.

When to revisit

Use this checklist before every planned change to a registrar, nameserver, hosting provider, domain, CMS, CDN, or server architecture. Revisit it before seasonal planning cycles, major campaigns, site redesigns, platform upgrades, and changes to email or security tooling. It is also useful after a migration: compare the original inventory with the live setup and turn any undocumented exceptions into maintenance notes.

Update the checklist when your workflows or tools change. Add new records, integrations, deployment steps, monitoring alerts, and rollback instructions as they appear. Review backup restoration on a regular schedule rather than waiting for the next migration.

For the next move, begin with three actions: export the current DNS records, create and test an independent backup, and write down the exact cutover and rollback steps. Then build the destination, test it privately, and change one dependency at a time. A careful migration is not defined by how quickly DNS changes; it is defined by whether you can verify the new environment and recover safely if a critical check fails.