WordPress migrations

OPanel moves an existing WordPress site onto a new site here from either of two sources, whichever suits the old host.

Migration Connector (no SSH needed)

For sites on a host that doesn’t offer SSH access — most shared hosting — the Migration Connector plugin does the job over plain HTTPS requests.

1. On the old site, install and activate the Migration Connector plugin. Your panel offers the plugin as a direct download from the new site’s Tools → Site Migration page.
2. Open Tools → Site Migration on the old site (added by the plugin) and choose Generate migration key. The key is shown once, expires after 7 days, and can be turned off or regenerated at any time — generating a new one invalidates the old.
3. Paste the key into the new site’s migration page here. If the old site doesn’t use HTTPS, you’ll need to explicitly allow HTTP for the transfer.
4. The migration runs in short, resumable steps, so you can close your browser — PHP time limits on the old host don’t matter. Once it’s done, turn the key off or remove the plugin from the old site.

The migration pulls the old site’s files and database, rewrites URLs throughout (including inside serialized data), and lands on the new site ready to go — check it on its preview address, then point DNS at your new server when you’re happy with it.

Note

The plugin is a small, purpose-built tool (GPL-2.0-or-later) that only exists to talk to this migration process — it doesn’t touch anything else on the old site, and every request it answers is cryptographically signed and time-limited.

SSH/SFTP pull

If the old host offers SSH access, give the new site’s migration page the old host’s address, credentials (password or private key) and remote path instead. Files transfer over rsync, and the database is exported and imported directly over the SSH connection — no plugin needed on the old site at all.

What the migration handles

• Files and the full database, including correctly rewritten serialized PHP data (the classic failure mode of naive search-and-replace tools)
• Table prefixes and character sets read automatically from the source
• Large sites, transferred in resumable chunks so a dropped connection doesn’t restart the whole job

Limits

• The site plus database must fit within the destination plan’s disk quota — checked before the transfer starts, and again as data actually arrives.
• WordPress multisite networks, a WordPress install kept outside the site’s home directory, and database views, triggers, routines and events are not carried over by this migration; move those by hand.
• Symbolic links on the source aren’t followed.
• Because the source site keeps running during the transfer, changes made there after the export started may not be captured — plan your DNS cutover close to the migration’s completion for an active site.

Only public internet addresses can be used as a migration source — the transfer explicitly refuses private, internal and cloud-metadata addresses, so this can’t be pointed at anything on your provider’s own infrastructure.