You bought the new host. The domain DNS is ready to flip. Then someone says “just export the database and search-replace the old URL.” Three hours later page-builder images still point at the old domain, serialized options are corrupted, and wp-admin throws a white screen because a host mu-plugin from the previous company came along for the ride.
A WordPress migration is not a special ritual. It is a restore onto a different address. Snapshotify’s Site Migration treats it that way: restore onto any domain, URLs follow, serialized data is rewritten safely, and you are not editing config files or running hand-rolled search-and-replace scripts.
Snapshotify is the DaftPlug backup plugin. This post stays on Site Migration only: new host or domain, URLs rewritten, serialized-safe replacements, no config file editing. Not retention policy as the main story, not cloud destination setup as the main story, not smart file exclusions as the main story, not database-only backup as the primary path, not email notifications, not retry-failed-cloud-uploads as the main story. For the portable ZIP+SQL archive shape you may move between machines, keep WordPress portable backup ZIP+SQL without the plugin nearby and treat archive portability as a sibling, not a substitute for migration rewrites.
What Snapshotify actually ships here
Stay inside the real feature set:
- Site Migration for a new domain or host with URLs rewritten
- Restore onto any domain and the URLs follow
- Serialized data rewritten without corrupting it
- No config file editing and no DIY search-and-replace scripts required for the URL swap
- Full-site archive (files + database) as the migration source, with the same Snapshotify upload and restore machinery built for real site sizes
This post does not invent one-click DNS flips Snapshotify does not publish, automatic SSL certificate purchase, undocumented “zero downtime cutover orchestrators,” or a claim that migration replaces careful DNS timing. Site Migration is the product promise: restore onto any domain, URLs follow, serialized data rewritten safely, no config file editing. Stay there. Retention, cloud destinations, smart exclusions, database-only, notifications, and cloud retry are parallel tools, not this article’s job.
Why migrations fail when you “just replace the URL”
One literal replace is not enough. The old address appears as https://old.example.com, as escaped JSON inside page builders, as protocol-relative URLs, with and without www, on http and https, and sometimes percent-encoded. Miss the JSON-escaped form and the site “loads” while every builder image still points at the old host.
Serialized PHP data has length prefixes. A naive SQL replace changes string length and breaks options, widget settings, and builder data. Snapshotify’s migration path is built to rewrite serialized values safely.
Restoring the wrong server files bricks the destination. Old-host mu-plugins, SSL-forcing plugins on a destination not yet on HTTPS, and login cloaking plugins can hide wp-admin behind a slug you do not know. Migration hygiene matters as much as the string rewrite.
Table prefixes differ more often than people admit. Import alone is not enough when role and capability rows store the prefix too. A migration path that only dumps SQL without repairing those references is how you lock yourself out of wp-admin.
Trust compounds quietly. Clients rarely praise “serialized options survived.” They simply open the new domain and see working media. The metric you care about is a clean cutover, not applause for a search-replace script.
How to migrate with Snapshotify
Assume Snapshotify is installed on the source. You will take a full snapshot, move it, restore on the destination, and let migration rewrites run when the site URL differs.
1. Back up the source site fully
On the old host, create a full-site Snapshotify backup. This is not the moment for aggressive exclusions. You want files and database together. Schedules are fine for everyday life. For a move, take a fresh manual full snapshot after you freeze content edits.
2. Download it or keep it reachable in the cloud
Either download the archive or leave it in cloud storage the destination can use. The destination needs the ZIP. Do not rely on “it is still on the old server disk” after you cancel that account. If you need a portable ZIP+SQL reminder for handoff, use the related portable backup guide as adjacent reading.
3. Prepare a working WordPress on the destination
Install WordPress on the new host or domain and activate Snapshotify. The destination does not need to be empty. Restore replaces what is there. Use temporary admin credentials you control; remember that after restore you will sign in with the source site’s users.
Point DNS only when you are ready. Many teams restore on a temporary URL or hosts-file override first, then cut DNS.
4. Upload the archive on the destination
In Snapshotify, upload the backup archive on the destination. Wait until the backup appears as a restorable snapshot. Do not close the browser mid-upload on a huge site. Let chunked progress finish.
5. Restore and let Site Migration rewrites run
Start restore. Snapshotify compares the backup’s site URL to the destination. When they differ, Site Migration runs: URLs follow the new domain, serialized data is rewritten safely, and you are not editing wp-config by hand for the URL swap.
Do not close the browser mid-flight on a huge site. Let batched progress finish.
6. Check the result like a skeptic
After restore:
- Load the front end, especially page-builder pages (missed URL variants show up there first).
- Confirm media loads (uploads path and URL rewrite both worked).
- Open wp-admin with source credentials.
- Confirm permalinks behave; re-save Settings → Permalinks if links came back plain.
- Spot-check widgets, menus, and one form that stores options.
- Only then flip DNS if you restored on a temporary address first.
If URLs still point at the old domain, confirm you restored the full snapshot (not a partial file copy), confirm the destination site URL actually differs so migration mode ran, and confirm a page cache on the edge is not serving old HTML. Do not invent undocumented Snapshotify “re-run replace only” buttons that are not on the product page. Take a fresh backup and restore again if the cutover was incomplete.
7. Document the cutover for the next teammate
Write one line in your internal runbook: “Snapshotify Site Migration from [old] to [new] on [date]. Full snapshot [id/name]. Verified builder pages, media, wp-admin. DNS flipped at [time]. Retention and cloud sync are separate.” Migrations get blamed when someone deletes the old host before the verification checklist finishes.
Who this is for
Site owners moving hosts who want URLs to follow without a freelance search-replace emergency.
Rebrands and domain changes where the content stays and the address changes.
Agencies running client migrations who cannot afford corrupted Elementor or Divi options.
Stores and membership sites whose media and serialized settings are load-bearing, not optional.
Teams staging on a temporary URL before a production domain cutover.
This is less urgent for brand-new empty sites where a fresh install is cheaper than a migrate. Even then, Snapshotify Site Migration is the clean path when real content already exists.
What good looks like
- The destination loads on the new host or domain with working media.
- Page-builder pages do not still reference the old address in JSON.
- Serialized options and widgets survive without corruption.
- You did not edit wp-config by hand for the URL swap.
- Site Migration is used without requiring retention policy redesigns or cloud destination changes in the same hour.
- You signed into wp-admin with source credentials and verified permalinks.
- You did not invent DNS automation or claim migration replaces SSL and DNS planning.
If the destination white-screens, restore from a known-good snapshot again after fixing destination PHP or disk issues, and keep the source backup until verification is done. Never cancel the old host on hope alone.
Pitfalls (the ones that bite)
Naive SQL search-replace on serialized data. Length prefixes break. Use Snapshotify’s migration path instead.
Migrating a partial file copy without the database (or the reverse). Site Migration wants a full snapshot story.
Flipping DNS before verification. Temporary URL or hosts-file checks catch builder URL misses before the world sees them.
Canceling the old host before the checklist finishes. Keep the source backup reachable.
Confusing portable ZIP+SQL with migration rewrites. Portability is about archive shape. Site Migration is about URLs following a new domain. Use both deliberately.
Enabling every backup toggle during a migrate. If retention, exclusions, and cloud destinations all change mid-cutover, you cannot tell which change broke the restore. Migrate first, tune later.
Forgetting source credentials. After restore, the destination users are the source users.
Ignoring edge caches. An old HTML shell can look like a failed rewrite. Purge or bypass cache when verifying.
Practical checklist before you call it done
- Freeze content edits on the source and take a fresh full Snapshotify snapshot.
- Download the archive or confirm cloud reachability from the destination.
- Install WordPress and Snapshotify on the destination (temporary URL is fine).
- Upload the archive and wait until it is restorable.
- Restore and let Site Migration rewrite URLs when the domain differs.
- Verify builder pages, media, wp-admin (source credentials), and permalinks.
- Purge or bypass edge cache while verifying.
- Flip DNS only after the checklist passes.
- Keep the source backup until you are confident.
- Leave retention, smart exclusions, and cloud destination redesigns for a later pass if they are not already stable.
- Write the cutover date, old URL, new URL, and snapshot id in the team runbook.
- Only then cancel the old host.
Takeaway
People move hosts and domains. Hand-rolled search-replace scripts break serialized data and leave builder media on the old address. Snapshotify’s Site Migration restores onto any domain so URLs follow, serialized data is rewritten safely, and you are not editing config files for the swap. It is not retention policy, not cloud retry, and not a DNS provider. It is the quiet restore-path fix for a very ordinary WordPress migration failure.
Snapshotify handles Site Migration alongside the rest of the backup stack, without asking you to maintain a third-party search-replace ritual that knows nothing about serialized options. Take a full snapshot. Restore on the destination. Verify before you flip DNS. Keep sibling backup features as separate enablement work. For portable ZIP+SQL archive shape during handoff, use the related portable backup ZIP+SQL guide when you need that sibling story.
One Pro membership unlocks Snapshotify plus Progressify, Lightify, Generatify, and Rankify. New Pro plugins join existing memberships. Plans differ by site count only (Pro $37.99 for 1 site, Pro Plus $74.99 for 5, Pro Max $138.99 for 100), with a 14-day money-back guarantee. See pricing when a host or domain move should rewrite URLs safely instead of hoping a SQL replace holds.
Start the full snapshot. Restore on the new address. When media and builder pages still work, the migration finally respects how WordPress actually stores URLs.