A website migration is more than copying files to a new server. This reusable website migration checklist helps you plan the move, preserve email and search visibility, validate DNS and SSL, and monitor the site after launch so small problems are found before they become outages.
Overview
Moving a website to a new host can involve several separate systems: the domain registrar, DNS hosting, web hosting, databases, email services, SSL certificates, analytics, and search-engine signals. Treating the work as one large “switch” makes it difficult to identify what changed when something fails. A safer approach is to record the current state, build and test the replacement environment, change traffic in a controlled way, and verify each service afterward.
This checklist applies to common migrations, including moving between shared hosting accounts, changing managed WordPress hosting providers, replacing a VPS, or transferring a site to a new infrastructure stack. It assumes that the domain name will remain the same. A domain transfer to a different registrar is a separate administrative process and does not, by itself, move website files or email.
Before starting, assign an owner for each area: website files and application code, databases, DNS, email, analytics, and SEO. Keep a written change log with dates, old values, new values, and rollback instructions. That record becomes especially useful when DNS changes are still propagating or when a problem appears several hours after launch.
What to track
1. Inventory the current environment
Record the current hosting account, server address, document root, runtime versions, database engine, scheduled jobs, storage locations, CDN settings, firewall rules, and third-party integrations. List every hostname in use, including the main domain, www, staging subdomains, API endpoints, and asset domains. Export the current DNS zone or copy each record into a migration worksheet.
Pay particular attention to records that are easy to overlook: MX records for email, TXT records for SPF and domain verification, DKIM selectors, DMARC policy records, CNAME records for SaaS tools, and verification records used by analytics or webmaster platforms. Do not assume that a website migration should replace all existing DNS records.
2. Create and test backups
Take a complete backup before making changes. For a database-driven site, this normally includes the database, uploaded media, application files, configuration files, and any custom scripts. A backup is only useful if it can be restored, so test at least one restoration in the destination environment or another isolated location. Document the backup timestamp and retention location.
Use the guidance in Best Website Backup Solutions to compare backup approaches for shared hosting, VPS, WordPress, and cloud servers.
3. Prepare the new host without changing public DNS
Create the destination site, database, user accounts, storage, runtime settings, and deployment process. Copy the site and import the database, then update configuration values such as database credentials, environment variables, file paths, caching endpoints, and API keys. Keep the destination private while it is being tested. A temporary host URL, local hosts-file entry, staging domain, or access-controlled preview can help you inspect the site without sending public visitors to it.
Test critical workflows rather than only checking the homepage. Submit forms, sign in, search, add products to a cart if relevant, upload files, publish content, process a test transaction where appropriate, and confirm that scheduled tasks run. For WordPress, review the required PHP version, database configuration, caching, backups, and security settings with the WordPress hosting requirements checklist.
4. Protect email continuity
Determine whether email is hosted with the old web host, the domain provider, or a separate service. If email is separate, preserve its MX, SPF, DKIM, DMARC, and related records during the website move. If email is moving too, create mailboxes and aliases at the destination, migrate messages, verify authentication records, and plan a short overlap period if the providers support it. Never delete the old mail service until delivery has been tested and important messages are accessible.
The guide to business email on a custom domain provides a focused review of mailbox setup and DNS checks.
5. Map URLs and preserve SEO signals
Export a list of important URLs from analytics, search data, the current sitemap, and the site itself. Compare the old and new URL structures. If paths are changing, create a one-to-one redirect map, preferably using permanent server-side redirects. Avoid sending every old URL to the homepage; redirect each page to its closest relevant replacement, or return an appropriate not-found response when no replacement exists.
Check canonical tags, robots directives, XML sitemaps, pagination, structured data, internal links, and language or regional annotations if the site uses them. Make sure a staging environment has not left behind a noindex directive or password rule that will be copied into production.
6. Confirm SSL and performance settings
Install and validate the certificate for every public hostname before changing traffic. Test both the preferred HTTPS address and common alternate forms, then confirm that HTTP redirects to HTTPS without redirect loops. Review mixed-content warnings caused by hard-coded HTTP assets. If a CDN is involved, verify its origin address, caching rules, TLS mode, purge process, and access controls. See CDN vs. web hosting for the distinction between the two layers.
Cadence and checkpoints
Use checkpoints instead of relying on one launch-day inspection:
- One to two weeks before: lower DNS record time-to-live values if your plan and provider allow it, inventory records, freeze nonessential releases, create backups, and confirm access to registrar, DNS, hosting, email, analytics, and search tools.
- Several days before: build the destination site, restore a backup, test application workflows, prepare redirects, install SSL, and record baseline measurements for uptime, response time, crawl errors, traffic, conversions, and email delivery.
- Immediately before the switch: take a final database and file backup, pause content changes if possible, confirm the destination is ready, and capture the final DNS zone.
- Launch window: change only the intended DNS records, note the exact time, monitor both old and new systems, and use a DNS propagation checker from more than one network or location.
- First hour: test the homepage, representative content pages, redirects, forms, login, checkout or lead flow, robots.txt, sitemap, SSL, and email sending and receiving.
- First day: inspect logs, error rates, server resources, crawl reports, analytics, cache behavior, and customer support reports. Keep the old environment available until the new site is stable and rollback is no longer needed.
- First week: compare traffic, indexed URLs, rankings, conversions, response times, and email delivery with the baseline. Resolve recurring errors rather than dismissing isolated symptoms.
For complex applications, use a staging environment and a documented rollback threshold. For example, decide in advance which errors would justify reverting DNS or restoring the previous application, rather than making that decision under pressure.
How to interpret changes
DNS results can differ by resolver and location while records update. A temporary difference does not necessarily mean the migration failed, but a wrong record, unexpectedly long cache time, or inconsistent authoritative nameserver configuration requires investigation. Compare the authoritative DNS answer with results from several public resolvers, and verify that the record points to the intended service.
A spike in server errors usually points to an application, database, permissions, runtime, or environment-variable problem rather than DNS. Review web-server and application logs, then reproduce the failing request. A page that loads but loses styles or scripts often indicates an incorrect asset path, blocked resource, CDN issue, or mixed-content problem.
Search traffic may fluctuate after a migration, particularly when URLs, redirects, canonicals, or crawl directives change. Check technical causes before concluding that the host itself caused an SEO decline. Compare the old and new URL sets, review redirect status codes, inspect representative pages, and submit an updated sitemap when appropriate.
Email problems should be separated into different categories: missing MX records affect routing, authentication failures affect trust and delivery, and mailbox or quota issues affect receipt. Test both directions using more than one mailbox and inspect message headers when possible. A migration can leave the website healthy while email is broken, so email deserves its own checkpoint.
When to revisit
Revisit this checklist before every significant infrastructure change, not only a complete host move. Use it for a domain transfer, DNS provider change, CDN introduction, WordPress platform change, database upgrade, email-host migration, or redesign that changes URLs. A monthly or quarterly review is also useful for sites with active releases or several administrators.
During each review, confirm that backups still restore, registrar and DNS access is current, SSL renewal is functioning, monitoring alerts reach the right people, and the documented DNS zone matches production. Check hosting resource usage, uptime records, application error rates, page performance, email authentication, redirect behavior, and search-console coverage. Review renewal dates and ownership details for domains, hosting, certificates, plugins, and third-party services.
Keep a current migration worksheet containing the latest backup location, provider contacts, DNS records, service dependencies, rollback steps, and the date of the last successful test. When the next migration arrives, this record will reduce guesswork and make the launch easier to audit. For infrastructure-specific preparation, compare hosting options for developers, review domain privacy protection, and keep the website migration checklist available as a recurring operational reference.
Next action: create the worksheet today, export your current DNS records, verify one restorable backup, and schedule a recurring review. A migration is safest when its critical details are known before the change window begins.
