Move WordPress Site to Another Host Without Errors

A hosting move can fix slow load times, poor support, storage limits, or reliability problems. It can also break forms, images, email, checkout, tracking, and SEO if you rush it. This guide shows you how to move WordPress site to another host with a practical migration workflow built around backups, staging, DNS control, and post-launch testing.

This is written for business owners, marketing teams, and site managers who need the move done carefully, not just quickly.

Key Takeaways

• A safe WordPress migration starts before any files are moved. You need backups, access checks, and a rollback plan.
• The safest method depends on site size, complexity, and business risk. A brochure site is different from WooCommerce.
• DNS should be changed only after the migrated site has been tested on the new server.
• Post-launch checks should cover forms, checkout, redirects, SSL, email records, tracking, and Google Search Console.
• Keep the old host active for at least seven days after launch so you can roll back quickly if needed.

Before You Move WordPress Site to Another Host

The biggest migration problems usually come from missing details, not from the transfer itself. Before you move WordPress site to another host, create a simple migration inventory.

At minimum, document:

• Current hosting company and control panel access.
• Domain registrar access.
• DNS provider access, such as Cloudflare, GoDaddy, or Namecheap.
• WordPress admin login.
• SFTP or SSH access.
• Database access through phpMyAdmin or the host’s database tool.
• Active theme, child theme, and custom code snippets.
• Active plugins, especially caching, security, form, membership, and ecommerce plugins.
• Email records, including MX, SPF, DKIM, and DMARC.
• Tracking tools, such as Google Analytics, Google Tag Manager, Meta Pixel, or call tracking scripts.

This inventory matters because a WordPress site is not only files and a database. A typical business site also depends on DNS settings, SSL certificates, cron jobs, SMTP settings, analytics scripts, API keys, and form notifications.

For sites already under a care plan, this prep work belongs inside a larger technical upkeep process. A regular WordPress website maintenance and updates workflow makes migrations easier because backups, updates, and plugin inventories are already current.

Lower DNS TTL before the migration

If you control DNS, reduce the TTL value before launch day. TTL stands for “time to live,” and it tells DNS resolvers how long to cache a record before checking for updates again.

For example, if the current A record TTL is 14,400 seconds, some visitors may continue reaching the old server for hours after the switch. Lowering it to 300 seconds at least 24 hours before migration gives you a faster cutover window.

This does not guarantee instant propagation everywhere, but it reduces the practical waiting period when you point the domain to the new host.

Take two backups, not one

Before changing anything, take two separate backups:

Backup Type	What It Includes	Why It Matters
Full site backup	WordPress files, themes, plugins, uploads, and database.	Gives you a complete restore point if the migration fails.
Database-only backup	Posts, pages, users, orders, settings, and plugin data.	Protects the most frequently changing part of the site.

For a simple business website, a plugin backup may be enough. For WooCommerce, membership, LMS, booking, or high-traffic sites, use a server-level or SSH-based backup so you are not relying on a plugin timeout.

A useful real-world habit: name backup files with the domain, date, and purpose.

example-com-pre-migration-full-2026-06-11.zip

example-com-pre-migration-db-2026-06-11.sql

Then verify the backup. Do not just assume the file downloaded correctly. Open the archive, check that wp-content/uploads/ is present, and confirm the .sql file is not empty.

Choose the Right WordPress Migration Method

There is no single best way to move WordPress site to another host. The right method depends on site size, access level, and how costly downtime would be.

Migration Method	Best For	Skill Level	Main Risk
Migration plugin	Small to medium business sites.	Beginner to intermediate.	File size limits or timeout errors.
Manual SFTP + database migration	Sites where you need more control.	Intermediate.	Database credential mistakes or incomplete uploads.
WP-CLI and server tools	Large, complex, or high-value sites.	Advanced.	Wrong commands can affect production data.
Managed host migration	Sites moving into a host that offers migration support.	Beginner.	Less visibility into the exact steps performed.
Professional migration	Ecommerce, membership, custom, or revenue-critical sites.	Agency or developer.	Requires clear scope and access handoff.

WordPress.org’s own documentation explains the basic structure of moving WordPress: files, database, configuration, and URL updates all need to be handled carefully. The official WordPress moving guide is a useful reference if you want to understand the underlying mechanics.

When a plugin migration is enough

A plugin-based migration is usually fine when the site is small, the database is not huge, and there is no complex ecommerce or membership logic.

Common tools include:

