DNS Is Not the Hard Part. Everything Before It Is.
Most site owners treat WordPress migration like moving files from one folder to another. Pull everything over, point the domain, done. That mental model is why migrations fail — and why "five-minute" moves turn into twelve-hour recoveries.
Migration breaks at specific, predictable points. Serialized data in the database. Absolute URLs hardcoded across the wp_options table. Cron jobs referencing the old domain. Object cache serving stale responses against a new configuration. These aren't edge cases — they're standard failure modes that appear in the majority of migrations done without a structured process.
This guide covers how to move a WordPress site correctly: files, database, DNS sequencing, and the post-migration audit that most guides skip entirely.
What Actually Breaks During a WordPress Migration
Before touching a single file, understand the failure surface.
Serialized data corruption is the most common and the most invisible. WordPress stores data in the database using PHP's serialize() function. When you do a naive find-and-replace on the old domain URL inside a MySQL dump, you break the byte-count embedded in those serialized strings. The result: settings silently fail, widget configurations vanish, plugin states reset.
Hardcoded URLs in wp_options are the second landmine. The siteurl and home values are the obvious ones. But dozens of plugins store their own absolute paths — license keys tied to domain, redirect rules, API endpoint references, stylesheet paths in theme options. A string search across your dump will show you how embedded the old URL really is.
PHP version mismatches between old and new hosts cause immediate fatal errors post-migration. If your current host runs PHP 7.4 and your new host defaults to PHP 8.2, plugins that haven't been updated in 18 months will throw compatibility errors on activation. Check your plugin compatibility matrix before the migration, not after.
Active cron jobs don't automatically re-register on a new environment. WordPress cron (wp-cron) runs on page load by default, but if you've moved to a system cron via WP-CLI — which you should have — that configuration doesn't travel with the files. It lives on the server.
SSL misconfigurations post-migration are so common they deserve a separate bullet. Mixed content errors, forced HTTP rewrites in .htaccess pointing to the old host's certificate, HSTS headers cached in browsers — all of this surfaces the moment DNS propagates and real users hit the new server.
The Migration Process, Done Correctly
Step 1: Full Backup Before Anything Else
Non-negotiable. Run a complete backup on the origin server — files and database — before touching a single setting. This is your restore point if everything goes sideways.
Use WP-CLI on the source server:
wp db export backup-pre-migration.sql --add-drop-table
Pair that with an rsync or SFTP pull of the entire WordPress root directory, including wp-content/uploads, wp-content/themes, and wp-content/plugins. Do not rely on your host's backup system alone — you need a copy you control, off-server.
Step 2: Set Up the New Environment First
Provision the new host completely before moving any files. This includes:
- Installing the target PHP version and confirming it matches your plugin compatibility matrix
- Setting up the database (new database name, user, password, host)
- Configuring the server's document root
- Installing SSL on the new host before DNS moves
This matters because you want a fully operational environment ready to receive the migration, not a half-configured server you're racing to set up while DNS propagates.
Step 3: Transfer Files
Use rsync over SSH for efficiency and reliability:
rsync -avz --progress /var/www/html/ user@newhost:/var/www/html/
If SSH access isn't available, use SFTP with a client that supports resume-on-disconnect. Do not use cPanel's File Manager for large sites — it's slow, it times out, and it won't preserve file permissions correctly.
Step 4: Export, Modify, and Import the Database
Export from the old host:
wp db export old-site.sql --add-drop-table
Before importing, run a search-replace using WP-CLI's built-in serialization-safe method — not a text editor, not a generic find-replace in phpMyAdmin:
wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise --report-changed-only
The --precise flag forces WP-CLI to handle serialized data correctly, unpacking and repacking PHP-serialized strings rather than doing a raw string replacement. This single flag is what separates a clean migration from a corrupted options table.
Import the modified database into the new host:
wp db import old-site.sql
Then verify critical values:
wp option get siteurl
wp option get home
Both should return the new domain.
Step 5: Update wp-config.php
The new wp-config.php needs updated database credentials matching the new host environment. If you copied the file from the old server (which you should, to preserve keys and salts), update only the DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST constants.
Do not regenerate salts unless you need to invalidate all existing sessions. Regenerating them logs out every active user — which matters on membership sites or WooCommerce stores with active carts.
Step 6: Pre-DNS Testing via Hosts File
Before flipping DNS, verify the new site is fully operational using a local hosts file override:
- On Mac/Linux: Edit
/etc/hosts - On Windows: Edit
C:\Windows\System32\drivers\etc\hosts
Add:
[new_server_IP] newdomain.com
This forces your local machine to resolve the domain to the new server without affecting live traffic. Browse the entire site — frontend, admin, checkout flow, media library. Check that images load, forms submit, and admin redirects work.
This step catches 80% of post-migration issues before they affect a single real user.
Step 7: Lower TTL Before DNS Migration
At least 24 hours before you move DNS, lower your TTL to 300 seconds (5 minutes). This dramatically reduces propagation lag when you make the switch. If your TTL is still at 86400 when you point DNS, you're committing to up to 24 hours of split traffic between old and new servers.
Once DNS is live on the new server, monitor propagation using a tool like DNS Checker. Don't assume propagation is complete because it works on your machine — it may still be resolving to the old host for users on different ISPs or geographic locations.
Step 8: Post-Migration Audit
This is the section most migration guides skip, and it's where recoverable problems become permanent ones.
Object cache invalidation: If you're running a persistent object cache (Redis, Memcached), flush it immediately after migration. A stale cache serving old domain URLs or old database values will cause unexplainable behavior that's difficult to trace.
wp cache flush
Transient cleanup: Transients stored in wp_options may contain serialized data referencing old paths or URLs. Flush them:
wp transient delete --all
Cron job verification: Run wp cron event list on the new server to confirm all scheduled events carried over. If you use a real system cron rather than wp-cron, re-register it on the new server using the appropriate crontab entry. Missing cron jobs means missed emails, failed scheduled posts, and broken WooCommerce order processing.
Search index regeneration: If you run a search plugin (SearchWP, Relevanssi, Elasticsearch-based), your search index needs to be rebuilt from scratch on the new environment. The old index is environment-specific.
Query Monitor diagnostics: Install and run Query Monitor after migration to surface slow queries, broken hooks, and PHP notices that indicate compatibility issues. New server infrastructure often exposes problems the old server's configuration was silently suppressing.
404 audit: Crawl the new site with Screaming Frog or a similar tool. Missing redirects, broken internal links, and orphaned media URLs show up immediately in a crawl. Fix them before they affect SEO.
Domain Migration Is a Different Problem
Moving a site to a new domain — not just a new host — carries additional complexity that file-and-database migrations don't.
Canonical tags and sitemap URLs need updating across the theme and in your SEO plugin settings. If you use Yoast or Rank Math, update the site URL in plugin settings, regenerate the sitemap, and submit the new sitemap to Google Search Console.
301 redirect architecture must be in place before you decommission the old domain. Every indexed URL on the old domain needs a 301 pointing to the equivalent URL on the new domain. A blanket redirect from the old domain root to the new domain root is not sufficient — Google treats root-to-root redirects as a single signal, but individual URL-to-URL 301s pass link equity at the page level.
Google Search Console requires a domain change notification (Change of Address tool) if you're migrating domains. This is separate from just submitting a new sitemap. Miss this step and you're leaving Google to figure it out on its own — which takes significantly longer.
Email deliverability breaks immediately if MX records aren't transferred correctly. This is technically outside WordPress, but domain migrations commonly break email because DNS changes often overwrite existing MX records. Before pointing nameservers to a new host, document every DNS record on the old configuration.
Where DIY Migration Goes Wrong
The process above works — when executed precisely and in order. The problem isn't the steps. It's execution under pressure.
Most DIY migrations fail not because of ignorance but because of environment — unfamiliar server configurations, hosting panels with limited SSH access, time pressure from an expiring hosting contract, or a plugin causing a conflict that requires diagnosis mid-migration.
The real cost of a failed migration isn't just downtime. It's data loss. A botched database import with a corrupted search-replace means reconstructing content manually. A missed 301 redirect on a high-authority URL means a measurable SEO regression. A missed cron job means a WooCommerce store processing orders without sending confirmations — often undetected for days.
For a WooCommerce store generating $5,000/day, a 6-hour outage during a botched migration represents roughly $1,250 in lost revenue — before accounting for customer trust erosion and abandoned cart recovery costs.
The math on professional migration is straightforward. See our WordPress migration and maintenance services — the cost of a managed migration is a fraction of what a failed one costs in recovery time and revenue.
What Vimsy's Migration Process Covers
Our Migration Magic service handles the full migration stack: file transfer, database migration with serialization-safe search-replace, wp-config.php configuration, DNS transition coordination, pre- and post-migration testing, and a 48-hour monitoring window post-launch.
We run the hosts-file verification step on every migration before touching DNS. We confirm cron jobs, flush transients, validate object cache configuration, and audit for PHP version compatibility before the site goes live on the new server.
You can see the full scope of what we cover in our pricing — there's no hidden complexity surcharge for WooCommerce or membership sites. We document it upfront.
If your migration is more urgent — a failing host, an expiring contract, an active security incident — we offer emergency WordPress support with fast response times.
The Checklist You Should Run on Every Migration
For reference — not as a substitute for expertise, but as a quality gate:
- [ ] Pre-migration backup: files + database, off-server copy
- [ ] New host PHP version matched to plugin compatibility
- [ ] Database export using WP-CLI with
--add-drop-table - [ ] Search-replace using
wp search-replacewith--preciseflag - [ ] wp-config.php updated with new DB credentials
- [ ] Hosts file pre-flight test before DNS change
- [ ] TTL lowered 24 hours before DNS switch
- [ ] Object cache flushed post-migration
- [ ] Transients deleted post-migration
- [ ] Cron jobs verified with
wp cron event list - [ ] SSL confirmed on new host before DNS move
- [ ] 301 redirects in place (for domain migrations)
- [ ] Search Console updated (for domain migrations)
- [ ] Query Monitor run to surface PHP/hook issues
- [ ] Site crawl for 404s and broken media
You can also review our WordPress maintenance checklist for what to monitor ongoing after the migration is complete.
Migration Is a Systems Problem, Not a Technical Skill Problem
The steps above aren't secret knowledge. They're available in WordPress documentation, hosting guides, and a hundred blog posts. The gap isn't information — it's systems execution under real conditions.
A missed flag in a database search-replace, a forgotten DNS record, a PHP version that doesn't match — any one of these turns a clean migration into an emergency recovery. And emergency recoveries, by definition, happen at the worst possible time.
Look — I'm writing this because this is a problem I see constantly, and it's also exactly what we built Vimsy to solve. If you want professionals handling this instead of hoping nothing breaks, book a free call.
Your new host isn't going to audit your cron jobs. Your old host isn't going to care about your serialized data. That's the gap this work fills — and filling it properly the first time is always cheaper than fixing it afterward.
