Knowing how to migrate WordPress site to new host without downtime comes down to a fixed order: exporting the database, transferring files via SFTP, updating configuration constants, and lowering DNS TTLs before flipping traffic. This process protects your content while moving server infrastructure. You will handle serialized data carefully so your layouts stay intact throughout the move.
#ad – we may earn a commission from the links in this post. How this works
We have moved some client websites between providers. The difference between a clean migration and a week-long support ticket usually comes down to pre-flight checks, handling serialized data correctly, and managing DNS propagation windows.
This is the workflow we use when sites need to move without breaking layouts or losing content. You will follow each step in order so the new environment matches your old one exactly. The how to migrate WordPress site to new host process feels technical until you separate file transfer from database import and DNS updates into distinct phases.
How to migrate a WordPress site to a new host: pick a method
There are three ways to move a WordPress site, and the one you pick decides how much of this runbook you actually need.
| Factor | Host-Assisted Migration | Migration Plugin (e.g., Duplicator) | Manual SSH/rsync |
|---|---|---|---|
| Best for | Sites under 2GB with low technical comfort | Sites up to 10GB where you need a staging copy first | Large sites, multisite, or complex .htaccess chains |
| Data safety | Provider handles backup; limited client control | You control local backups and package integrity | Full control; you own the backup chain |
| Speed | Dependent on host internal network; often slow for large DBs | Limited by PHP max_execution_time and upload caps | Fastest for file transfer; requires manual DB export/import |
| Troubleshooting | You wait on support tickets if they stall | You debug import timeouts yourself | You fix errors directly via terminal or error logs |
Choose a plugin if:
* Your site is under 5GB and you need to verify the move on a staging URL before going live
* You want to package everything into one downloadable archive for safekeeping
* You are comfortable running wp search-replace locally after unpacking
Because large packages require upload time, you should test your bandwidth first.
Go manual if:
* You have a site over 10GB or complex custom server configurations
* Your host’s migration assistant fails on serialized data or PHP limits
* You need to preserve exact file permissions and .htaccess rewrite rules
Since you manage every transfer step, you will catch permission errors before they break the front end.
Back up your WordPress site before you migrate to the new host
Before anything moves, you need a backup you can restore and a record of what the current site runs. The diagram below shows where those two steps sit in the sequence.
What to back up before you touch anything
- Run a full site export to local storage using Duplicator before touching the live server.
- Verify database integrity with a dry-run search/replace on a staging clone.
- Reduce DNS TTL to 300 seconds at least 24 hours before the planned cutover.
- Snapshot the current
php.inivalues from your existing host for reference.
Where host-assisted backups fall short
- Host-assisted backups often fail on large sites exceeding PHP memory limits.
- Skipping local verification risks corrupted exports that you cannot fix later.
- High TTLs left in place can force propagation delays of hours or days.
Since you already know how to migrate WordPress site to new host files, you will notice the backup step dictates every downstream decision.
Moving files and database to the new server
This is where most migrations go wrong. The database moves first, then the files, and then you edit the constants shown below so WordPress can find its new database.
Why SFTP and the mysql client
- SFTP preserves file permissions better than cPanel File Manager.
mysqldumpwith compression reduces transfer time for large databases.- Manual config updates let you tweak constants like
WP_HOMEwithout plugin interference.
Who should take the manual route
- Practitioners comfortable with terminal commands and server configuration files.
- Sites with custom caching layers that need manual replication on the target server.
When manual is the only option
- Migrating a multisite network where subfolder vs. subdomain routing must be preserved exactly.
- Moving between providers that use different control panels but identical PHP stacks.
What breaks during a manual import
- Manual database imports can timeout if
max_execution_timeis not raised on the target server before you start. - A single typo in
wp-config.phplocks you out of the admin dashboard immediately. - You are responsible for regenerating CSS and JS bundles for page builders after the move.
Once you establish the connection, you will run the database import first so the file upload can proceed simultaneously.
When a search and replace leaves serialized data broken, work through this checklist before you reach for the backup:
After you migrate: DNS cutover and WordPress site checks on the new host
Once you migrate, the WordPress site sits on the new host, but nobody is seeing it yet. These are the checks worth running before and immediately after you flip DNS.
Checks to run the moment DNS flips
- Purge all cache layers (Redis/Memcached) and page builder caches immediately after import.
- Verify SSL certificates are installed and redirecting HTTP to HTTPS correctly on the new host.
- Test admin login and front-end assets before flipping production traffic.
Caches that keep serving the old site
- Elementor‘s
elementor/cssdirectory often serves stale layouts until purged or recreated. - Leaving old DNS records active too long can cause intermittent access failures during propagation.
- Skipping post-migration cache clearing forces you to troubleshoot layout drift with no data saved.
Object caching and wp-config changes
- Sites using aggressive object caching that need
wp-config.phpto disable caching for the initial login verification. - Domains moving from HTTP to HTTPS where mixed-content warnings block scripts after the move.
Since you already understand how to migrate WordPress site to new host infrastructure, you will notice this phase depends entirely on cache layer management.
Which host is right for you?
When you plan how to migrate WordPress site to new host, where you are moving to changes how much of the work above you have to do yourself.
Matching the new environment to the old
- Matching PHP versions and extensions prevents fatal errors after you update your config.
- Selecting a host with appropriate RAM per process matters more than CPU cores for WordPress imports.
- Managed hosts handle cache layer tuning; bare-metal requires manual PHP-FPM pool configuration.
Where entry-level plans struggle
- Entry-level shared plans often throttle I/O during large file transfers, stalling migration scripts.
- Moving from managed to unmanaged hosting shifts the burden of server security patches and updates to you.
- Some hosts disable required PHP functions like
exec()orshell_execneeded by backup tools.
Choose SiteGround if:
* You need managed WordPress support and can pay above entry-level shared pricing
* Your site relies on specific cache optimizations they provide out of the box
* You want a migration assistant that handles standard themes without custom server tweaks
Because you will avoid manual PHP tuning, your migration time shrinks significantly.
Choose NameHero if:
* You want faster hardware than budget shared plans without paying for full management
* Your project requires specific PHP extensions or higher process limits
* You are comfortable configuring your own cron jobs and server-side security rules
If you prefer raw performance over hand-holding, this path gives you more control.
For readers on a tight budget starting their first site, Bluehost remains a viable entry point where cheap shared hosting is genuinely the right answer. However, you will manage server configurations yourself instead of relying on platform tools.
Conclusion
Learning how to migrate WordPress site to new host safely is mostly about sequence. Think of a migration as moving a library while the doors are still open. The books (your content) don’t change, but if you pack them in boxes without labeling them correctly, nobody can find anything when you arrive. Our runbook keeps the labels intact by backing up first, verifying on a staging shelf, and swapping the sign outside the building only after we’ve confirmed every page is readable on the new street. You will save hours of debugging by following this sequence instead of guessing file paths or DNS timing.
Related guides
- UpdraftPlus setup for scheduled backups before risky changes: teamupdraft.com
- DNS propagation calculator: zerotowp.com
- Elementor cache clearing techniques: wppioneer.com
FAQs
1. Can I migrate my site without downtime?
You can minimize downtime by reducing your DNS TTL to 300 seconds 24 hours before moving, uploading the site to a staging URL on the new host, and flipping the A record during low-traffic hours. Propagation usually clears within minutes at this setting, so visitors see the new server almost immediately.
2. What happens to my Elementor layouts after migration?
Elementor stores cached CSS in the elementor/css directory, which can serve stale layouts until purged. We always clear this cache and regenerate bundles on the new host before turning traffic back on. If layouts look broken, it is usually due to a server-side caching layer that has not been flushed.
3. Do I need to install WordPress again on the new host?
You do not reinstall WordPress if you use a migration plugin or manual file transfer; you upload your existing wp-admin and wp-content folders and import your database. The core files are included in your package, and only wp-config.php needs updates for the new connection details.
4. How do I fix serialized data errors after import?
Serialized data corruption usually occurs if a raw SQL replace breaks string lengths. We run wp search-replace with the --precise flag to keep serialization intact. If you already have broken arrays, export the corrupted wp_options rows, decode them manually, correct the values, and re-upload the fixed records.
5. Should I keep my old host active after migration?
Yes, keep your old hosting account open for at least seven days while you monitor error logs and verify all functionality. This gives you a rollback option if DNS propagation leaves some users on an incomplete site or if you miss a custom configuration detail during the move.
→ Manual migration workflow checklist: duplicator.com
→ Zero-downtime cutover sequence details: wppioneer.com
→ Pre-migration best practices for backups and verification: wpremote.com
Handy to have: If rankings are the worry, a solid SEO book explains the why behind steps like these.
As an Amazon Associate, Gila Bytes earns from qualifying purchases.
If this sounds like more than you want to take on yourself, this is exactly the kind of work we do for clients at Gila Bytes. Get in touch and we’ll handle it.
#ad – This post has affiliate links; we may earn a commission at no extra cost to you. Draft was created with assistance of AI, reviewed and edited by people at Gila Bytes. How we handle affiliate links
We sell managed hosting and maintenance ourselves, so read this as a comparison from someone with skin in the game – our interest, in full.