• Duplicator
• All-in-One WP Migration
• UpdraftPlus Premium
• BlogVault
• WPvivid

The practical limit is not just the size of the site. It is the server environment. A 900 MB site may migrate smoothly on one host and fail repeatedly on another because of PHP memory, upload limits, or execution time settings.

When manual migration is safer

Manual migration gives you more visibility. You download the site files, export the database, upload both to the new server, create a new database, update wp-config.php, and run a proper search and replace.

This is often safer for sites where you need to inspect what is moving. It also helps when a plugin cannot package the site because the old host is slow or restricted.

The main file you will edit is wp-config.php. These values must match the new database exactly:

define( ‘DB_NAME’, ‘new_database_name’ );

define( ‘DB_USER’, ‘new_database_user’ );

define( ‘DB_PASSWORD’, ‘new_database_password’ );

define( ‘DB_HOST’, ‘localhost’ );

Some hosts do not use localhost for DB_HOST. Check the new host’s database documentation before assuming.

When WP-CLI is the better option

For larger sites, WP-CLI is usually cleaner than clicking through a browser-based database import. It avoids many timeout problems and lets you run precise commands through SSH.

A typical WP-CLI database workflow may look like this:

wp db export pre-migration.sql

wp db import pre-migration.sql

wp search-replace ‘https://oldexample.com’ ‘https://newexample.com’ –all-tables –precise –dry-run

The –dry-run flag is important. It shows what would change before writing anything to the database.

WP-CLI’s official search-replace command documentation explains options such as –precise, –all-tables, and –dry-run. These matter because WordPress stores some data in serialized formats, and careless find-and-replace work can break widgets, theme options, and plugin settings.

Step-by-Step WordPress Host Migration Process

Once backups are verified and the new hosting account is ready, use a controlled sequence. Do not update DNS first. Build and test the new copy before visitors reach it.

1. Prepare the new hosting environment

Start by matching the new server to the site’s needs. Check:

• PHP version.
• MySQL or MariaDB version.
• PHP memory limit.
• Max upload size.
• Max execution time.
• SSL availability.
• Server caching settings.
• Staging environment availability.
• Cron behavior.
• Email sending rules.

If your current site runs PHP 8.1 and the new host defaults to PHP 8.3, test carefully. Most modern plugins should be compatible, but older themes, abandoned plugins, or custom code may throw warnings or fatal errors.

For a business site with custom templates, integrations, or special functionality, it may be worth reviewing the site as part of a broader WordPress development check before moving. A migration can expose hidden technical debt that was already there.

2. Move the WordPress files

If you are migrating manually, download the full WordPress root directory from the old server. This is usually one of these folders:

/public_html/

/www/

/htdocs/

/site-name/

The most important folder is:

/wp-content/

It contains themes, plugins, uploads, and many site-specific assets. If this folder is incomplete, the migrated site may load with missing images, broken layouts, or inactive functionality.

A practical tip from production migrations: if the old host has a file manager, compress the site into one archive before downloading. Moving one .zip file is usually faster and less error-prone than transferring thousands of small image and plugin files over SFTP.

3. Export and import the database

Export the database from the old host using phpMyAdmin, Adminer, WP-CLI, or the hosting control panel. For most WordPress sites, the export should be an .sql file.

Then create a new database on the destination host:

1. Create the database.
2. Create a database user.
3. Assign the user to the database.
4. Grant all required privileges.
5. Import the .sql file.
6. Update wp-config.php with the new credentials.

That third step is easy to miss. Many “Error establishing a database connection” issues happen because the database user exists, but it was never assigned to the database.

4. Run search and replace safely

If the domain stays the same, you may still need search and replace if the staging URL, temporary URL, or protocol changed.

Examples:

http://example.com → https://example.com

http://www.example.com → https://example.com

https://old-staging-host.com/~account → https://example.com

Do not open the SQL file and run a basic text editor replacement unless you fully understand serialized data. Use WP-CLI or a trusted database search-and-replace tool.

A safe WP-CLI example:

wp search-replace ‘http://example.com’ ‘https://example.com’ –all-tables –precise –dry-run

wp search-replace ‘http://example.com’ ‘https://example.com’ –all-tables –precise

Run the dry run first. Then run the live command only after reviewing the output.

5. Test the site before changing DNS

This is the step that prevents most migration emergencies. Test the migrated site privately before pointing the domain to the new host.

Use one of these options:

• A staging URL provided by the host.
• A temporary host URL.
• A local hosts file entry that points your domain to the new server IP.

