How to Migrate a WordPress Site to a New Host

Overview

If you want a safe WordPress hosting migration, the goal is simple: move files, database, and configuration without breaking traffic, forms, email, logins, or search visibility. The exact tools may change over time, but the operating principles stay the same.

Before you move a WordPress website, keep these four rules in mind:

• Take a full backup you can restore independently. Do not rely only on the old host's automated backups.
• Build and test the new environment before changing DNS. DNS should be the final switch, not the first step.
• Lower risk by freezing changes during the cutover window. That includes new posts, orders, form submissions, and plugin updates where possible.
• Document your current setup. Record DNS records, plugin list, PHP version, SSL method, cron jobs, redirects, caching rules, and email routing before you touch anything.

A WordPress migration usually includes these components:

• WordPress core files, themes, plugins, uploads, and media library
• The WordPress database
• wp-config.php settings and any custom server rules
• DNS records for the website and sometimes email
• SSL configuration
• Caching, CDN, firewall, and security settings

If you are also moving DNS or domain management, review your records carefully. A hosting migration and a domain transfer are different tasks, even when they happen close together. If you need a broader preflight process, see Website Migration Checklist: Move Your Site to a New Host Safely. If DNS changes are part of your move, How to Point a Domain to Your Hosting Provider: Complete DNS Setup Guide and DNS Records Explained: A, AAAA, CNAME, MX, TXT, NS, and SRV are useful companion references.

Pre-migration checklist

• Confirm access to the old host: file manager, SFTP, database admin, control panel, backups
• Confirm access to the new host: control panel, SSH or SFTP, database credentials, temporary URL or staging access
• Note the current PHP version, memory limit, database version, and active extensions
• Export a current list of DNS records, especially A, AAAA, CNAME, MX, TXT, and any CDN or verification records
• Take an on-demand backup of files and database and store it off-host
• Put transactional sites on a migration schedule with a defined freeze window
• Check whether email is tied to the current host before changing nameservers or DNS
• Reduce TTL on key DNS records ahead of time if you control them and have time to plan

Checklist by scenario

Use the scenario that matches your setup. The steps overlap, but the risk points differ depending on how much infrastructure is changing.

Scenario 1: Standard WordPress hosting migration with a plugin

This is often the fastest path for brochure sites, blogs, and lower-complexity business sites.

1. Prepare the destination host. Create the target site, database if required, and SSL-ready environment. Match PHP settings as closely as possible to the source.
2. Clean up the source site. Remove unused plugins, themes, stale backups, and large cache files so you are not migrating unnecessary data.
3. Create a fresh full backup. Keep one copy locally before using any migration plugin.
4. Run the migration tool. Export from the source and import to the destination according to the tool's workflow.
5. Update configuration if needed. Some tools handle URL and path updates automatically; others may require a search-and-replace in the database.
6. Test on a temporary URL, staging domain, or hosts file override. Verify pages, admin login, forms, media, menus, and key plugins before pointing the live domain.
7. Point DNS to the new host. Update the relevant A record, CNAME, or nameservers based on your setup.
8. Monitor propagation and keep the old host active temporarily. Do not cancel the old plan until traffic clearly resolves to the new environment and the site is stable.

This scenario works well when you want to transfer WordPress hosting with minimal manual intervention. It is less ideal when the site has custom server rules, unusual file structure, or heavy ecommerce activity.

Scenario 2: Manual migration of files and database

Manual migration gives you more control and is often preferred by developers, IT admins, and anyone moving between different hosting stacks.

1. Download site files. Copy the full WordPress directory, including hidden files such as .htaccess if applicable.
2. Export the database. Use phpMyAdmin, a control panel database tool, or command line access.
3. Create the destination database. Create a new database and user with proper privileges on the new host.
4. Upload files to the new host. Preserve directory structure and file permissions where appropriate.
5. Import the database. Load the SQL export into the new database.
6. Update wp-config.php. Set the new database name, username, password, and host.
7. Run a URL search-and-replace if the temporary domain differs. Use a safe method that handles serialized data correctly.
8. Review rewrite rules and permalinks. Re-save permalinks in WordPress admin if needed.
9. Test before DNS cutover. Use a temporary preview method to validate the migrated site.
10. Switch DNS and monitor. Keep both environments available during propagation.

