Migrating a WordPress site sounds simple until the final switch. That is where things usually go wrong. Broken forms, missing images, login issues, and DNS delays can turn a routine move into a headache.
A structured approach removes most of that risk. This guide walks through a clean, low-downtime migration process that actually holds up in production.
1. Back Up Everything First
Before making any changes, take a full backup of your current site.
This should include:
- All WordPress files
- The database
- Any custom configurations such as
.htaccessorwp-config.php
You can do this using hosting backups, plugins like UpdraftPlus or All-in-One WP Migration, or manually via mysqldump and file transfer.
Having a complete backup means you can roll back instantly if anything breaks.
2. Prepare the New Hosting Environment
Set up the new server properly before moving any data.
Make sure:
- PHP version matches or exceeds your current setup
- Required PHP extensions are installed
- MySQL or MariaDB is ready
- SSL can be configured using Let’s Encrypt or equivalent
- Nginx or Apache is configured correctly
Create a new empty database and note the credentials.
3. Migrate Files and Database
Transfer your site to the new host.
Upload all WordPress files via SFTP or rsync if dealing with large sites.
Export the database from the old host using:
mysqldump -u USER -p DATABASE > backup.sql
Import it on the new host using:
mysql -u USER -p DATABASE < backup.sql
Update wp-config.php with the new database details.
4. Fix URLs and Paths
If anything changes during migration such as domain, paths, or protocol, update URLs in the database.
Using WP-CLI:
wp search-replace ‘oldsite.com’ ‘newsite.com’
Alternatively, use a plugin if WP-CLI is not available.
5. Test the Site Before DNS Changes
Do not switch DNS yet.
Preview the site using your hosts file or a temporary domain provided by your host.
Check:
- Pages and posts
- Images and media
- Contact forms
- Login and admin area
- Plugins and themes
- eCommerce or membership systems
Fix any issues now, not after launch.
6. Reduce DNS TTL in Advance
Lower the TTL on your DNS records 24 to 48 hours before migration.
For example, reduce from 86400 seconds to 300 seconds.
This helps speed up propagation when switching IPs, although some resolvers ignore TTL settings.
7. Final Sync Before Cutover
Right before switching DNS:
- Optionally enable maintenance mode on the old site
- Take a fresh database export
- Sync any new uploads or changes
This prevents data loss during the transition.
8. Update DNS Records
Point your domain to the new server by updating A records or nameservers.
Propagation can take anywhere from a few minutes to several hours, occasionally up to 24 hours.
9. Monitor and Verify
After the switch, check everything works properly.
Verify:
- Site loads correctly
- SSL is active
- Forms send emails
- Admin login works
- Scheduled tasks and cron jobs run
- Caching and CDN are functioning
Keep the old hosting active for at least 48 hours in case traffic is still reaching it.
10. Clean Up
Once everything is stable:
- Disable maintenance mode
- Re-enable caching and performance tools
- Cancel the old hosting when safe
- Take a fresh backup of the new environment
Final Thoughts
A smooth WordPress migration comes down to preparation rather than guesswork.
Back up properly, test thoroughly, sync data carefully, and plan DNS changes in advance. Do that, and you can migrate with little to no visible downtime.
Recommended Hosting
Choosing the right host is just as important as the migration itself. A poor platform will undo all the effort you have put into a clean move.
TekLan Hosting is a strong choice for WordPress hosting, particularly if you want consistent performance and proper support when things matter. Their use of NVMe storage helps with faster load times, and having UK-based support means issues get handled quickly rather than sitting in a queue.
For anyone migrating a live site, that reliability makes a difference. If something needs adjusting during or after the move, you want a host that actually responds.
Moving hosts should be something you do once properly, not something you repeat because of avoidable problems.