How to Migrate a WordPress Site to a New Hosting Provider Without Downtime

Zero downtime is a sequencing problem, not a plugin problem

Almost every guide on how to migrate a WordPress site to a new host tells you the same thing: install a migration plugin, click a button, done. That advice works right up until the moment your visitors hit a “Error establishing a database connection” page, your padlock icon disappears, or your contact form emails vanish for three days.

The plugin is the easy part. What actually causes downtime is doing the right steps in the wrong order. Lowering your DNS TTL after you switch nameservers is useless. Installing the SSL certificate after the DNS change means hours of browser warnings. Moving MX records without checking where mail is actually hosted means lost leads.

This guide gives you the exact sequence our migration team at Ameritech Hosting follows, including the checks that happen before you touch a single file and the ones that happen 48 hours after the switch.

The short answer (for people in a hurry)

Lower your DNS TTL to 300 seconds, 48 hours before migration day.
Take a full manual backup: all files plus a database export. Store it off-server.
Document your email setup and current MX records.
Provision the new hosting account and match the PHP and MySQL versions.
Copy files and database to the new server (plugin or manual).
Test the site on the new server using your local hosts file, not a temporary URL.
Issue the SSL certificate on the new server before the DNS change.
Recreate email accounts and MX/SPF/DKIM/DMARC records.
Switch DNS. Keep the old host live for at least 7 days.
Run post-migration checks: links, forms, redirects, mixed content, search console.

Why the order matters: the migration timeline

When	Action	Why it must happen then
Day -7	Audit site, email accounts, cron jobs, third party integrations	You cannot migrate what you did not know existed
Day -3	Provision new hosting, match PHP/MySQL, create databases	Version mismatches cause fatal errors after the switch
Day -2	Lower DNS TTL to 300s	TTL changes only propagate after the old TTL expires
Day -1	Full backup, freeze content changes, copy site to new server	Anything published after the copy will be lost
Day 0 (morning)	Hosts file testing, SSL issuance, email setup	Everything must be green before a single visitor is routed
Day 0 (low traffic hour)	DNS switch	Minimises exposure during the propagation window
Day +1 to +7	Monitoring, final content sync, keep old host active	Some ISPs cache DNS longer than they should
Day +14	Raise TTL back to 3600s or higher, cancel old plan	Low TTL adds unnecessary DNS lookups long term

Step 1: Audit before you touch anything

Open a simple document and write down:

PHP version currently in use (Tools > Site Health > Info in WordPress).
MySQL or MariaDB version and database size.
Total disk usage, including the uploads folder. Anything over 2 GB usually rules out one click plugin migration on shared servers.
Every email address hosted on the current server, plus mailbox sizes.
Current DNS records: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC), and any verification records for Google, Microsoft, payment processors or ad platforms.
Cron jobs defined at server level (not WP-Cron).
SSL certificate type: free Let’s Encrypt, or a paid certificate that needs reissuing.
Licensed plugins that bind to a domain or site key.
Hardcoded IP addresses in third party services, webhooks, or firewall allowlists.

Run a full crawl of the site with a tool like Screaming Frog and export the list of URLs and status codes. This becomes your “before” snapshot for the post-migration comparison. Without it, you are guessing about broken links.

The email question nobody asks early enough

This is the single most common cause of real damage during a migration. Ask yourself: is my email hosted on the same server as my website?

If your MX records point to your web host, you must recreate every mailbox on the new server and migrate the actual messages (IMAP sync) before switching.
If your MX records point to Google Workspace, Microsoft 365 or another external provider, you must make sure those MX and TXT records are copied into the new DNS zone before you change nameservers. Changing nameservers without copying MX records means mail stops flowing immediately.

Step 2: Lower your DNS TTL (do this first, 48 hours ahead)

TTL (Time To Live) tells resolvers how long to cache your DNS record. If your A record TTL is 14400 seconds, some resolvers will keep sending visitors to your old server for up to four hours after you make the change.

The trick: a TTL reduction only takes effect after the previous TTL expires. So set it low well in advance.

Open your DNS zone editor (at your registrar or DNS provider).
Set the TTL of your A record, www CNAME and any subdomain records to 300 seconds.
Wait at least as long as the old TTL value, ideally 48 hours.
Verify with dig example.com +noall +answer or an online DNS checker that the reported TTL is now 300.

Nameserver change or A record change? Whenever possible, keep your DNS hosted where it is and simply update the A record. Nameserver changes are governed by the registry TTL (often 24 to 48 hours) and you cannot shorten those. Changing a single A record with a 300 second TTL gives you a five minute cutover instead of a two day one.

Step 3: Take a real backup (not just a plugin backup)

Even if you plan to use a migration plugin, take an independent manual backup first. If the plugin fails halfway through, this is your rollback.

Files