Manual migration is usually better for custom themes, membership sites, WooCommerce stores, multisite considerations, and moves from shared hosting to scalable hosting environments like VPS hosting or a cloud server for website workloads.

Scenario 3: Migrating to managed WordPress hosting

Managed WordPress hosting often includes a website migration service or guided tooling. Even if the host assists, you should still treat the move as an operational change you own.

1. Confirm what the host migrates. Some providers move the site only, while DNS, email, staging, backups, or CDN settings may remain your responsibility.
2. Ask about excluded items. Large media libraries, custom cron jobs, old PHP applications, or non-WordPress subdomains may need separate handling.
3. Check caching and security layers. Managed platforms may replace your existing cache plugin, firewall plugin, or backup plugin.
4. Validate staging and push workflows. Make sure the new platform fits your update and deployment habits before go-live.
5. Review post-migration performance settings. Reconfigure image optimization, object cache, redirects, CDN integration, and SSL.

This route is appealing if your main priority is fast web hosting, less server maintenance, and support during the migration window. It is still important to inspect the result carefully rather than assume the process is complete because the files imported successfully.

Scenario 4: High-change sites such as WooCommerce, memberships, or bookings

Sites with orders, account changes, or time-sensitive user actions need an extra layer of caution because the database can change constantly.

1. Schedule a low-traffic migration window. Pick a time with fewer orders or account actions.
2. Freeze content and transactions if possible. Maintenance mode may be appropriate for a short final sync.
3. Take an initial copy, then a final delta copy. The first migration gets most of the site over; the final sync captures recent database changes.
4. Verify payment, email, and webhook integrations. Test order confirmation emails, payment callbacks, and plugin automations.
5. Check background jobs. Cron tasks, subscription renewals, queue workers, and booking reminders must run on the new host.
6. Retain the old environment until business operations are clearly normal. Do not remove the source site too early.

If you run ecommerce, also review host suitability before you move. Best Hosting for WooCommerce Stores: Features, Limits, and Upgrade Triggers can help you assess whether the new environment fits the workload.

Scenario 5: Migration that also changes DNS, email, or domain control

This is where many otherwise clean migrations go wrong. The website may move successfully while email breaks because MX, SPF, DKIM, or DMARC records were overlooked.

1. Inventory all current DNS records. Do not assume the zone contains only website records.
2. Replicate non-web records before cutover. Preserve MX, TXT, verification, autodiscover, and other business-critical entries.
3. Confirm whether you are changing nameservers or only specific records. Nameserver changes affect the entire zone.
4. Test email after the change. Send and receive messages from external accounts.
5. Verify authentication records. Check SPF, DKIM, and DMARC if business email is in use.

For this scenario, see SPF, DKIM, and DMARC Explained for Website Owners, How to Set Up Business Email for a New Domain, and How to Transfer a Domain Name Without Downtime.

What to double-check

After you move a WordPress website, the site may look fine on the homepage while deeper functions fail. This is the section worth revisiting before every cutover.

Site function checks

• Front page, key landing pages, blog posts, category pages, and search results
• Admin login, password reset, user registration, and role permissions
• Contact forms, anti-spam tools, and notification emails
• Media library paths, image thumbnails, PDF links, and embedded video
• Navigation menus, widgets, internal links, and redirects
• Custom post types, taxonomies, and page builder layouts

Configuration checks

• Database credentials in wp-config.php
• Correct site URL and home URL values
• Permalink structure and rewrite rules
• File permissions on uploads, cache, and plugin directories
• PHP version compatibility for plugins and theme
• Cron job behavior and scheduled task execution