The hosts file method is the most realistic because your computer sees the real domain on the new server while everyone else still sees the old live site.

Your test should cover:

• Homepage.
• Main navigation.
• Service pages.
• Blog posts.
• Contact forms.
• Newsletter forms.
• Search.
• Login pages.
• Checkout, if WooCommerce is active.
• Payment gateway test mode, if possible.
• Image loading.
• Mobile layout.
• Admin dashboard access.
• Media uploads.
• Sitemap.
• Robots.txt.
• Canonical tags.
• Redirects.
• Tracking scripts.

For a deeper technical review, pair the migration test with a website audit checklist so you are not only checking whether the site loads, but whether it remains healthy for SEO, performance, and conversion.

6. Change DNS when the new site passes testing

When testing is complete, update the DNS records. Most standard host migrations involve changing the A record for the root domain and sometimes the www record.

Common examples:

Record	Name	Value
A	@	New server IP address
CNAME	www	Root domain or host-provided target
MX	@	Email provider mail server
TXT	@	SPF, DKIM, DMARC, verification records

Be careful with email. Moving web hosting does not always mean moving email hosting. If the domain uses Google Workspace, Microsoft 365, Zoho, or another email provider, preserve the MX and TXT records unless the email setup is intentionally changing.

Google’s Search Central documentation on site moves with URL changes is written for domain or URL changes, but the same principle applies to careful migration work: preserve crawlability, redirects, and signals so search engines can continue understanding the site.

Post-Launch Checks That Protect SEO and Revenue

Once DNS points to the new host, the migration enters the monitoring phase. This is where small missed details show up.

Run the following checks within the first hour:

• Visit the site from a mobile device on cellular data.
• Confirm SSL is active and there are no browser warnings.
• Submit every important form.
• Check that form notifications arrive.
• Test checkout if the site uses WooCommerce.
• Confirm admin login works.
• Purge all cache layers.
• Crawl the site for 404 errors.
• Confirm images load from the correct domain.
• Check that analytics is still recording visits.
• Review server error logs.
• Confirm the XML sitemap loads.
• Submit the sitemap in Google Search Console.

Then monitor again after 24 hours, 72 hours, and seven days.

A simple migration monitoring sheet can include:

Check	Tool	Timing
Broken pages	Screaming Frog or Sitebulb	First hour and 24 hours
Indexing and sitemap	Google Search Console	24 to 72 hours
Uptime	UptimeRobot or Better Stack	First seven days
SSL status	Browser and SSL checker	First hour
Form delivery	Manual test and SMTP logs	First hour
Speed	PageSpeed Insights or GTmetrix	24 hours after cache settles
Server errors	Hosting logs	First 24 hours

Do not cancel the old hosting plan immediately. Keep it active for at least seven days. If something serious appears, you can point DNS back to the old server while the issue is fixed.

Watch for migration issues that do not appear instantly

Some problems only show after real users interact with the site. For example, a brochure site may look fine until a contact form fails because SMTP was configured on the old host. A WooCommerce site may display products correctly but fail at checkout because webhooks were blocked by a firewall rule.

Common delayed issues include:

• Contact form emails not sending.
• WooCommerce payment webhooks failing.
• Scheduled posts not publishing.
• Backup plugins failing because paths changed.
• Cache plugins serving old asset paths.
• Security plugins blocking the new server IP.
• Mixed content warnings from old HTTP image URLs.
• 404 errors from hardcoded links in theme files.
• API integrations failing because the new server IP is not allowlisted.

This is why the first week after you move WordPress site to another host should include active monitoring, not just a quick “site looks fine” check.

When to Hire Help for a WordPress Migration

A DIY migration can be reasonable for a small site with low traffic, simple plugins, and a recent backup. It becomes risky when the site affects sales, lead generation, client access, or daily operations.

Consider professional support if the site has:

• WooCommerce orders, subscriptions, or memberships.
• A large database.
• Custom plugins or custom theme logic.
• API integrations with CRMs, booking tools, or payment systems.
• Heavy media libraries.
• Multiple user roles.
• Multisite setup.
• Strict uptime requirements.
• Known malware or security issues.
• Poor current hosting performance that may affect backups.

A useful rule: if losing a day of leads, orders, or client access would cost more than hiring help, do not treat the migration as a weekend experiment.

The safest migration is not the one with the fewest steps. It is the one with a verified backup, a tested new environment, a clear DNS plan, and a rollback path.

FAQs