Managed WordPress Hosting Migration Guide: Move a Site Without Losing Traffic or Data

Overview

A WordPress migration is more than copying a website folder. A working site usually includes a database, media uploads, themes, plugins, configuration files, scheduled tasks, DNS records, email services, analytics tags, and search-related settings. A successful move keeps those pieces aligned while changing the server that delivers the site.

Managed WordPress hosting may include provider-specific migration tools, staging environments, automated backups, security controls, or technical support. Features vary, so confirm exactly what the new plan supports before you begin. Check the current WordPress and PHP requirements, storage limits, traffic expectations, backup retention, staging workflow, SSL certificate setup, and available support. If you are comparing hosting types before moving, see our guide to shared hosting versus VPS.

The safest approach is to treat the migration as a controlled release:

1. Inventory the current site and its dependencies.
2. Back up the site and confirm that the backup can be restored.
3. Build and test a complete copy on the new host.
4. Lower unnecessary DNS delays before the planned switch, where appropriate.
5. Point the domain to the new environment and monitor the result.
6. Keep the old site available until verification and rollback decisions are complete.

Do not cancel the old hosting plan immediately. A migration is not finished when the files have been uploaded; it is finished when the new site serves the right content, forms work, tracking is present, and important URLs remain accessible.

Checklist by scenario

Before any migration

• Record the domain name, current host, new host, registrar, DNS provider, and account access details.
• List every domain and subdomain connected to the site, including www, staging, shop, member, or media subdomains.
• Export or document DNS records. Include A, AAAA, CNAME, MX, TXT, and any verification records that are still in use.
• Identify who handles email. Website hosting and business email may be separate services, and changing the wrong DNS record can interrupt mail.
• Note the active WordPress version, PHP version, theme, plugins, custom code, cron jobs, cache settings, and security tools.
• Make a full backup of the database and files. Store a copy outside the current hosting account.
• Confirm that the backup includes the wp-content directory, uploads, themes, plugins, and configuration details needed to reconnect the site.
• Record important URLs, redirects, canonical settings, robots directives, XML sitemaps, analytics IDs, tag manager settings, and Search Console verification methods.
• Pause large content changes during the final copy, or create a clear cut-off time so new posts, comments, orders, and form submissions are not missed.

When using a host migration tool

• Read the provider's instructions before changing DNS. A migration tool may create a temporary address or staging copy.
• Confirm whether the tool copies the database, media, custom files, redirects, and serialized data—not just the visible pages.
• Ask how the tool handles password-protected staging sites, caching, multisite installations, large databases, and sites with ecommerce or membership features.
• Compare the migrated copy with the original before approving the final switch.
• Check whether the tool changes URLs or search visibility settings while the copy is being tested.

For a manual migration

1. Create the new hosting account and confirm its WordPress, PHP, database, storage, and SSL requirements.
2. Copy the WordPress files and import the database using the new host's supported method.
3. Update the database connection details in the configuration file as required by the new environment.
4. Check file paths, permissions, rewrite rules, and any server-level configuration used by the old host.
5. Use a temporary URL, hosts-file test, or staging address to review the site before DNS changes. The exact method depends on the provider.
6. Replace temporary URLs only when you understand how the process affects serialized WordPress data. Use a migration tool designed for WordPress where possible.
7. Regenerate permalinks by saving the permalink settings, then test representative posts, pages, categories, tags, and media files.

For a domain or DNS change

• Confirm whether you are moving only hosting or also transferring the domain registration. These are separate operations.
• Keep the domain at the existing registrar if that is simpler; change only the DNS records or nameservers needed to connect the domain to hosting.
• Preserve MX and email-related TXT records unless your email provider gives different instructions.
• Set up SSL on the new host before or immediately after the domain points there, then test both HTTP and HTTPS behavior.
• Use the preferred domain format consistently, such as the non-www or www version, and redirect the other version.

What to double-check

Use the new host's staging copy as a review environment, not merely as proof that the homepage loads. The following table covers the checks most likely to reveal an incomplete migration.

Search visibility is usually protected by preserving the same domain, URL paths, status codes, content, and crawl settings. A hosting move by itself should not require a redesign or URL change. If URLs must change, create and test a redirect map before launch. For broader launch checks, use the website launch checklist.

Common mistakes

• Relying on one untested backup. A backup that cannot be restored is not a reliable rollback plan. Keep an independent copy and verify its contents.
• Changing nameservers without documenting email records. Website and email may use different systems. Capture the complete DNS zone before editing it.
• Leaving staging controls in production. Remove password protection when appropriate, but also check that noindex directives, temporary URLs, or development credentials remain.
• Copying files but not the database. Posts, settings, users, menus, and plugin data are commonly stored in the database and will not appear in a files-only copy.
• Testing only the homepage. Internal links, media, forms, search, login, redirects, and less-visited content can fail even when the homepage looks correct.
• Allowing two live sites to receive changes. New comments, orders, registrations, or posts can be lost if both environments remain active during the final cutover.
• Updating too many variables at once. Avoid combining a host migration, theme redesign, domain change, and major plugin overhaul unless you have a strong reason and a detailed test plan.
• Closing the old account too early. Keep the previous environment until DNS has settled for your audience and the new site has passed post-launch checks.

If the migration exposes a problem, switch back according to your documented rollback plan rather than making rushed changes. Rollback may mean restoring the old DNS records, reopening the old site, or restoring a backup, depending on what changed. Record the time of the switch and the exact DNS values so the decision is reversible.

When to revisit

Save this checklist and revisit it before every hosting migration, staging-to-production launch, major redesign, or recovery exercise. The workflow remains useful, but the details around supported PHP versions, WordPress releases, backup tools, staging features, caching, SSL setup, and provider migration tools can change.

Review it before seasonal traffic periods or other important publishing cycles, especially when the site handles registrations, orders, time-sensitive campaigns, or frequent content updates. Give yourself enough time for a full backup, a test migration, DNS changes, and a rollback decision—not just the file transfer.

For your next move, create a one-page migration record containing the current and new host, DNS provider, backup locations, cut-off time, test URL, launch owner, rollback trigger, and post-launch checks. Then follow this order:

1. Inventory the site and services.
2. Back up and verify the restore path.
3. Build the new copy.
4. Test content, URLs, forms, email, analytics, SSL, and indexing controls.
5. Cut over DNS while keeping the old site available.
6. Monitor the live site and search-critical URLs.
7. Retire the old hosting only after the migration is demonstrably stable.

For related DNS work, see how to connect a domain to web hosting. If you are transferring the registration as well as the hosting, use the separate domain transfer checklist so the two changes do not become confused.