Requires the free Dragon Migrate.
Licence
Enter your licence key on Tools > Migrate > Pro (keys are in your dragoncore.ltd dashboard). Keys are stored encrypted; a licence covers the number of sites you bought it for (1, 5 or unlimited), and you can deactivate a site from the same screen to free its place for another. Updates are delivered automatically to licensed sites. If the licence lapses, the plugin keeps working with every Pro feature on each activated site; what stops is new versions and support, and renewing restores both on the same key. Renewal reminders arrive by email about two weeks before the period ends.
Your licence belongs to the site it is activated on, and is kept when a transfer replaces that site's database - pushing staging over production does not hand production the staging licence, or leave it unlicensed. It is kept at every step of the transfer, not only at the end, so a long transfer never loses its licence part way through (needs Dragon Migrate 1.0.13 or later).
Features
- Site-to-site push/pull - pair two sites with a key and move the database directly, serialization-safe with URL replacement. The old site's address is rewritten in every form it takes in content: as reported, with the opposite scheme (http:// links on a site that later moved to https://), protocol-relative (
//old-site.com/...), URL-encoded (inside query strings and oEmbed caches), and the JSON-escaped form of each. Leave Find/Replace empty on a pull and the other site's address becomes this one's. On a push, Replace with is filled in with the destination's address; left empty (in the form or by leaving out--replacein WP-CLI), it rewrites to the destination's own address, the one it reports when the push starts. A push never rewrites to an empty value, so links keep their address. Needs Dragon Migrate 1.0.10 or later on the site doing the rewrite. Internationalised (non-ASCII) domains are converted to their DNS form before pairing, so they connect like any other. - File sync - uploads/themes/plugins between paired sites.
- Schedules - recurring migrations for staging refreshes. Next-run times are shown in your site's time zone.
Saving or deleting a connection or a schedule shows a notice confirming it, or an error notice if it failed. The transfer audit log shows readable labels, and its CSV export has readable column headings (times in UTC).
Pairing
Generate a pairing key on the destination, paste it on the source. Keys are stored encrypted and transfers run over HTTPS. A site on plain permalinks (no /wp-json/ address) is reached through its ?rest_route= address instead: whenever the /wp-json/ address answers with something other than the REST API (a not-found page, or the home page), the request is sent again to ?rest_route=. The address that worked is remembered for each paired site, so later requests go straight to it; if a site changes its permalinks, the other address is tried once and remembered instead.
Safety
Every transfer that replaces a database takes a restore point on the receiving site first, and refuses to start if that restore point cannot be made. If the transfer then fails part way through, the site is rolled back to it automatically - in both directions, whether you pushed to the site or pulled from another one. The rollback runs a step at a time like the transfer itself, so a large site is not cut off part way by a time limit, and it is only reported as rolled back once the restore has finished. If a rollback is interrupted (a closed tab, a cancelled pull, a sending site that stops responding), the next hourly housekeeping run finishes it. The same goes for a push whose import finished on the receiving site after the sending site stopped asking: housekeeping checks the address, then keeps the transfer or undoes it. If the receiving site stops answering while it applies a push, the sending site keeps asking for a while (dropped connections and gateway timeouts are retried), and if it still gets no answer it records the push as "Outcome unknown" rather than failed: the receiving site finishes or undoes the transfer on its own within an hour or two. A push that is cancelled, or stops, after the receiving site took the transfer is recorded the same way. The sending site asks again on its own hourly housekeeping and records the real outcome, and the Transfer tab shows each unknown push with a Check again button. In WP-CLI, wp dragon-migrate push exits with code 2 in that case. A receiving site running an older Dragon Migrate Pro does not keep the outcome once a transfer ends, so the check can only report that it has closed the transfer; check that site. The restore points are ordinary backups and stay listed on the free plugin's Backups tab, so you can also go back by hand.
After the database is applied, the receiving site checks its own address. Its siteurl and home rows are read straight from the database before the transfer and again after it (not through get_option(), which a WP_SITEURL or WP_HOME constant would answer). If either no longer holds the receiving site's own value - the URL rewrite missed it, or its write failed - it is written back directly and checked again; a push reports that it had to do this, so you can correct the Find and Replace with values. If the address still cannot be set back, the transfer is undone and reported as failed. A pull is also undone when any write in the options table failed during its URL rewrite, because those rows are the site's live settings and one left holding the other site's address can send visitors, email or API calls there. Rows that failed to rewrite anywhere else (post content and GUIDs, post meta, comments, other plugins' tables) only leave a link pointing at the other site, so the pull stands, and its result, job log and audit record say how many rows were missed and in which tables. Undoing puts the previous tables back in moments where the free plugin swapped the imported ones in (Dragon Migrate 1.0.14 or later), and replays the restore point otherwise.
On the pulling site, the downloaded copy of the other site's database (dmg-export-pull-...) is deleted as soon as the pull has been applied and checked; a failed or cancelled pull deletes it too. A rollback never needs it, as it uses the restore point.
Which form of REST address each connected site answers on (pretty /wp-json/ or plain ?rest_route=) is remembered per site and kept through every transfer, so a pull no longer replaces it with the sending site's memory.
Paired sites don't need to run the exact same release - preflight checks that both ends speak the same transfer protocol, and ordinary updates don't change it, so transfers keep working while auto-updates roll out at different times (you'll see a note that the versions differ). A release that changes the protocol says so in its changelog; only then must both ends update together, and the transfer is refused before anything is sent until they have.
When another site pulls from this one, the database is exported to a file in the free plugin's storage folder and is listed on its Export tab while the pull runs. The file is kept for about a day after the export finishes or the pulling site last downloads from it, so the pulling site can retry a download, and is then deleted by the hourly housekeeping run. Only files this add-on made for a pull (named dmg-export-served-...) are ever deleted this way; your own exports and backups are never touched.
Scheduled transfers survive an incoming transfer: the schedule belongs to the site it was set up on, not to the database that arrives.
Uninstall
Deleting the plugin keeps all its data by default, so a reinstall picks up where you left off. To remove everything on uninstall, opt in first:
wp option update dragonmigratepro_delete_data_on_uninstall 1