Migrate a WordPress Site to a New Host or Domain Without Search-and-Replace Drama

Moving hosts should be boring. Changing domains should be boring. In practice it is the weekend you break serialized widgets, leave oldsite.com baked into half the options table, and discover the homepage still loads assets from the dying server.

Plenty of backup plugins can export a ZIP. Fewer restore that ZIP onto a new domain and rewrite URLs (including serialized data) without asking you to run a separate search-and-replace script. Snapshotify is built for that path: full-site snapshot, one-click style restore, migration-aware URL rewrite, batched so shared hosts with tight timeouts still finish.

This is not the “database-only snapshot before a plugin update” play (useful, already covered). It is not the sermon about keeping copies off the same box (also true; see same-server is not a backup). This is the move day runbook.

What “migration” has to get right

A WordPress site is not only files.

• Files: WordPress core (sometimes), wp-content (themes, plugins, uploads), config you may rebuild
• Database: posts, options, Elementor/page-builder blobs, WooCommerce tables, widget and theme mods packed in serialized PHP strings

Change the domain and every absolute URL stored in that database must follow. Naive find-and-replace breaks serialization length counts. Then the Customizer goes blank, menus vanish, and page builders show empty canvases.

Snapshotify’s product promise on migration: restore onto any domain and the URLs follow; serialized data rewritten without corrupting it; no wp-config spelunking and no separate search-and-replace ritual.

Before you touch DNS

1. Take a fresh full snapshot on the old site

In Snapshotify, run a full snapshot (database + files). Wait until it finishes. Download a copy to your laptop. If you are on Pro with cloud destinations, confirm the archive also landed in Google Drive, Dropbox, or OneDrive. Move day is a bad time to learn the only copy lived on the server you are about to cancel.

Free Snapshotify covers manual backup, upload, restore, and migration. Pro adds scheduling and cloud storage. Either way, migration day wants a verified archive in your hands.

2. Note versions and special cases

Write down PHP version, WordPress version, and whether you use object cache, Redis, or host-specific must-use plugins. Multisite, unusual table prefixes, and very large uploads directories deserve extra time (Snapshotify batches large work, but wall-clock time is still real).

3. Provision the new host cleanly

Empty WordPress on the destination (or the host’s empty docroot ready for restore). Matching PHP major version reduces plugin surprises. Create the new database and note credentials. You will point the restored site at them as part of the destination setup your host documents.

4. Keep the old site live until cutover

Do not cancel the old host in the same hour you start copying. Parallel running is how you still have a fallback when step seven goes weird.

Restore onto the new host or domain

Exact UI labels live under Snapshotify’s restore and migrating guides in the docs. The shape of the work:

1. Install Snapshotify on the destination (or restore workflow the plugin documents for import).
2. Upload the archive if it is not already visible (chunked upload exists so host limits stop mattering on multi-GB sites).
3. Run restore. Extraction, database import, and URL rewrite are handled for you.
4. Let batched SQL import finish even if the panel takes a while. Shared hosts with 30-second PHP timeouts are why batching exists. Do not spam-click restart.
5. Log into wp-admin on the new URL. Visit permalinks settings and save once (classic flush). Spot-check homepage, a post with images, checkout if you sell, and a form.

Serialized-safe rewrite should leave builders and widgets intact. If something still points at the old domain, note the exact string and check whether it lives in a cache layer, a CDN config, or a hardcoded theme file outside the database.

DNS and HTTPS cutover

Only after the destination looks right:

1. Lower TTL ahead of time if you can.
2. Point DNS to the new host.
3. Issue TLS on the new host (Let’s Encrypt or host panel). HTTPS mistakes break admin cookies and mixed content.
4. Re-test the same money paths on a phone network, not only office Wi-Fi.

If you also changed domains (not only hosts), plan Search Console property adds, sitemap resubmission, and Rankify (or your SEO plugin) redirects from old URLs to new. Snapshotify rewrites the site’s self-references; it does not replace a redirect strategy for the old hostname at the edge.

Pitfalls that turn migrations into war stories

Restoring from a stale snapshot. Content published after the archive will not be there. Take the final snapshot immediately before cutover, during a short content freeze if the site is busy.

Only copying wp-content by FTP. You skip the database story that actually defines the site. Use a real snapshot.

Running two conflicting backup plugins’ restorers. Pick Snapshotify for this move. Disable the other restorer so cron and copy jobs do not interleave.

Forgetting cron and email. New hosts need working loopback or real cron, and transactional email often breaks until SMTP is reconfigured.

Assuming cloud upload succeeded because the local row exists. Snapshotify can complete a local archive even when a cloud upload fails, then surface the failure in the activity log. Read the location column. Details are in the cloud storage docs; the same honesty matters when your migration copy is supposed to be offsite.

Skipping a post-migrate backup on the new host. Once DNS is live, take a new Snapshotify full snapshot on the destination as your known-good rollback for this environment. Schedule Pro backups afterward.

Huge media libraries on tiny PHP limits. Let batching work. For extreme sizes, run during low traffic and keep the laptop awake on the admin session if your host requires it.

Aftercare checklist (24 hours)

• Place a test order or submit a test form
• Confirm user logins and membership entitlements
• Watch error logs for missing paths
• Purge CDN and object cache
• Update payment gateway callback URLs if the domain changed
• Keep the old host read-only or parked briefly as insurance

For routine risk (plugin updates on the site you just moved), keep database-only backups before updates in the weekly habit. Migration gets you onto better infrastructure. Ops hygiene keeps you there.

Membership

Snapshotify Pro’s scheduling and cloud destinations sit on the same DaftPlug membership as Progressify, Lightify, Generatify, and Rankify. Manual backup/restore/migrate is available to start free on WordPress.org. Paid plans on pricing unlock the hands-off pieces across every plugin, priced by site count. Fourteen-day refund.

Takeaway

A WordPress migration fails in the database more often than in the ZIP. Use a full Snapshotify snapshot, restore on the new host or domain, and let the plugin rewrite URLs and serialized data in batches instead of improvising with SQL search-replace at 1 a.m.

Move day should feel like restoring a known snapshot sideways, not like rebuilding the site from folklore. That is the bar. Snapshotify is built to clear it.