v1.2.1

Released: Oct 29th, 2026

New Feature

• Added the one-time setup file wp-content/panelalpha-migrator-setup.php to preset the token and the settings, including allowed_destinations. The plugin reads it once and deletes it
• Added uninstall.php. Deleting the plugin from the dashboard removes its options, its scheduled cleanup, its temporary and backup tables, and its files in wp-content/migrations/
• Added readme.txt, an icon, banners and screenshots
• Added translations support for the admin texts (text domain panelalpha-migrator)

Improvement

• Renamed the plugin to PanelAlpha Migrator. The plugin folder and the zip are now panelalpha-migrator. Requires WordPress 6.2
• Received the migration on the destination through the WordPress REST API, protected by the destination's token
• Checked that the destination answers and accepts the token before anything is sent
• Imported tables into temporary tables and swapped them in with one step at the end, so the destination keeps working during the migration. A failed swap is rolled back
• Moved PHP files into place only at the end of the migration
• Cleaned up abandoned migrations after 48 hours
• Stored the token and the settings in the WordPress database
• Kept the destination's own token and settings after a migration
• Sent requests through the WordPress HTTP API and read the source database through wpdb

Removed

• Removed config.php. Use the setup file to preset the token and the settings
• Removed restore.php and the old receive path. Both sites of a migration must run 1.2.1
• Removed unused code and packages

Bug Fix

• Fixed the token and the settings being lost when the plugin was updated
• Fixed admin texts and error messages that were not escaped

v1.2.0

Released: Oct 27th, 2026

New Feature

• Added the insecure_tls option to skip the HTTPS certificate check for one migration, for a destination that has no valid certificate yet. It works only together with a manual ip. On the Migrator page it is a checkbox under the IP field
• Added a warning with the number of skipped files when files are deleted on the source during the migration, such as cache or log files. The migration still finishes
• Added creating the destination token the first time the destination's Migrator page is opened. The shipped config.php no longer has a token
• Added a user guide in the docs/ folder: installation, migrating a site, stop and resume, what gets moved, and the API

Improvement

• Required an administrator or the site token on every migration endpoint. Programs that call the API, PanelAlpha included, must send the source's token in the X-Migrator-Token header or as ?token=
• Refused loopback, private, link-local and other non-routable addresses as a destination. Addresses listed in allowed_destinations in config.php are still accepted
• Pinned the destination IP when the migration starts, so every later request goes to the same checked address
• Verified the destination HTTPS certificate on every request
• Reported a migration as finished only after the destination confirms it has every piece. Sending a piece again does not damage the file
• Allowed only one migration at a time, from the dashboard and from the API. An abandoned migration stops blocking new ones after 15 minutes (2 hours before)
• Restored each table piece in one transaction and sped up the chunk status check
• Copied nested .htaccess files and read the site address from the database
• Sent the list of tables and files to the destination before the first piece in API migrations, as the Migrator page does
• Deleted old files in wp-admin and wp-includes on the destination when the migration carries the WordPress core. wp-content is not touched
• Supported hosts that do not allow PHP to create new .php files, such as WP Engine, and files that can be changed but not replaced, such as config.php on Cloudways
• Made the finalize step work on sites without pretty permalinks
• Accepted the completion answer of a 1.1.4 destination
• Added unit tests for most services and controllers, run on PHP 7.4 to 8.5

Bug Fix

• Fixed several security issues in the migration API, file handling and token storage. Updating to 1.2.0 is recommended for all installations
• Fixed the plugin activating on PHP 7.4 and then failing during the migration. It now runs on PHP 7.4 to 8.5 and no longer logs deprecation notices on PHP 8.4 and 8.5
• Fixed backup_database and backup_files set to "false" or 0 being treated as on
• Fixed the first pieces of two tables landing in the same file
• Fixed a manual IP ignoring a custom destination port such as 8443
• Fixed start, stop and finalize steps on the Migrator page failing one another, and the success screen showing before finalize succeeded
• Fixed invalid input and a missing or malformed migration ID causing a PHP error instead of a 400 answer. An unknown ID now gets 404
• Fixed saving a new token reporting an error on servers with OPcache, and the old token still working for a while after a change
• Fixed exclusion rules that start with a dot, such as .git or /.ddev, not leaving out folders with that name
• Fixed the destination not finding the table prefix when wp-config.php does not hold it, and stopping while the tables are replaced

1.1.4

1.1.4 - 2026-09-28

Move a site to a destination that uses a different table prefix, and be sure a migration cannot write outside the WordPress folder. This version brings this repository level with the copy PanelAlpha ships.

Documentation: README · Guide

Security

• Files stay inside the site. The destination refuses any file whose path climbs out of the WordPress folder, such as ../ or an absolute path. Nothing is written, and the migration reports that piece as failed. wp-content/../wp-config.php is treated as wp-config.php, which is never overwritten.
• A safer token check on restore.php. The destination compares the token in a way that does not leak how close a guess was.

Added