Connect via SFTP or SSH and download the entire WordPress root, including:

wp-content/ (themes, plugins, uploads, mu-plugins, languages)
wp-config.php
.htaccess (it is hidden, make sure your FTP client shows dotfiles)
Any custom folders outside WordPress: /scripts, /old, PDFs, invoices, anything your team dropped in over the years

With SSH access, this is far faster:

tar -czvf site-backup-$(date +%F).tar.gz /home/user/public_html

Database

Export via phpMyAdmin (Export > Custom > SQL > check “Add DROP TABLE”) or via command line:

mysqldump -u dbuser -p dbname > dbname-$(date +%F).sql

Or with WP-CLI, which handles the credentials for you:

wp db export backup.sql

Store both files somewhere that is not the old server. A backup that lives only on the machine you are about to abandon is not a backup. vmali.fr walks through the specifics.

Freeze content

From the moment you take the final export, stop publishing posts, stop accepting orders if possible, and tell your team. For a WooCommerce store, schedule the migration for the quietest hour of the week and put the store in a brief maintenance mode during the final database sync. Any order placed after the export and before the switch will exist only on the old server.

Step 4: Prepare the new hosting environment

Before you upload anything, make the destination match the source, then improve it. Much the same conclusion turns up on pantheon.io.

Set the PHP version to the same major version the site currently runs. Upgrade afterwards, once the site is confirmed stable. Migrating and upgrading PHP at the same time makes debugging twice as hard.
Check max_execution_time, memory_limit, upload_max_filesize and post_max_size. Migration plugins routinely fail on default values. 300 seconds and 512M are sensible temporary values.
Create the database, database user, and grant full privileges. Note the credentials.
Confirm the new server supports the same extensions your plugins need (imagick, intl, soap, zip).
If you use Redis or object caching, provision it now.

Step 5: Move the site

Method A: migration plugin (fastest for most sites)

Well tested options as of 2026:

Tool	Best for	Watch out for
Duplicator	Small to medium sites, full control over the installer	Large archives time out on shared plans; free version has size limits
All-in-One WP Migration	Simplicity, single file export	Free import limit; needs an extension for bigger sites
UpdraftPlus (Migrator)	Sites already using it for backups	Migration feature is a paid add-on
Migrate Guru	Very large sites (multi-GB), free	Processing happens on their servers, not yours
WP-CLI + rsync	Developers, huge sites, repeatable syncs	Requires SSH on both ends

Whichever you choose, install it on the source site, generate the package, then install a bare WordPress on the destination and run the import. Do not point the plugin at your live domain during import. Work against the server IP or a temporary hostname until testing is done.

Method B: manual migration (most reliable)

Upload the files. Extract your archive into the new document root, or use rsync over SSH:

rsync -avz -e ssh /home/olduser/public_html/ newuser@new-server:/home/newuser/public_html/

Import the database. Create the database on the new host, then:
```
mysql -u newdbuser -p newdbname < dbname.sql
```
Or import the .sql file through phpMyAdmin. If the file is over the upload limit, gzip it first or use the command line.

Edit wp-config.php with the new credentials:

define( 'DB_NAME', 'new_db_name' );
define( 'DB_USER', 'new_db_user' );
define( 'DB_PASSWORD', 'new_password' );
define( 'DB_HOST', 'localhost' );

Some hosts use a specific database hostname rather than localhost. Check your control panel.

Fix file ownership and permissions if you have root or SSH access: directories 755, files 644, wp-config.php 640.

If the domain is also changing

Never run a plain find and replace on a SQL dump. WordPress stores serialized arrays in the options and postmeta tables, and a naive replace breaks the string length prefixes, which silently destroys widget settings, theme options and page builder content.

Use a serialization aware tool:

wp search-replace 'http://olddomain.com' 'https://newdomain.com' --all-tables --precise --recurse-objects --dry-run

Run it with --dry-run first, read the report, then run it for real. If you have no CLI access, the Better Search Replace plugin does the same job through the dashboard.

Step 6: Test on the new server before any DNS change

This is the step that separates a clean migration from a public disaster. You need to view the site on the new server, at its real domain name, while the rest of the world still sees the old server.

Use your hosts file

Editing your local hosts file makes only your computer resolve the domain to the new IP address.

Windows: C:\Windows\System32\drivers\etc\hosts (open Notepad as administrator)
macOS / Linux: /etc/hosts (edit with sudo)

Add two lines using your new server IP:

203.0.113.45  example.com
203.0.113.45  www.example.com

Flush your DNS cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS) and load the site.

Why not use the temporary URL the host gives you? Because a temporary URL forces you to change the site URL in the database, which then has to be changed back, and it hides exactly the problems you are testing for: absolute URLs, canonical tags, SSL behaviour and hardcoded paths.

Your pre-switch test checklist

