Migrate Between Two WP Panels

When can I use website migration?

Website migration is used to copy websites between two WP Panel servers, supporting WordPress and general PHP websites. You can also select multiple websites at once. The entry is located in the upper right corner of the „Website Management“ page.

Both servers must have the same version of WP Panel installed.
Only websites currently in the „Enabled“ state can be migrated; paused or abnormal websites must be restored to normal first.
After migration, the original primary domain and aliases will continue to be used; domain changes are not supported during migration.
If the receiving server has the same primary domain or alias, the migration will be rejected, and existing websites will not be overwritten.
BT Panel, manual environments, and other panels are not within the scope of automatic migration; manual migration should be used.

Preparation before migration

Upgrade both WP Panels to the same version.
Confirm that the two panels can access each other via their respective HTTPS addresses, and that the system times are basically consistent.
Confirm that the receiving server has no websites with the same domain and has sufficient space to store temporary data and the final website.
Choose a low-traffic period. After starting, the source website will display a 503 maintenance page until the migration is completed or canceled.
Plan DNS or CDN switching in advance; the panel will not automatically modify or wait for DNS resolution to take effect.

Connect the two panels

On the receiving server, open „Website Migration“ and select „I want to receive websites“.
Generate one-time pairing information and copy it to the source server within the validity period.
On the source server, select „I want to migrate websites“, paste the pairing information, and connect.
Select the receiving server and the websites to migrate, then run the pre-check.
After confirming that connection, version, domain, and space checks all pass, click „Start Migration“.

The pairing information contains a one-time secret; do not send it to public chats, tickets, or screenshots. When disconnecting, the panel will try to notify the other server at the same time; if the other party is offline, the local machine will still disconnect, and you should check the connection list later when the other party comes back online.

What will be migrated

The panel will migrate website files, databases, domains and aliases, SSL certificates, PHP and Nginx runtime configurations, cache settings, log policies, monitoring, expiration times, WordPress settings, and panel scheduled tasks that can be safely copied.

The built-in CDN real IP group can be used together. Custom groups will be created if they do not exist on the receiving server; if they have the same name and content, they will be reused; if they have the same name but different content, the migration of that website will be stopped to avoid overwriting existing settings.

What will not be migrated

Historical backup packages of websites and databases.
Access logs, error logs, monitoring records, and security event history.
Server-level remote backup accounts, keys, and S3 credentials.
Custom command scheduled tasks; the page will show the skipped count, and they need to be manually rebuilt on the new server.
The site API key on the original server; the receiving server will generate its own site identity and key, and related external integrations need to be reconnected.

If the source server has global remote backups enabled, the site's automatic backup policy will not be directly copied to the receiving end and needs to be reconfigured on the new server. Historical backups will not be migrated in any case.

What happens during migration

The source site will switch to a non-cacheable 503 maintenance page to prevent posts, orders, comments, or other data from changing. The original monitoring, scheduled tasks, updates, and backup switches will not be rewritten, but related write tasks will not be executed during the migration.

The receiving server will receive and check files in batches, restore the database, establish site configuration, and then perform a local health check. If there are many files or the network is slow, the maintenance time will be correspondingly longer.

After the health check passes, the receiving site will immediately become a normally enabled site and restore scheduled tasks and monitoring settings without waiting for DNS switching. Therefore, before the official switch, do not manually create new data such as orders or posts on the receiving end.

During migration, do not manually modify website files, databases, Nginx, PHP configurations, or task directories on either end. After the panel restarts, it will continue with steps that can be safely resumed; if the result is unclear, it will stop and prompt for handling rather than blindly repeating operations.

What the health check can confirm

For WordPress sites, it will check whether the program can start, whether the database can connect, and whether the core tables and site address are normal. All sites will also access the homepage from the receiving server locally to check Nginx, PHP, and obvious server errors.

This does not guarantee that public access, DNS, CDN, email, payments, third-party APIs, queue programs, or services outside the panel are normal. Supervisor, Swoole, external mounts, and self-built systemd services used by generic PHP sites will not be verified by the site migration.

View progress and handle failures

The task page will auto-refresh, showing the current step, transferred capacity, and speed; it will not provide an unreliable remaining time.
Multiple sites are processed separately; one site's failure will not block other sites.
When „Retryable“ appears, prioritize using the retry button on the task, and do not create another site with the same domain.
When canceling an unfinished task on the source server, the source site will be restored, and the receiving end will be notified as much as possible to clean up resources from this operation.
If the other server is offline, remote cleanup may not be completed immediately. After the connection is restored, check the receiving server and delete leftover tasks.
After the receiving site is enabled, even if the final scheduled task synchronization temporarily fails, the site will be retained for retry and will not be automatically deleted.

Migration tasks are temporary work records. After completion, failure, or cancellation and cleanup, the task will disappear from the list and will not be saved as long-term migration history.

Three choices after receiving is complete

After the receiving server completes, the source site remains in maintenance mode, waiting for the administrator to decide one by one:

Migration complete:End the task and keep the source site„s files and database. The source site will show “Migrated„ and remain in maintenance mode.
Migration complete and delete source site:After ending the task, proceed with the normal site deletion process to delete the source site on the current server.
Migration failed:Only restore the source site on the current source server, without relying on the receiving server being online, and do not automatically delete sites or resources already generated on the receiving server.

„Migration complete and delete source site“ is irreversible. First check the new site from real user networks, then delete the only available source site copy.

Restore a migrated source site

After selecting „Migration complete“, if you need to re-enable the source site, click „Restore source site“ in the site list, or select „Disable maintenance mode and restore to running state“ in the site details.

Restore only processes the current server: switch back to the normal website configuration and set the status to enabled. It does not check DNS, nor does it access or delete the website on the receiving server. After restoration, if you need to migrate again, you can initiate a new task.

File and program restrictions

Special files such as symbolic links pointing outside the website directory and device files will be rejected to avoid reading or writing content that does not belong to the website.
File content and permissions will be migrated, but the file„s “last modified time„ will become the receiving end“s write time. For websites that rely on file timestamps to generate version numbers or caches, you should clean or regenerate caches after migration.
Website migration only handles site resources managed by WP Panel; it will not copy self-built services, system tasks, or external storage outside the panel.

DNS switch and final checks

On the receiving server, check the frontend, backend, SSL, database connection, permalinks, media, and scheduled tasks.
Check email, forms, payments, third-party APIs, and business-critical processes.
Modify DNS or CDN origin address yourself to point the domain to the receiving server.
Confirm from mobile network or other real user networks that access has reached the new server.
After confirming the new site is stable, go back to the source server and choose to keep, delete, or restore the source site.

WP Panel does not determine whether global DNS propagation is complete. Do not delete the source site immediately based solely on the resolution result of your current computer.