• Different table prefixes. When the source and the destination use different prefixes, such as wp_ and site1_, the tables arrive under the destination's prefix, so WordPress finds them without any repair.

Changed

• Steadier connections. Requests to the destination now use HTTP/1.1, so connections behave the same on every server.
• Plugin data survives the address change. A saved object from a plugin that is not loaded is left as it was, also when it sits inside another object, instead of being altered.
• Building the plugin from the repository. vendor/ is no longer committed. Run composer install --no-dev in the plugin folder before you copy or zip it; without vendor the plugin does nothing.
• Unit tests. composer test runs them, and they run on every push.

1.1.3

1.1.3 - 2026-07-07

Sites with linked tables and with settings from inactive plugins now migrate without errors.

Changed

• Tables restore in any order. A table that points at another one no longer fails because the other has not arrived yet.
• Settings from plugins that are not active are copied as they are. Data such as WooCommerce scheduled actions used to be damaged when the address changed. Now it arrives unchanged.

1.1.2

1.1.2 - 2026-07-06

Older and unusual tables now restore on strict MariaDB and MySQL servers.

Changed

• Tables no longer get refused for their engine or storage options. Every table is created as InnoDB, and options newer servers reject, such as a tablespace or a fixed row format, are left out. The data is the same, and you do not have to fix the table by hand.

1.1.1

1.1.1 - 2026-04-16

The destination now knows the source's table prefix, and the small gaps left after 1.1.0 are closed.

Added

• Copy the .htaccess file. After a migration over the API, transfer-htaccess sends the source's main .htaccess to the destination, so redirects and custom rules come along. It replaces the destination's file, says so when the source has none, and works even before pretty permalinks are on.
• The source's table prefix in the answer. Starting a migration over the API now returns table_prefix.

Changed

• An empty table prefix is respected. A wp-config.php with $table_prefix = '';, or with no prefix line at all, is treated as unprefixed instead of silently becoming wp_.
• A deleted file does not stop the migration. If a file disappears from the source after the scan, it is skipped and the migration goes on. The batch and status answers list it in skipped_files.
• Token in a header. Where the site token is accepted as ?token=, you can also send it in the X-Migrator-Token header, so it does not have to sit in the address.

1.1.0

1.1.0 - 2026-03-16

Migrate to WP Cloud, to a server whose domain is not live yet, and sites with binary data in the database. The plugin now shows PanelAlpha, or the name of the host that supplied it, as its author.

Added

• Destination IP address. Enter the new server's IP address in Destination IP Address (Optional), or pass ip over the API, to migrate before the domain points at it. The domain is kept in every request and in the migrated database.
• WP Cloud and Bitnami. Sites whose wp-content or wp-config.php live outside the WordPress folder are scanned and restored in the right place.
• Firewall-friendly sending. base64: true over the API sends each piece encoded, for destinations whose firewall blocks raw data, such as WP Cloud.
• Force a new migration. force: true over the API removes the lock left by an earlier migration on the source, so a new one can start.
• Where the migration is. Batch answers name the table or file being sent now and the next one.
• Branding. The Plugins page shows the author name and link from an optional branding.php, and PanelAlpha by default.
• Database login fallback. When the destination's wp-config.php cannot be read, the plugin finds the login another way, or takes it from the database setting in config.php.

Changed

• Binary data moves intact. Database values that are not valid text, such as serialized binary data, arrive unchanged instead of failing the piece.
• Decimal numbers pass the integrity check. Tables with decimal numbers no longer fail with a checksum mismatch, whatever the PHP precision settings on the two servers.
• Database hosts with a port or socket. A DB_HOST such as localhost:3307 or localhost:/path/to/mysql.sock connects correctly.
• Empty files are copied without errors.
• A finished migration says so. Calling process-batch after the end answers "finalized": true with Migration is already completed instead of an error, and a migration with only the database or only the files finishes correctly.

1.0.0

1.0.0 - 2026-01-29

The first version: move a WordPress site to another WordPress installation from the dashboard or over the API.

Added

• Migrate from the dashboard. Copy the destination's address with its token, paste it on the source, and select Start Migration. The page shows the scan, the database and the files as they are sent, and a summary at the end.
• Migrate over the API. remote-sync prepares a migration and remote-sync/process-batch sends it in batches, so PanelAlpha or a script can run it without a browser. migrate.php does this from the command line. One migration runs at a time per source.
• Pieces, not one big upload. Files are sent in pieces of about 520 KB and tables 100 rows at a time, each checked on arrival, so large sites do not hit upload or time limits.
• Address change. The source address is replaced with the destination's in the database while it is sent, including inside saved settings.
• The destination keeps its own configuration. wp-config.php, the main .htaccess and the plugin itself are never overwritten.
• Stop and resume. Stop Backup pauses a migration; Resume Backup continues an interrupted one from where it stopped.
• Choose what to send. Database, files, or both, and extra folders or file types to leave out.
• Tokens. Generate New Token on the destination replaces the token and invalidates every address copied before.