Moving WordPress to a new host does not have to mean lost rankings, broken email, or a long outage. This reusable migration checklist walks through backups, staging, files, databases, DNS, SSL, redirects, analytics, testing, and rollback steps so you can move your website with greater control.
Overview
A WordPress hosting migration usually involves copying two core parts of the site: the WordPress files and the database. You must also reconnect the domain, confirm the server environment, preserve every important URL, and verify that supporting services still work after the move.
The safest approach is to prepare the new host while the old site remains live. Build and test a copy first, lower DNS timing values before the switch when appropriate, then change DNS only after the new installation is ready. Keep the old hosting account active until you have completed post-migration checks and are confident that a rollback is no longer necessary.
Before choosing a plan, compare the new environment with your current one. Check the supported PHP version, database type, available storage, server resources, SSL setup, backup tools, staging features, caching options, and control-panel workflow. A migration is not the right time to change several major variables at once unless you have a specific reason and a tested rollback plan.
For background on the wider setup, see Shared Hosting vs VPS vs Managed Hosting and the Website Launch Checklist.
Checklist by scenario
Before moving anything
- Record the current host, domain registrar, DNS provider, WordPress version, PHP version, database type, and SSL configuration.
- Confirm that you control the domain account, DNS account, hosting account, and administrative WordPress login.
- Export a complete backup of the database and all WordPress files, including
wp-content, uploads, themes, plugins, and configuration files. - Download or independently store at least one backup outside the current server.
- List active plugins, themes, custom code, scheduled tasks, forms, payment connections, email integrations, and third-party scripts.
- Record the current WordPress URL, site URL, permalink structure, robots settings, sitemap location, and any custom redirects.
- Capture baseline checks: key page URLs, search visibility, analytics activity, contact forms, checkout flows, and representative page-load results.
- Tell contributors when editing will pause. A short content freeze reduces the chance of losing new posts, comments, orders, or form submissions during the final transfer.
During the build on the new host
- Create the new hosting account and install the required WordPress-compatible environment. Match the current PHP and database versions first if compatibility is uncertain; upgrade later after testing.
- Create the database and database user, then note the database name, username, password, and host value required by the new provider.
- Transfer the WordPress files using the host's migration tool, a backup plugin, SFTP, or another controlled method. Avoid mixing partial copies from different methods unless you know exactly which files are current.
- Import the database and update the new
wp-config.phpvalues if the database name, user, password, or host has changed. - Check file ownership and permissions through the hosting control panel or provider documentation. Incorrect permissions can cause failed uploads, plugin errors, or inaccessible files.
- Use a temporary URL, staging address, hosts-file override, or provider preview method to test the new copy before public DNS changes. Prevent accidental indexing while the site is private or incomplete.
- Review site URLs carefully. Do not perform a blanket search-and-replace without a backup; serialized WordPress data can be damaged by unsuitable tools.
At the DNS changeover
- Confirm that the new site is complete and that the latest database backup has been imported.
- Lower DNS TTL in advance only if your DNS provider supports it and the timing fits your migration plan. TTL changes do not guarantee that every resolver will update immediately.
- Update the relevant A, AAAA, CNAME, or nameserver records according to the new host's instructions. Keep email records such as MX, SPF, DKIM, and DMARC intact unless email is moving too.
- Activate SSL on the new host and verify that both the preferred HTTPS version and any necessary HTTP-to-HTTPS behavior work correctly.
- Keep the old host online. During propagation, some visitors may reach the old server while others reach the new one.
- Continue checking both environments until DNS has settled across the networks and locations that matter to your audience.
For a closer explanation of records and propagation checks, use How to Point a Domain to Web Hosting.
After the switch
- Log in to WordPress and confirm the dashboard, media library, themes, plugins, and user accounts.
- Test the homepage, several old posts, category and tag pages, search, pagination, author pages, feeds, and any custom content types.
- Submit a test contact form and verify that delivery reaches the intended mailbox. Test transactional or notification email separately.
- Confirm analytics, tag management, advertising pixels, consent tools, and webmaster verification remain present and functional.
- Check the XML sitemap, robots.txt, canonical tags, indexability, and redirect behavior.
- Review server logs and WordPress error logs for PHP errors, missing files, database warnings, or repeated 404 responses.
- Keep a dated copy of the final backup and document the new host, DNS records, SSL settings, and renewal information.
What to double-check
A migration can appear successful while quietly losing important functions. Use this inventory before and after the move:
| Area | What to record before migration | What to test afterward |
|---|---|---|
| URLs and SEO | Top pages, permalink structure, redirects, canonicals, sitemap | Open representative URLs, crawl for 404s, confirm indexability |
| Content | Latest posts, media, comments, custom fields | Compare recent content and open images, downloads, and embeds |
| MX, SPF, DKIM, DMARC, forms, notifications | Send and receive messages; submit every important form | |
| Security | SSL, firewall, login protection, backups | Test HTTPS, admin login, backup completion, and alerts |
| Performance | Caching, CDN, image optimization, PHP version | Check key templates and monitor errors or unusual slowdowns |
| Tracking | Analytics IDs, tag manager, conversion events | Confirm real-time visits and test important events |
Create a URL and plugin inventory rather than relying on memory. A simple sheet can include: URL, page type, organic importance, redirect destination, plugin dependency, test result, and notes. This makes it easier to separate a hosting move from an unplanned redesign or URL change.
Most hosting migrations should preserve URLs. If a URL must change, map the old address to its closest relevant new address with a server-level permanent redirect, update internal links, and test the destination. Do not redirect every old page to the homepage as a substitute for proper mapping.
Common mistakes
- Deleting the old host too soon: Keep it available until DNS, email, forms, analytics, and crawl checks are complete.
- Copying files without the database: Posts, settings, users, comments, and many plugin configurations live in the database.
- Forgetting recent changes: A backup taken days before migration may omit new content or orders. Take a final backup immediately before the cutover.
- Changing URLs during the move: A host migration should generally preserve the existing URL structure. Treat redesigns and domain changes as separate projects when possible.
- Ignoring email DNS: Changing nameservers or DNS records can interrupt mail even when the website works. Record every mail-related record first.
- Testing only the homepage: Problems often appear in media files, forms, search, archives, checkout pages, or less-visited templates.
- Upgrading everything at once: A new PHP version, theme, plugin set, and hosting stack make errors harder to diagnose. Establish a stable baseline, then update in controlled steps.
- Leaving a staging copy indexable: Protect private copies and check that the live site's robots and canonical settings were not inherited incorrectly.
When to revisit
Use this checklist before a host renewal, major traffic season, site redesign, domain change, PHP upgrade, or performance-related move. Revisit it whenever your hosting control panel, migration tool, WordPress version, active plugins, or DNS provider changes. Hosting workflows differ, so confirm exact steps and compatibility requirements in the current provider documentation before starting.
Schedule a final review after the first full day of traffic and again after your normal reporting cycle. Compare search impressions, analytics visits, conversions, server errors, uptime observations, and crawl results with the pre-migration baseline. A temporary fluctuation does not automatically indicate an SEO failure, but unexplained changes deserve investigation.
Practical next step: choose a migration window, export a complete backup, create the URL and plugin inventory, and write down the DNS rollback values before touching the live site. If something fails, restore the previous DNS records, keep the old host available, and investigate from the logs rather than making several untracked changes at once.
