InstaMigrate provides authenticated REST API endpoints that enable full WordPress site migrations between servers. It handles database export\/import with binary-safe hex encoding, file archiving and transfer, and serialization-aware search-replace for domain changes.<\/p>\n\n
Features:<\/strong><\/p>\n\n Important:<\/strong> This plugin grants full database and filesystem access via its REST API. Deactivate and delete it immediately after your migration is complete.<\/p>\n\n\n Go to Tools > InstaMigrate in your WordPress admin. The API key is displayed there and can be regenerated if needed.<\/p><\/dd>\n No. This plugin exposes powerful migration endpoints. Always deactivate and delete it after your migration is complete.<\/p><\/dd>\n Yes. The search-replace engine correctly unserializes PHP data, performs replacements recursively, then re-serializes with updated byte counts.<\/p><\/dd>\n Two methods: (1) \n
\n
insta-migrate<\/code> folder to \/wp-content\/plugins\/<\/code><\/li>\nX-Insta-Key<\/code> header for all REST API requests<\/li>\n\n
Where do I find my API key?<\/h3><\/dt>\n
Is this plugin safe to leave active?<\/h3><\/dt>\n
Does it handle serialized data during search-replace?<\/h3><\/dt>\n
What authentication methods are supported?<\/h3><\/dt>\n
X-Insta-Key<\/code> header with the plugin API key, or (2) WordPress Application Passwords via HTTP Basic Auth (requires admin privileges).<\/p><\/dd>\n\n<\/dl>\n\n\n1.8.1<\/h4>\n\n
\n
\/theme\/activate<\/code> switches the active theme, installing it from wordpress.org first if it isn't present. Defaults to Twenty Twenty-One, which supports WordPress 5.3 and newer \u2014 a single theme that works across the whole supported range. This matters before a core change: WordPress ships a theme matched to each release, so the active theme is often newer than the core version being moved to, and it then calls functions that don't exist there and takes the whole site down. The response returns the previous theme so the change can be reversed. A request with no body at all does the whole step \u2014 it activates Twenty Twenty-One and installs it first if the site doesn't have it. On multisite it changes only the current site unless you ask for the whole network.<\/li>\n\/core\/update<\/code> updates WordPress core to a requested version. Intended for the case where the site you're copying from runs a newer WordPress than the site you're copying to \u2014 a migration replaces plugins, themes and the database, but not WordPress itself, so without this the destination keeps its older core and a plugin that needs the newer one can fatal on load. Raise-only by design: a request at or below the current version is reported as skipped and never downgrades. Multisite is refused outright \u2014 a network shares one copy of WordPress, so a core change there can't be limited to one site or undone per site. Hosts that require FTP\/SSH credentials for filesystem writes return a distinct fs_credentials_required<\/code> error rather than a generic failure.<\/li>\n\/plugins\/deactivate-plugin<\/code> deactivates plugins without deleting them, so the change can be undone \u2014 the response returns the previous active-plugin list as a restore point. Pass all_except_self<\/code> to deactivate everything except InstaMigrate in one call (useful before a core update). Network-activated plugins are included on multisite. InstaMigrate refuses to deactivate itself, so a site is never left without a way back in.<\/li>\n\/files\/search-replace<\/code> no longer crashes the site when the extensions<\/code> value is sent as plain text (for example txt<\/code>) rather than a list. It previously produced a \"critical error\" page with no usable error message; it now accepts a list, a comma-separated string, or a JSON array, and always returns a proper error if something else goes wrong.<\/li>\n\/files\/mkdir<\/code> now keeps new directories inside wp-content<\/code>, matching every other file endpoint. Previously it would create a directory anywhere the site's user could write. A path given relative to wp-content<\/code> still works exactly as before \u2014 it is simply anchored there instead of to an undefined location \u2014 so existing callers are unaffected. Only a path pointing outside wp-content<\/code> is now refused.<\/li>\n1.8.0<\/h4>\n\n
\n
\/files\/archive<\/code> now honors an exclude<\/code> parameter (a JSON array or CSV of wp-content-relative paths\/globs) \u2014 matched files and whole directories are left out of the archive. Default (no exclude) is byte-identical to before.<\/li>\n\/files\/list<\/code> endpoint lists a wp-content directory one level at a time, with file and directory sizes, so a migration UI can show what's on the site and let you choose what to skip. Confined to wp-content (no access outside it).<\/li>\n1.7.9<\/h4>\n\n
\n
1.7.8<\/h4>\n\n
\n
\/files\/archive<\/code> (tar.gz) no longer 500s on large uploads\/<\/code>\/plugins\/<\/code> directories. It now streams a POSIX ustar tar straight into a gzip sink one file at a time (constant memory, single pass) instead of building the whole tar in memory and re-reading it to compress (two passes that OOM'd as an uncatchable PHP fatal). Output is unchanged on the wire (still a .tar.gz<\/code>); long paths beyond ustar's 255-char limit are reported in a new long_paths<\/code> field instead of producing an unextractable entry.<\/li>\nuploads\/<\/code>, which holds uploads\/instamigrate\/<\/code>) no longer self-includes the half-written archive \u2014 the temp dir is skipped during the walk. This removes a runaway-growth timeout and the long-standing silently-ignored exclude<\/code> behaviour for the temp dir.<\/li>\n<\/ul>\n\n1.7.7<\/h4>\n\n
\n
source_url<\/code> SSRF guard. IP validation now normalizes addresses with inet_pton and tests an explicit CIDR denylist instead of PHP's range filter flags \u2014 closing bypasses via IPv4-mapped IPv6 (e.g. ::ffff:169.254.169.254<\/code>), NAT64 (64:ff9b::\/96<\/code>) and CGNAT (100.64\/10<\/code>). The host is resolved once, every returned address is validated, and the validated IP is pinned into the request (CURLOPT_RESOLVE<\/code>) so DNS rebinding between check and connect can't reach an internal address.<\/li>\n\/db\/import<\/code> now deletes a source_url<\/code>-pulled temp dump on every exit path (no orphaned gz left in uploads\/instamigrate\/<\/code>), and guards the magic-byte read against an unreadable file (clean 500 instead of a fatal).<\/li>\n\/db\/export<\/code> skip_regenerable<\/code> no longer over-matches \u2014 it uses a Wordfence allowlist (never skips wfconfig<\/code>\/wfls_*<\/code> config + 2FA secrets) and skips only Elementor telemetry (e_events<\/code>), never form submissions. ignore_tables<\/code> now also accepts suffix-only table names.<\/li>\n\/files\/fetch-probe<\/code> caps the body it buffers (origins that ignore Range can return a full body), avoiding a memory spike on large artifacts.<\/li>\n<\/ul>\n\n1.7.6<\/h4>\n\n
\n
\/db\/import<\/code> and \/files\/extract<\/code> accept a source_url<\/code> param and fetch the artifact directly from the source site (SSRF-guarded: http\/https only, blocks loopback\/private\/reserved\/link-local targets), so a destination can pull large archives straight from the source instead of routing every byte through a migration client. New \/files\/fetch-probe<\/code> endpoint reports whether the destination can reach a given source URL, so callers can fall back to chunked upload when it can't.<\/li>\n\/db\/export<\/code> can skip the data of regenerable\/log tables (opt-in via skip_regenerable=1<\/code> and\/or an explicit ignore_tables<\/code> CSV) to shrink huge dumps \u2014 the DROP+CREATE schema is still emitted so dependent plugins don't fatal, only the rows are skipped. Default behavior is unchanged.<\/li>\n\/files\/extract<\/code> accepts verify=1<\/code> to count any archive entries missing after extraction and report complete:false<\/code> + missing<\/code> \u2014 surfacing silent ZipArchive\/Phar truncation on very large file trees instead of a false success.<\/li>\n<\/ul>\n\n1.7.5<\/h4>\n\n
\n
\/db\/export<\/code> now compresses the SQL dump inline in a single pass at gzip level 1, instead of writing the full uncompressed dump to disk and then re-reading and re-compressing it at level 9. This removes a second full pass over the dump and the most CPU-intensive step of the export \u2014 on large databases the level-9 re-compression was the main cause of edge-timeout (HTTP 524) failures. The emitted SQL is byte-for-byte unchanged and the import side auto-detects gzip by magic bytes, so the compression level is fully transparent.<\/li>\n<\/ul>\n\n1.7.4<\/h4>\n\n
\n
\/insta-migrate\/v1\/plugins\/install-activate-plugin<\/code> endpoint. Installs a plugin from a URL (or .zip<\/code>) via WordPress's Plugin_Upgrader<\/code> and activates it. Powers App-driven post-migration plugin actions, so an integrating App can request specific plugins be installed on the destination as part of the migration. Authenticated via X-Insta-Key<\/code>.<\/li>\n\/insta-migrate\/v1\/plugins\/delete-plugin<\/code> endpoint. Accepts a plugin_files<\/code> array, deactivates each plugin and removes it via delete_plugins()<\/code>. InstaMigrate is filtered out of the request (both instamigrate\/insta-migrate.php<\/code> and insta-migrate\/insta-migrate.php<\/code> directory variants) so the endpoint cannot disable its own access. Authenticated via X-Insta-Key<\/code>.<\/li>\n<\/ul>\n\n1.7.3<\/h4>\n\n
\n
1.7.2<\/h4>\n\n
\n
push_file<\/code> bridge action. Source plugin can now multipart-POST a local file directly to a remote URL \u2014 typically the destination plugin's \/files\/upload<\/code> or \/db\/import<\/code> endpoint. Enables source-bridge inversion for sites where the source is firewalled (Imunify360 IP bans, custom WAFs) but the destination is reachable normally. The source plugin polls outbound, dest receives via its existing endpoints, no tracker upload sink required.<\/li>\n<\/ul>\n\n1.7.1<\/h4>\n\n
\n
1.7.0<\/h4>\n\n
\n
\/wp-json\/<\/code>). The plugin POSTs to the tracker for the next command, dispatches it via the existing internal handlers, posts the result back, and self-triggers the next tick using CURLOPT_RESOLVE<\/code> to the origin IP for CF bypass. WP-Cron bridge_safety_tick<\/code> resumes the chain on the next admin pageview if a tick dies mid-flight.<\/li>\n1.6.0<\/h4>\n\n
\n
1.5.0<\/h4>\n\n
\n
1.4.0<\/h4>\n\n
\n
manage_network<\/code> (super admin) on multisite, instead of manage_options<\/code> which subsite admins may have<\/li>\n\/files\/concat<\/code>) output restricted to plugin temp directory only<\/li>\n\/files\/search-replace<\/code>) restricted to uploads directory only<\/li>\n\/files\/upload<\/code>) destination restricted to uploads directory only<\/li>\nwp-content\/insta-migrate-tmp\/<\/code> to wp-content\/uploads\/insta-migrate-tmp\/<\/code> per wp.org guidelines<\/li>\n<\/ul>\n\n1.3.0<\/h4>\n\n
\n
\/wp-cli<\/code> REST endpoint (required exec)<\/li>\n1.2.0<\/h4>\n\n
\n
\/db\/fix-prefix<\/code> endpoint \u2014 fixes usermeta meta_key and options option_name values after a migration where the table prefix changed. Prevents users losing roles\/capabilities when the sed prefix-rewrite missed single-quoted values.<\/li>\n<\/ul>\n\n1.1.0<\/h4>\n\n
\n
\/files\/concat<\/code> endpoint \u2014 concatenate chunked file uploads on the server (for large archives exceeding PHP upload limit)<\/li>\n\/files\/search-replace<\/code> endpoint \u2014 search-replace strings within static files on disk (CSS\/JS\/JSON), used for Elementor CSS domain replacement after DB search-replace<\/li>\n1.0.0<\/h4>\n\n
\n