Security and performance checks

• SSL certificate installed and the site loading over HTTPS
• No mixed-content warnings from old HTTP assets
• Caching configured appropriately for the new host
• CDN, WAF, or reverse proxy settings updated to the new origin IP if needed
• Backups enabled on the new host and tested
• Firewall, security plugin, and rate-limiting rules not blocking legitimate traffic

SEO and analytics checks

• Canonical tags and robots settings unchanged unless intentionally updated
• XML sitemap accessible
• Analytics, tag manager, and conversion tracking still firing
• Search console or webmaster verification records intact if DNS changed
• Redirects preserved, especially from old URLs or legacy structures

If the move includes a host upgrade, this is also a good time to benchmark performance on the new stack. Performance is not only about faster hardware. It often depends on the cache layer, PHP workers, image delivery, database responsiveness, and application overhead. In other words, secure web hosting and fast web hosting are partly operational outcomes, not just product labels.

Common mistakes

Most migration issues come from skipping a small validation step, not from the transfer itself. These are the mistakes that repeatedly create downtime or confusing partial failures.

• Changing DNS before testing the destination. Once visitors resolve to the new host, you are debugging in production.
• Forgetting email-related DNS records. Website traffic may work while mail stops sending or receiving.
• Relying on one backup method. A plugin snapshot is helpful, but an independent file and database backup is safer.
• Ignoring PHP and extension differences. A plugin that worked on the old host may fail silently on a different version or missing module.
• Cancelling the old host too early. Keep the source available until you have verified the new environment over time.
• Running unsafe search-and-replace operations. Serialized WordPress data can break if updated carelessly.
• Leaving cache or CDN settings pointed at the old origin. This can create inconsistent results that look like DNS problems.
• Skipping transactional testing. Homepage checks are not enough for stores, memberships, or booking systems.
• Confusing domain transfer with hosting migration. You can point a domain to new hosting without moving the domain registrar right away.
• Failing to review renewal and support terms on the new host. Migration is also a good time to clarify backup policies, support boundaries, and pricing structure. For that, see Web Hosting Pricing Guide: Intro Rates, Renewals, and Hidden Costs to Check.

When to revisit

This checklist is worth revisiting any time the inputs change, not only when you are actively moving a site. A migration plan ages quickly when plugins, DNS providers, hosting workflows, or business requirements change.

Review and refresh your WordPress migration guide in these situations:

• Before seasonal planning cycles. If traffic spikes are coming, validate whether your current host still fits the workload and whether a planned move needs extra lead time.
• When workflows or tools change. New backup plugins, new deployment methods, different DNS providers, or a shift to managed WordPress hosting all change the runbook.
• When adding ecommerce, memberships, or bookings. A once-simple site can become a high-change application that needs a different migration process.
• When changing domain and hosting responsibilities. If registrar, DNS, email, and hosting are spread across multiple vendors, document ownership clearly.
• After any major platform update. Theme rewrites, plugin consolidation, PHP upgrades, and security-layer changes all affect migration behavior.

Practical action plan for your next migration

1. Create a one-page inventory of your current WordPress environment: host, registrar, DNS provider, email provider, backups, SSL, CDN, and critical plugins.
2. Decide which migration path applies: plugin-based, manual, host-assisted, or staged/delta migration for high-change sites.
3. Take and verify independent backups before doing anything else.
4. Build and test the destination environment fully before changing live DNS.
5. Switch DNS only after the site, SSL, forms, admin, and key workflows pass review.
6. Monitor for at least a short stability window before retiring the old host.
7. Update your internal checklist with anything that was harder than expected so the next migration is easier.

A good WordPress hosting migration is repeatable, documented, and boring in the best way. If you use this checklist each time you transfer WordPress hosting, you reduce the chance of downtime, protect email and DNS settings, and make future platform changes much easier to manage.