Homepage, a blog post, a category archive, a static page, and a 404 page all render correctly
Permalinks work (if not, resave Settings > Permalinks to regenerate .htaccess rules)
Images load from the uploads folder, not from the old server
Log in to wp-admin successfully
Contact form submits and delivers
Checkout flow completes in test mode (WooCommerce)
Search works
No PHP notices or warnings in the error log
Page speed is at least equal to the old host

Step 7: Install the SSL certificate before the DNS switch

A missing certificate is the fastest way to scare away every visitor with a full page browser warning. Handle it before the cutover, not after.

Most hosts can issue a Let’s Encrypt certificate using DNS validation, which works even while the domain still points elsewhere. Ask your new host to use the DNS-01 challenge, or add the required TXT record yourself.
If you have a paid certificate (OV, EV, wildcard), request a reissue for the new server and install it in advance.
If neither is possible, the fallback is to issue the certificate immediately after the DNS change. Realistically that means a few minutes of exposure, so do it during your quietest hour and be at the keyboard.

Killing mixed content warnings

Mixed content happens when the page loads over HTTPS but pulls an image, script or stylesheet over HTTP. The padlock disappears and browsers block the resource.

Run a search-replace from http://yourdomain.com to https://yourdomain.com across all tables.
Check hardcoded links in theme files, custom HTML widgets and page builder blocks.
Confirm siteurl and home in wp_options both use https.
Open the browser console (F12) on your key templates and look for “Mixed Content” messages.

Add a canonical redirect in .htaccess so HTTP and non-www always land on one version:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Careful: only one canonical redirect chain should exist. If your old host had a redirect rule and your new host adds another, you can create a loop that takes the site down entirely.

Step 8: Set up email before you touch DNS

Create every mailbox on the new server with the same addresses and, ideally, the same passwords.
Migrate the actual messages with an IMAP sync tool (imapsync, or a migration wizard if your host provides one). Do this before the switch so the mailboxes are already populated.
Copy every DNS record related to mail into the new zone: MX, SPF (TXT), DKIM (TXT), DMARC (TXT), plus autodiscover records.
Set up forwarders and aliases.
Warn the team that mail clients may need a settings update (incoming/outgoing server names).

If mail is external, the only thing that matters is that the MX and TXT records exist identically in the new zone before nameservers change. Screenshot the old zone. Then screenshot it again.

Step 9: Make the switch

Put the old site into maintenance mode or at least stop new orders and comments if you cannot tolerate any data loss.
Do a final delta sync: re-export the database and rsync the uploads folder so anything published in the last hours is carried over.
Update the A record (and AAAA if you use IPv6) to the new server IP. With a 300 second TTL, most resolvers pick it up in under five minutes.
Verify propagation with dig example.com from a few locations, or an online propagation checker.
Remove the lines you added to your local hosts file, flush DNS, and browse the live site as a normal visitor.
Leave the old hosting account running for at least 7 days. Visitors on stale DNS still see a working site instead of an error. Keep the old site read-only if you can, to avoid split orders.

Step 10: Post-migration checks

First hour

Homepage and 5 to 10 key pages load over HTTPS with a valid padlock
wp-admin accessible
Send a test email to and from a mailbox at the domain, and to a Gmail address (check the spam folder)
Submit a contact form and confirm receipt
Place a real test order if you run a store
Check the server error log

First 24 hours

Re-crawl the site and compare status codes against your pre-migration export. Any new 404 or 500 is a migration artefact.
Confirm your XML sitemap is generating and accessible
Check robots.txt. A staging environment can leave a Disallow: / behind, which is the single most damaging SEO mistake in this whole process.
Verify Search > Settings > Reading does not have “Discourage search engines from indexing this site” checked
Re-check that WP-Cron or your server cron is firing (scheduled posts, backups, WooCommerce actions)
Confirm caching, CDN and firewall (Cloudflare origin IP) point to the new server
Reconnect any plugin licences bound to a server or IP

First week

Watch Google Search Console for crawl errors and server response spikes
Check Analytics for traffic anomalies (a sudden drop usually means a tracking code or DNS issue, not a ranking issue)
Confirm backups are running on the new host
Retest email deliverability with a tool like mail-tester, since SPF and DKIM often need adjusting
Once stable, raise DNS TTL back to 3600 or 14400 and cancel the old plan

The mistakes that actually cause downtime

