![Migrate WordPress Hosting Checklist: 12 Steps [2026]](/images/blog/migrate-wordpress-hosting-checklist-12-steps-2026.jpg)
Moving a WordPress site between hosts is straightforward when you work through the right steps in order. I've walked dozens of clients through migrations, and the ones that go smoothly all share the same trait: the site owner checked every item on a list before flipping DNS. Miss a step and you get 404s, broken images, or worse—emails disappearing into the void.
Before you touch anything
Document your current setup first. Log into your existing cPanel or hosting panel and note down the PHP version, database name, and any custom php.ini settings. Screenshot your current DNS records—A, CNAME, MX, TXT—everything. You'll need these later. If you're running a mail server on the same domain, write down the MX records and any SPF or DKIM entries.
Check your current site size. Run du -sh public_html via SSH or look at the file manager. Database size matters too; export it once to see how large the SQL dump is. Some migration plugins choke on databases over 1 GB.
Step 1: Choose the right migration method
You have three paths. Manual migration gives you full control: you download files via FTP, export the database from phpMyAdmin, upload everything to the new host, then import and run search-replace on URLs. It's reliable but slow.
Migration plugins like Duplicator or All-in-One WP Migration bundle files and database into a package, then unpack it on the destination. They work well for sites under 512 MB. For larger sites or if you're uncomfortable with manual steps, ask your new host if they offer free migration service—most do, and their techs handle the heavy lifting.
Pick one method and commit. Mixing methods halfway through creates confusion.
Step 2: Back up everything on the old host
Never start a migration without a verified backup. Use your hosting control panel's backup tool to download a full account backup, or run these commands via SSH:
tar -czf ~/backup-$(date +%F).tar.gz public_html
mysqldump -u dbuser -p dbname > ~/backup-$(date +%F).sql
Download both files to your local machine. Extract the tarball and spot-check a few files. Import the SQL dump into a local MySQL instance if you want to be extra safe. I've seen hosts claim backups exist, then produce nothing when disaster strikes.
If you're using a plugin, export a package and download it before you do anything else.
Step 3: Set up hosting and database on the new server
Create a cPanel account or hosting space on your new provider. Provision a MySQL database and user, then note the credentials—database name, username, password, and hostname (usually localhost but not always). Set the database user's permissions to ALL on the new database.
Create an FTP or SFTP account if you're uploading manually. Write down the hostname, port, username, and password. Match the PHP version to what your old host was running, or go one version newer if your theme and plugins support it. Mismatched PHP versions cause white screens.
Step 4: Upload files to the new host
For manual migrations, connect via FTP or SFTP and upload the contents of public_html (or www, or htdocs—whatever your old host called it) into the new host's document root. Upload the wp-content folder first; it's the largest and you'll know right away if your connection is stable.
Skip the package manager cache directories if you're uploading manually; some hosts stuff node_modules or vendor folders in there by accident.
Plugins like Duplicator will generate an installer script. Upload the package file and installer.php to the new document root, then visit https://newhost-temp-url.com/installer.php in your browser. Follow the wizard and point it at your new database credentials.
Step 5: Import and configure the database
If you're migrating manually, log into phpMyAdmin on the new host, select your empty database, and click Import. Choose the SQL dump file and hit Go. For large databases, increase the upload limit in php.ini or split the file using a tool like BigDump.
Once imported, edit wp-config.php in the new document root. Update DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST to match your new database credentials. If you're reusing the same database name and user, double-check the password—it rarely survives the move.
Generate new salts at the WordPress salt generator page and replace the AUTH_KEY, SECURE_AUTH_KEY, and related constants in wp-config.php. Old salts work but new ones force everyone to log in again, which is cleaner.
Step 6: Run search-replace on URLs
WordPress hardcodes your domain in the database. If your old site was https://oldhost.com and the new temp URL is https://newhost.temp.com, every internal link will 404 until you fix it. Install WP-CLI on the new host or use the Better Search Replace plugin.
With WP-CLI:
wp search-replace 'https://oldhost.com' 'https://newhost.temp.com' --all-tables --dry-run
Run it without --dry-run once you confirm the counts look right. If you don't have WP-CLI, the plugin works the same way: search for the old URL, replace with the temp URL, and tick "Run as dry run" first. Check every table.
Don't skip serialized data. WordPress stores widget settings and some theme options in serialized PHP arrays. A naive find-replace will corrupt them; use a tool that understands the format.
Step 7: Test the site on the new host before DNS changes
Visit your new site using the temporary URL your host provided, or edit your local hosts file to point your domain at the new server's IP address. On Linux or macOS:
sudo nano /etc/hosts
Add a line:
203.0.113.50 yourdomain.com www.yourdomain.com
Replace that IP with your new server's IP. Save, flush DNS (sudo dscacheutil -flushcache on macOS), then visit your domain. It'll load from the new server even though DNS hasn't changed globally.
Click through every page. Test forms, logins, image uploads, and any e-commerce checkout flow. Check the browser console for 404s on CSS or JavaScript files. Broken assets mean your search-replace missed a URL, or files didn't upload completely.
Step 8: Install and configure SSL on the new host
If your old site ran on HTTPS, provision a Let's Encrypt certificate on the new host before you switch DNS. Most cPanel installs have AutoSSL enabled; just wait a few minutes after adding the domain and the certificate appears automatically. If your host uses a different panel, look for "SSL/TLS" or "Let's Encrypt" in the menu.
Once installed, verify the certificate covers both yourdomain.com and www.yourdomain.com. Visit https://newhost-temp-url.com (via the hosts file trick) and check that the padlock appears. If it doesn't, you'll get mixed-content warnings after DNS switches.
Update any hardcoded http:// URLs in your database or theme files to https://. The search-replace step in step 6 should have caught them if you included the protocol, but double-check wp-config.php for WP_HOME and WP_SITEURL constants.
Step 9: Reduce DNS TTL before the switch
Log into your domain registrar or DNS provider and lower the TTL (time to live) on your A record to 300 seconds (5 minutes). Most DNS records default to 3600 or higher. A low TTL means changes propagate faster. Make this change at least 24 hours before you plan to switch, so the old TTL expires everywhere.
While you're in the DNS panel, screenshot all existing records again. You'll need to recreate them after you point the A record at the new IP.
Step 10: Point DNS to the new server
Update your domain's A record to the new server's IP address. If you're managing DNS at your registrar, this is usually under "DNS Management" or "Advanced DNS." Change the A record for @ (the root domain) and the A or CNAME record for www to point at the new IP.
If you have subdomains, update those A records too. Leave MX records alone unless you're also migrating email. Leave TXT records (SPF, DKIM, DMARC) untouched unless they reference the old server's hostname.
Save the changes and wait. DNS propagation isn't instant. Run dig yourdomain.com or nslookup yourdomain.com from your terminal every few minutes. When the IP matches your new server, you're live for your local resolver. Others will follow.
Step 11: Verify the live site end-to-end
Once DNS has propagated (you're seeing the new IP in dig results), remove the hosts file entry you added in step 7 and visit your domain normally. You should see the new site. Test everything again: logins, forms, image uploads, checkout flows if you're running WooCommerce, and email contact forms.
Check your email. Send a test message to an address on your domain and confirm it arrives. If mail stops working, you either forgot to migrate MX records or your old host was handling email and you didn't provision it on the new one. Go back to your DNS panel and double-check the MX records match what you documented in the beginning.
Watch your WordPress admin for plugin or theme errors. Sometimes plugins store absolute paths to the old server; they'll log warnings in the debug.log if you have WP_DEBUG turned on.
Step 12: Monitor for 48 hours and keep the old site up
Don't cancel your old hosting account immediately. DNS caching and propagation can take up to 48 hours in rare cases, so some visitors will still hit the old server. If you delete the old site too soon, they'll see a 404 or a parked page.
Monitor your error logs on the new server. In cPanel, check the error_log file in your document root or visit Metrics → Errors. Look for 404s on old URLs, failed database connections, or file permission issues. Fix them as they appear.
After 48 hours of clean logs and stable traffic, you can safely cancel the old hosting. Download one final backup from the old host before you do, just in case.
What about email and DNS records?
If your domain handles email and you're only migrating the website, triple-check your MX records before you switch DNS. Lots of migrations go sideways because the site owner forgets the MX records pointed at the old host's mail server. Copy every MX, SPF, DKIM, and DMARC record from the old DNS zone to the new one before you change the A record.
Some hosts bundle email and web hosting on the same server. If that's your setup, either migrate your mailboxes too (export via IMAP, import on the new server) or point MX records at a third-party mail provider like Google Workspace or Zoho before the move. Email gaps are harder to fix than website downtime.
What if something breaks after DNS switches?
You have two options. Roll back by changing the A record back to the old IP—DNS will revert within minutes if you kept the TTL low. Or, troubleshoot the new server in real time if you're confident you can fix it fast.
Common post-migration issues: mixed content warnings (some assets still loading over http://), broken image paths (wrong URL in the database), permission errors (set directories to 755 and files to 644), and missing .htaccess rules (WordPress regenerates this file, but custom rules need to be copied manually).
How long does a WordPress migration take?
Small sites (under 1 GB) take one to two hours if you're doing it manually. Larger sites or those with complex plugin configurations can take half a day. Migrations using a host's white-glove service are usually done within 24 hours, though you'll still need to verify everything afterward.
Do I need downtime during the migration?
No. The old site stays live until you switch DNS. Visitors keep hitting the old server while you prep the new one. The only gap happens during DNS propagation, and even then most users see either the old or new site—rarely a blank page.
Can I migrate WordPress without a plugin?
Yes. Manual migration is often cleaner for large sites because you control every step. FTP the files, export the database, upload to the new host, import the database, update wp-config.php, and run search-replace. Plugins are convenient for smaller sites but they hide what's happening, which makes troubleshooting harder when something goes wrong.
What if my new host has a different PHP version?
Match the PHP version on the new host to the old one first, then test your site. Once stable, upgrade PHP incrementally—7.4 to 8.0, then 8.0 to 8.1, testing after each jump. Skipping multiple versions at once will break older plugins and themes. Check the plugin compatibility list in your WordPress admin before you upgrade.
Keep the checklist and test every item
Migrations fail when you skip steps, not because the process is hard. Back up before you start, test on the new host before DNS changes, verify SSL is working, and keep the old site online for 48 hours. Every migration I've seen go smoothly followed this sequence. The ones that didn't usually skipped the search-replace step or forgot about email.
Print this checklist or keep it open in a tab. Check off each item as you go. If you hit a snag, roll back and troubleshoot rather than pushing forward with broken pieces. A slow, methodical migration beats a fast, chaotic one every time.