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 Elementor 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 treats it that way: back up the source, restore on the destination, and when the site URL differs it rewrites URLs and paths across the database, including serialized data.
Snapshotify is the DaftPlug backup plugin. This post is about site migration: restore onto a new host or domain with automatic URL and path rewrites, serialized-safe replacements, no config-file editing, and no hand-rolled search-and-replace scripts. Not one-click restore as pure disaster recovery (already covered), not email notifications, not retention policy, not upload-existing-ZIP as the primary story, not database-only as the primary story, not exclude-cache/logs as the primary story. For the same-site emergency path, keep one-click restore of a full WordPress snapshot nearby. Same engine. Different address.
What Snapshotify actually ships here
Stay inside the real feature set:
- Migration by restore when the destination address differs from the backup’s site URL
- Automatic rewrite of URLs and paths throughout the database
- Serialized data rewritten without the classic corrupt-option failure
- 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 chunked upload and batched processing so large sites finish
Docs add important migration hygiene Snapshotify handles on purpose: roughly twenty URL variants (plain, JSON-escaped, percent-encoded, protocol-relative, http/https, www/non-www), longest match first; skipping dangerous server files and host-injected mu-plugins on migration; resetting or refreshing permalinks appropriately; repairing table-prefix capability data when prefixes differ.
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 https:\/\/old.example.com inside page-builder JSON, as //old.example.com, with and without www, on http and https, and percent-encoded. Miss the JSON-escaped form and the site “loads” while every Elementor or Divi 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. .user.ini with an auto_prepend_file from the old host, host mu-plugins that cannot be deactivated, SSL-forcing plugins on a destination not yet on HTTPS, login-URL cloaking plugins that hide wp-login.php behind a slug you do not know. Snapshotify’s migration guide skips or deactivates those classes of problems when it detects an address change. Same-site disaster restore deliberately does not strip your security stack the same way.
Table prefixes differ more often than people admit. Import alone is not enough. Role and capability rows store the prefix too. Snapshotify rewrites table names and repairs those internal references so you are not locked out of wp-admin with zero capabilities.
How to migrate with Snapshotify
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.
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 host file first, then cut DNS.
4. Upload the archive on the destination
In Snapshotify → Backups → Upload Backup, upload the archive. Uploads run in chunks so normal PHP limits stop being the whole story. Wait until the backup appears as a restorable snapshot.
5. Restore and let migration rewrites run
Start restore. Snapshotify compares the manifest’s site URL to the destination. When they differ, it runs migration steps: URL and path rewrites across variants, serialized-safe replacements, and the skip/deactivate rules that protect you from old-host landmines.
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.
- If permalinks came back plain, re-save Settings → Permalinks (Apache without rewrite support is the edge case; otherwise rules refresh in place and
.htaccessis never blindly restored because it is server-specific). - Reconnect Search Console, payment webhooks, and anything else keyed to the old domain.
- Take a fresh backup of the migrated site on its new home.
Freemius license caches are cleared so licensed plugins revalidate on the new domain. Stored accounts are left alone so you do not silently deactivate everything you meant to keep.
If you are migrating to a staging URL first, keep the live origin untouched and repeat the restore onto production only after staging passes the builder and media checks. Snapshotify does not modify the source site during a migration restore.
What good looks like
- Destination front end loads on the new host or domain without leftover old-host URLs in builder content.
- Media URLs resolve on the new address.
- Serialized options and builder JSON are intact (no truncated widgets, no broken theme mods).
- You can log into wp-admin with the migrated users.
- Host mu-plugins and dangerous server config from the old shop did not come along.
- Permalinks work (re-saved if needed).
- A new Snapshotify backup exists on the destination after the move.
- The source site is unchanged if you still need it (migration does not modify origin).
If only half the images moved, you likely restored an incomplete archive or excluded uploads by mistake. Migrate again from a full snapshot rather than patching paths by hand.
Pitfalls (the ones that bite)
DIY search-replace on serialized data. Use Snapshotify’s migration restore instead.
Migrating from a skinny backup. Exclusions that drop uploads make a pretty database with broken media.
Assuming destination empty-install users survive. They do not. Source users win.
Leaving old-host security prepend files in play. Let migration skip server config; do not manually copy .user.ini “just in case.”
Forcing SSL plugins before the destination has HTTPS. That is a redirect-loop machine.
Skipping the page-builder click tour. Green homepage, dead inner pages.
Canceling the old host before you verified the new one. Keep origin until smoke tests pass.
Treating this as database-only. Theme files, uploads, and plugins have to come along for a real host move.
Practical checklist before you call it done
- Freeze edits on source and take a fresh full Snapshotify backup.
- Download or confirm cloud availability of that archive.
- Install WordPress + Snapshotify on the destination.
- Upload the archive with chunked upload.
- Restore and allow migration URL/path rewrites to finish.
- Click page-builder pages and media-heavy templates.
- Sign in with source credentials; re-save permalinks if needed.
- Reconnect domain-bound services (Search Console, payments, webhooks).
- Take a new backup on the destination.
- Only then cancel old hosting or flip final DNS if still pending.
Write down the new home URL, the old home URL, and the timestamp of the snapshot you migrated from. When something looks wrong a day later, that note is how you know which archive to trust.
Takeaway
Moving WordPress is scary when you treat it like surgery with a text editor. It is calmer when you treat it like a restore onto a new address with a tool that understands serialized data and old-host traps.
Snapshotify migrates by restoring a full snapshot on the new host or domain, rewriting URLs and paths (including serialized and JSON-escaped forms), and skipping the server files and host baggage that brick destinations. Back up fully on the source. Upload on the destination. Restore once. Verify builder pages and media before you kill the old server.
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 the next host change should be a restore, not a weekend of search-replace.
Snapshot on the old site. Restore on the new one. When the URLs follow and serialized data survives, the migration earned the word “done.”