Mistake	Symptom	Fix
Cancelling the old host on switch day	Part of your audience sees a dead site for hours	Keep it live 7 to 14 days
Lowering TTL on migration day	Long, unpredictable propagation	Lower it 48 hours ahead
Nameserver change instead of A record change	Email breaks, records lost, 24h+ propagation	Change the A record where possible; otherwise pre-build the full zone
Plain SQL find and replace	Broken widgets, empty page builder layouts	Use WP-CLI search-replace or Better Search Replace
Forgetting .htaccess and hidden files	404 on every page except the homepage	Enable hidden files in FTP; resave permalinks
SSL installed after DNS switch	Full page security warning	Use DNS validation to issue in advance
Staging robots.txt or noindex left in place	Rankings collapse within days	Check robots.txt and Reading settings immediately
MX records not copied	Silent mail loss, bounced enquiries	Export the full zone before touching anything
Upgrading PHP during the migration	Fatal errors you cannot attribute	Match versions first, upgrade a week later
Publishing content during the copy window	Lost posts and orders	Freeze content, run a final delta sync

Does migrating hosts hurt your SEO?

No, provided the URLs stay identical and the site stays reachable. Google does not rank you based on who hosts you. What it does notice is:

Server response codes. Sustained 5xx errors during a crawl will cost you.
Response time. A slower new host degrades crawl budget and Core Web Vitals. Benchmark before and after.
Accidental noindex or robots.txt blocking. The number one self inflicted wound.
Broken internal links and images caused by leftover old-domain URLs.
Redirect chains from duplicated HTTPS and www rules.

You do not need to notify Google of a host change if the domain does not change. If the domain does change, implement 301 redirects for every URL and use the Change of Address tool in Search Console.

Migration checklist you can copy

☐ Site audit documented (PHP, MySQL, size, email, DNS zone export)
☐ Pre-migration crawl exported
☐ New hosting provisioned, PHP/MySQL matched, DB created
☐ DNS TTL lowered to 300 (48h ahead)
☐ Full manual backup stored off-server
☐ Files and database copied to new host
☐ wp-config.php updated
☐ Serialization-safe search-replace done (if domain changed)
☐ Hosts file test passed on all key templates
☐ SSL certificate issued and installed on the new server
☐ Mailboxes created and IMAP sync complete
☐ MX, SPF, DKIM, DMARC recreated
☐ Content frozen and final delta sync run
☐ A record updated
☐ Hosts file entries removed, live site verified
☐ Post-migration crawl compared to baseline
☐ robots.txt and indexing settings checked
☐ Backups and cron confirmed on new host
☐ Old host kept live 7 to 14 days
☐ TTL raised back, old plan cancelled

Let us handle it instead

Every plan at Ameritech Hosting includes a free, engineer-assisted WordPress migration. We take the full backup, replicate your environment, pre-issue the SSL certificate, rebuild your DNS zone with your existing mail records intact, test everything behind a hosts file, and only then flip the switch, usually during your lowest traffic hour. If anything is not right, we roll back. Talk to our migration team and send us your current host details to get a plan within 24 hours.

FAQ

How long does it take to migrate a WordPress site to a new host?

The technical copy takes 30 minutes to 3 hours for a typical site. The full project, including the 48 hour TTL reduction, staging tests and the 7 day overlap with the old host, spans about 10 days. Actual downtime should be zero if you follow the order above.

Will my site go down during the DNS change?

Not if both servers are serving the same site at the same time. During propagation, some visitors reach the old server and some reach the new one. Because both work, nobody sees an error. Downtime only happens when you delete the old site before propagation finishes. wpengine.com walks through the specifics.

Can I migrate WordPress without a plugin?

Yes. Download all files via SFTP, export the database with phpMyAdmin or mysqldump, upload both to the new host, import the database, and update the credentials in wp-config.php. This manual method is more reliable for large sites and gives you full visibility over what moved.

What is the best WordPress migration tool?

There is no single winner. Duplicator and All-in-One WP Migration are best for small to medium sites, Migrate Guru handles multi-gigabyte sites without timing out, and WP-CLI with rsync is the most robust option if you have SSH access on both ends. Many hosts, including us, also run the migration for you at no cost.

Why do my images disappear after the migration?

Usually one of three reasons: the uploads folder did not transfer completely, file permissions or ownership are wrong on the new server, or the database still contains old absolute URLs. Compare the file count in wp-content/uploads on both servers first, then run a search-replace if the paths are stale.

Do I need to reinstall my SSL certificate on the new host?

Yes. Certificates are installed per server, not per domain. A free Let’s Encrypt certificate can be reissued on the new server using DNS validation before you switch, or automatically after the DNS change. A paid certificate needs to be reissued with a new CSR generated on the new server.

Should I change nameservers or just the A record?

Change the A record if you can. It propagates in minutes with a low TTL and it leaves your MX, SPF and verification records untouched. Change nameservers only when you also want the new host to manage DNS, and rebuild the entire zone there beforehand.

What happens to my email when I move hosts?

If your mail is hosted on the web server, you must recreate mailboxes and sync messages via IMAP before the switch, or mail will bounce. If you use Google Workspace or Microsoft 365, just make sure the MX and TXT records are replicated exactly in the new DNS zone before it goes live.