Moving a WordPress website to a new host does not have to mean lost traffic, broken email, or extended downtime. This reusable WordPress website migration checklist covers preparation, file and database transfer, staging tests, DNS cutover, SEO verification, email continuity, and rollback planning so you can move hosts with control.
Overview
A WordPress hosting migration usually involves four separate systems: the WordPress files, the database, the domain and DNS settings, and any services connected to the site. Treating the move as a single copy-and-paste task is a common source of avoidable problems.
The safest approach is to build a complete inventory, create independent backups, copy the site to the new host, test it privately, and change DNS only after the new environment is ready. Keep the old hosting account active until the new site has passed post-launch checks and the normal DNS transition period has ended.
Migration inventory
- Domain and DNS: Record the current nameservers, A records, CNAME records, MX records, TXT records, and any subdomains.
- WordPress: Note the WordPress version, active theme, plugins, multisite status, cron jobs, scheduled tasks, and administrator accounts.
- Hosting: Record the PHP version, database type and version, server rules, caching configuration, SSL setup, storage paths, and access credentials.
- Business functions: List contact forms, checkout pages, memberships, appointment tools, analytics, advertising tags, webhooks, and integrations.
- SEO assets: Check the XML sitemap, robots.txt, canonical settings, redirects, structured data, media URLs, and any staging restrictions.
- Email: Identify whether mail is hosted with the current web host, a separate provider, or a combination of services.
DNS changes are not the same as transferring a domain registration. If you are also changing registrars, separate that task from the hosting migration where possible. The domain transfer guide explains the registrar side of that process.
Checklist by scenario
Scenario 1: A standard WordPress site with low traffic
- Choose a migration window. Select a period when orders, form submissions, publishing, and administrative activity are lower. Lower activity reduces the chance of data changing during the final copy.
- Reduce DNS uncertainty. If you control the DNS zone, review the TTL values before the move. A lower TTL may help changes be recognised sooner, but DNS resolvers do not all behave identically.
- Create two backups. Export the complete database and copy the entire WordPress installation, including
wp-content, configuration files, uploads, custom themes, and server rules. Store at least one backup outside the current host. - Prepare the new account. Confirm the target PHP and database versions are compatible with your WordPress version, theme, and plugins. Create the database, database user, and correct permissions.
- Copy the site. Upload the files and import the database using the tools provided by the new host. If using a migration plugin, follow its compatibility and storage requirements and keep a manual backup.
- Update connection details. Set the new database name, username, password, and host in the new environment. Do not replace the live site until the copied version has been tested.
- Test with a temporary address. Use a staging URL, hosts-file entry, or hosting preview method. Check the homepage, internal links, images, menus, search, forms, login, comments if enabled, and key conversion paths.
- Install SSL before launch. Confirm that HTTPS works on the final domain and that WordPress Address and Site Address use the intended protocol. Resolve mixed-content problems before directing visitors to the new server. See the HTTPS and mixed-content troubleshooting guide if browser warnings appear.
- Perform the final copy. If visitors can submit forms, place orders, or publish content, take a final database backup immediately before DNS cutover. Copy any files or records created since the first transfer.
- Change DNS. Update the relevant A, AAAA, CNAME, or nameserver records. Do not alter MX records unless email is intentionally moving. The DNS records guide can help identify each record type.
- Monitor both hosts. Check the new server and the old server during the transition. Keep the old site available while DNS caches change and verify that visitors are reaching the intended host.
Scenario 2: An online store, membership site, or frequently changing website
For a site with regular orders, registrations, comments, or content updates, the main risk is database drift. A simple file transfer may leave new transactions on the old host after the database was copied.
- Put the site into a planned maintenance or read-only mode for the shortest practical period during the final database export.
- Record the exact time of the final backup and confirm that it imported successfully.
- Pause scheduled jobs that could send duplicate emails, process payments, or create records on both hosts.
- Check payment, login, account, order, and notification workflows on the new host before reopening the site.
- Compare recent orders, users, submissions, and published content between the final backup and the new database.
Scenario 3: A site with business email on the current host
Do not assume that moving website files moves mailboxes safely. Before changing DNS, identify every mailbox, forwarding rule, autoresponder, alias, spam setting, and mail archive. Preserve the existing MX, SPF, DKIM, and DMARC records if the email provider is not changing. If mail is moving too, plan that as a separate migration with its own backups and verification steps. The domain, hosting, SSL, and email setup guide provides a useful DNS review framework.
What to double-check
Staging-site test table
| Area | Test | Pass condition |
|---|---|---|
| URLs | Open representative pages, posts, categories, and media | No unexpected redirects, 404 errors, or incorrect domains |
| Forms | Submit each important form | Success message appears and the notification reaches its destination |
| Database | Check recent content, users, products, and settings | Expected records and relationships are present |
| Performance | Test key pages on desktop and mobile | No obvious slow queries, missing assets, or cache conflicts |
| Security | Review file permissions, admin access, SSL, and security tools | Only intended users and services have access |
| SEO | Inspect robots.txt, sitemap, canonicals, and metadata | Production pages are crawlable and staging controls are removed |
| Send and receive test messages | Mail delivers and the correct MX and authentication records remain |
SEO and redirect verification
A host change should not require changing URLs. Confirm that the new server preserves the same permalink structure, trailing-slash behaviour, preferred hostname, and HTTPS rules. Test a sample of important old URLs and confirm they return the intended status. If URLs must change, create one-to-one permanent redirects and update internal links, canonical tags, XML sitemaps, and relevant references.
Review analytics and search tools after launch. Confirm that tracking codes load once, conversions are recorded, the sitemap is available, and the site is not accidentally blocked by a staging robots.txt file or noindex setting. Avoid deleting redirects or changing several SEO elements at the same time as the hosting move; isolating changes makes diagnosis easier.
Rollback procedure
Write the rollback steps before changing DNS. Include the previous DNS values, the location of the old hosting account, the latest verified backup, the person authorised to make the change, and the checks that trigger a rollback. If the new site shows data loss, broken checkout, widespread server errors, or a serious email problem, point DNS back to the old host, restore the affected service, and investigate before attempting the cutover again.
Common mistakes
- Deleting the old host too early: Keep the old environment available until the new site and email have been verified.
- Copying files but not the database: Posts, settings, users, orders, and plugin data are commonly stored in the database rather than in uploaded files.
- Forgetting hidden files: Server rules and configuration files can affect redirects, caching, security, and PHP behaviour.
- Changing MX records accidentally: A website DNS change should not interrupt email when mail remains with the existing provider.
- Testing only the homepage: Forms, admin login, search, media, checkout, scheduled jobs, and less-used templates can fail while the homepage appears normal.
- Leaving staging controls enabled: Noindex directives, password protection, or a blocked robots.txt file can remain after launch.
- Using a plugin without checking its limits: Large databases, restricted server permissions, unsupported PHP versions, or limited storage can interrupt automated migrations. Keep a manual backup regardless of the chosen workflow.
- Ignoring caching: Clear application, server, CDN, and browser caches when appropriate, then verify that visitors receive current content.
When to revisit
Use this checklist before every WordPress hosting migration, even when the new provider uses a familiar control panel. Revisit it before seasonal planning cycles, major launches, redesigns, domain changes, or a move from shared hosting to cloud hosting or VPS hosting. Hosting environments and migration tools change, so confirm supported PHP versions, database requirements, backup methods, SSL processes, and staging features before each project.
After launch, schedule a short operational review. Check uptime, forms, orders or registrations, email delivery, analytics, search visibility, backups, and security logs. Keep a dated migration record containing the final backup, DNS changes, test results, and rollback decision. For ongoing maintenance, pair this document with the website hosting maintenance checklist and review backup and recovery procedures regularly.
Action plan: inventory the current site today, confirm where DNS and email are managed, create a tested backup, build the new environment, complete the staging table, document rollback steps, and change DNS only when every critical check passes.
