Migrating WordPress shouldn’t feel like defusing a bomb. With the right plan, you can move to a new host smoothly, avoid downtime, and protect your SEO. This step-by-step guide gives you the complete checklist, so you can safely migrate a WordPress site to a new host without surprises. You’ll back up everything, test on staging, handle DNS cutover cleanly, and tie up post-migration loose ends the way pros do.
[7NiU5-F5IdQK494cbiWtU] Pre-Migration Checklist and Planning
Audit, Access, and Compatibility
Start by auditing what you’re moving. Note your WordPress version, PHP version, active theme, and plugins (including versions and license keys). Flag anything outdated or abandoned, those are common breakpoints when switching environments.
Collect access you’ll need: current host control panel, SFTP/SSH, database (phpMyAdmin or MySQL credentials), WordPress admin, DNS registrar, and new host logins. Confirm you can enable/disable maintenance mode and run WP-CLI.
Check compatibility on the new host. Confirm supported PHP versions (8.1/8.2), MySQL/MariaDB versions, and required PHP extensions (curl, mbstring, intl, imagick, gd). If you rely on Redis or Object Cache Pro, verify availability. For eCommerce or membership sites, confirm persistent object caching and proper session handling.
If your site handles payments or personal data, review compliance needs (PCI, HIPAA-like constraints, data residency). Know where your backups will live and who can access them.
Choose Your Migration Method and Timeline
Pick your approach:
- Manual: SFTP + database export/import + WP-CLI search-replace. Most control and transparency.
- Plugin-assisted: Tools like Duplicator, All-in-One WP Migration, or Migrate Guru can simplify packaging. Useful for non-technical moves, but watch size limits and server timeouts.
- Host-assisted: Many premium hosts offer free concierge migrations, take it if downtime risk is high.
Set a timeline. Lower your DNS TTL to 300 seconds at least 24 hours before cutover to speed propagation. Schedule the final switch during a trough in traffic (check analytics). Define a rollback plan and who approves a go/no-go. For high-traffic or transactional sites, freeze content (disable publishing and orders) during the final sync window or plan a delta sync.
[Xs9vdMWFDF1wYj7uqLkVA] Back Up and Verify Your Site
Full File and Database Backups
Create two independent backups: one via your current host’s snapshot or backup tool, and one you control.
Files: Download the entire WordPress directory (wp-content, wp-includes, wp-admin, and root files like wp-config.php and .htaccess). Don’t skip hidden files.
Database: Export a full SQL dump. With WP-CLI: wp db export site-backup.sql. With phpMyAdmin, choose “Quick” or “Custom” and include all tables, routines, and triggers.
Store backups offsite (cloud storage or a separate region). Encrypt if they contain sensitive data.
Verify Integrity and Recovery Points
Test the backups. Open the archive and spot-check file sizes and key directories. Validate the SQL isn’t truncated and includes CREATE TABLE statements. If possible, restore to a local or temporary database to ensure the dump imports cleanly.
Define recovery points. Keep at least one pre-migration backup and one right before DNS cutover. If something goes sideways, you’ll thank yourself.
[wUsqu8duIeiqlGEEe76sP] Prepare the New Host and Staging
Environment Setup: PHP, Database, and Resources
On the new host, create the site container or account. Set PHP to your target version (match production first: you can upgrade after). Create a new database, user, and a strong password. Note the host, DB name, user, and port.
Adjust PHP settings to match workload: memory_limit (256M+ for heavy sites), max_execution_time (120–300), upload_max_filesize/post_max_size (bigger than your largest media file). Enable OPcache, and configure Redis if you’ll use object caching.
Spin up a staging domain or subdomain (e.g., staging.yourdomain.com) or plan a hosts-file preview to avoid indexing staging in search.
SSL, Domain Mapping, and Hosts File Preview
If your host supports automatic SSL (Let’s Encrypt), prepare it for the live domain, but don’t force HTTPS redirects until you can resolve the domain locally. For staging, use a temporary domain with its own SSL cert, or rely on a hosts-file preview.
For a hosts-file preview: map your domain to the new server’s IP in your local hosts file so only you see the new instance at the real URL. This lets you test real paths and cookies without exposing the new site publicly. Remember to remove the entry after cutover.
[zogysGdggoky-Bqukcx5Z] Migrate Files and Database
Export/Import the Database and Update wp-config.php
Import your SQL dump into the new database. With WP-CLI on the new host: wp db import site-backup.sql. If the database already has tables, drop them first or use a fresh database.
Open wp-config.php and update DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST to your new values. Keep your AUTH_KEY/SALT values: don’t regenerate them unless you want to force logouts for all users.
If table prefixes differ (e.g., wp_ vs. custom_), ensure you imported to the correct schema and that wp-config.php uses the same $table_prefix.
Transfer wp-content and Run URL Search-Replace Safely
Upload your files over SFTP or rsync. Prioritize wp-content (themes, plugins, uploads) and any custom directories. Keep file permissions sane: files 644, directories 755. Preserve .htaccess or nginx rules.
Update hard-coded URLs in the database to match the new domain if it’s changing or to normalize protocol (http to https). Use a serialized-safe tool:
- WP-CLI: wp search-replace ‘http://oldsite.com’ ‘https://newsite.com’ –skip-columns=guid
- Interconnect/it’s Search Replace DB script, or a trusted migration plugin
Skip the guid column to avoid RSS breakage, and test on staging first. If you’re keeping the same domain, you may only need to normalize http→https and fix absolute paths from old environments.
[a6KspV-i3G_zOlFY2qZGm] Test Before DNS Cutover
Functional QA, Performance, and Caching
Browse the site via the staging URL or hosts-file preview. Log into wp-admin and the front end. Check critical flows: contact forms, checkout, search, logins, and membership gates. Test media playback, downloads, and any third-party embeds.
Regenerate permalinks by visiting Settings > Permalinks and saving once. Clear all caches: page cache, object cache, CDN (if connected), and browser cache. If your theme or a plugin has its own cache, purge it too.
Run a quick performance check. Measure TTFB and Core Web Vitals with tools like WebPageTest or PageSpeed Insights (on a staging URL, you’ll get approximate signals). If caching or compression was better tuned on your old host, replicate those settings now.
Security, SSL, and Email Deliverability
Confirm SSL works on staging or via your hosts-file preview. Force HTTPS with a 301 redirect only after you confirm no mixed-content issues. Update WordPress and Site Address URLs to https in Settings > General if applicable.
Verify security plugins and WAF rules still apply. Check file permissions, disable directory indexing, and ensure disallowed file types aren’t publicly accessible. Confirm cron is running (WP-Cron or system cron) for scheduled tasks.
If your site sends email (orders, notifications), test with a transactional service (SMTP, SendGrid, SES). Validate SPF, DKIM, and DMARC records match your sending domain so deliverability doesn’t tank after migration.
SEO Checks: Permalinks, robots.txt, and Sitemaps
Make sure permalinks are identical to the old site. Confirm robots.txt isn’t blocking the site on the new host. In Settings > Reading, ensure “Discourage search engines from indexing this site” is unchecked for production.
Check your sitemap index (from SEO plugins like Yoast or Rank Math) and fetch it in your browser. Update any hard-coded canonical tags or OG tags if domains changed. Prepare to resubmit sitemaps in Google Search Console after cutover.
[Ex1W5ZYX4FJEiUkUBDdbg] Cutover, Monitoring, and Cleanup
Update DNS Records, Propagation, and Downtime Mitigation
When you’re satisfied with staging, it’s time to switch. Update the A record (and AAAA for IPv6) of your root domain and the CNAME for www to point to the new host. Keep the lowered TTL (300 seconds) for faster propagation. If you changed nameservers, expect a longer global update window.
To reduce downtime, enable maintenance mode briefly during final sync, then disable once the new site is live. For dynamic sites, freeze content during the cutover window to prevent data divergence (orders, comments). If you rely on a CDN, update its origin to the new server and pre-warm the cache.
Monitor Logs, Fix Issues, and Roll Back if Needed
After updating DNS, monitor in real time. Watch access logs, error logs, PHP-FPM logs, and your application error monitor. Check key pages, transactions, and the homepage from multiple locations. Expect some users to hit old and new servers until caches expire.
If a critical issue appears, you have options: fix in place, temporarily route traffic back by restoring the old A record, or roll back using your last known-good backups. Because you lowered TTL earlier, failback is faster.
Post-Migration Tasks: Redirects, CDN, and Decommissioning
If the domain changed or URL structure shifted, carry out 301 redirects at the server level to preserve SEO equity. Verify they’re one-hop (no chains) and that canonical tags reflect the new URLs.
Reconnect your CDN and image optimization services. Purge caches and confirm compression, HTTP/2 or HTTP/3, and brotli/gzip are active. Re-enable any performance plugins you paused and re-check Core Web Vitals.
In Google Search Console and Bing Webmaster Tools, submit the new sitemaps, set preferred domain, and verify HTTPS. Watch for crawl errors, soft 404s, and spikes in 5xx.
Once traffic is fully on the new host and stable, remove your local hosts-file override. Decommission the old environment only after a quiet period (often 7–14 days) and a final backup. Cancel old cron jobs and third-party webhooks that targeted the old server.
[7qTAL3mv8POl-fSnMNcEM] Conclusion
You don’t need heroics to move WordPress, just a deliberate plan. Back up twice, verify you can restore, mirror the environment on a staging setup, test ruthlessly, then handle DNS with a short TTL and watch logs like a hawk. This step-by-step guide is your complete checklist to safely migrate a WordPress site to a new host without losing data, traffic, or sleep. Stick to the sequence, keep a rollback handy, and you’ll land on the new host cleanly and confidently.
No responses yet