Part of the guide: How to restore a WordPress site without phpMyAdmin or FTP
Part of the guide: Migrate a WordPress site to a new host
Moving a WordPress site to a new host or domain is usually the fiddliest job in WordPress. BackupEase Pro turns it into a pull migration: the new site fetches everything from the old one using a single-use key, imports the database, and rewrites every stored address for you. You never need FTP access to the old server.
Migration runs on the destination site and needs BackupEase Pro there. The source site only needs the free BackupEase installed and active, so it can generate a key. See Installing BackupEase if you need to set that up.
How a pull migration works
The destination site connects to the source and pulls everything across. In order, BackupEase Pro:
- Authenticates with a single-use 64-character migration key, valid for 24 hours and revoked the moment the migration succeeds.
- Streams the files and the database in chunks, so a large site never loads into memory at once.
- Imports the database, rewrites every stored address for the new location, and updates
wp-config.php.
It uses WP-CLI where it can and falls back to pure PHP on shared hosting. The wizard has three steps: generate a key on the source, configure the destination, then run it.
Step 1: Generate a key on the source site
- Open the Migration tab on the old site Sign in to the site you are moving away from and open BackupEase › Migration.
- Generate the key Click Generate Migration Key. The key is 64 characters, marked expires in 24h, and can be revoked at any time with Revoke Key.
- Copy it, with the source URL Use Copy Key, and note the old site’s address. You will paste both into the new site.
Step 2: Configure the destination site
Set up a clean WordPress install at the new location, activate BackupEase Pro, and open BackupEase › Migration. This step has three lettered sections.
A. Paste Migration Key
- Enter the source Put the old site’s address in Source Site URL and the key in Migration Key.
- Connect Click Connect to Source. On success the section collapses to Connected, with a Change button if you need to go back.
B. Smart Find & Replace
Old URL fills in from the source as you connect and is read-only. New URL is this site. Server paths are detected automatically, so there is nothing to type here in a normal move.
Under Show Advanced Path Rules there is one checkbox, Update all URLs in the database to use this site’s domain, ticked by default. Leave it ticked unless you are deliberately making an exact clone, for example a staging copy that must keep answering on the original address. Unticking it imports the database as-is, with no address rewriting at all.
C. Lightning Speed Transfer
This is the SSH section, and it is enabled by default because it is worth using: supplying the source server’s SSH details bypasses HTTP limits and moves the files up to ten times faster. Without it the migration still works, over standard HTTP.
| Field | What goes in it |
|---|---|
| SSH Host | The old server’s hostname, for example example.com. Your host may give you a different SSH hostname from your site address. |
| Port | 22 unless your host says otherwise. Some hosts move SSH to a non-standard port. |
| Username | Your SSH or cPanel username, not your WordPress login. |
| Authentication Method | Password or SSH Private Key. Some hosts disable password logins entirely, in which case a key is the only option. |
| Remote WordPress Path | Leave blank. It is filled in for you when the connection test passes. Set it by hand only if detection fails, for example /public_html. |
Fill the fields in and press Test SSH Connection before moving on. Do not skip that: a bad SSH configuration discovered halfway through a transfer costs you the whole run.
Generating an SSH key
If your host offers password logins, you can use one and skip this section. Otherwise, or if you would rather not put a password in a form, you need a key pair. The private key goes into BackupEase on the new site. The public key gets authorized on the old server. They are generated together, and they are not interchangeable.
BackupEase cannot open a passphrase-protected private key. There is nowhere to type the passphrase, and the connection fails at the login step with an authentication error that does not explain why. cPanel offers a passphrase field and encourages you to fill it. For a key used only for this migration, leave it empty, and delete the key afterwards.
In cPanel
- Open the SSH key manager On the old site’s cPanel, go to Security › SSH Access, then Manage SSH Keys.
-
Generate a new key
Click Generate a New Key. Give it a name you will recognise, such as
backupease-migration. Leave the passphrase fields empty. RSA at 2048 or 4096 bits is fine, and so is ED25519 if offered. - Authorize the public key Back on Manage SSH Keys, find your new key under Public Keys and click Manage, then Authorize. It must read authorized. A key that exists but is not authorized will not let you in, and this is the step people miss.
-
Copy the private key
Under Private Keys, click View/Download on the same key and copy the text exactly as shown, including the
-----BEGINand-----ENDlines. Ignore the option to convert it for PuTTY: a.ppkfile is a different format and BackupEase cannot read it. - Paste it into BackupEase On the new site, in section C, choose the SSH Private Key tab and paste the whole key into the box. Then press Test SSH Connection.
In Plesk
Plesk has no key generator of its own. Generate the pair on your own computer with the ssh-keygen recipe below, then paste the public key into Websites & Domains › SSH Access › SSH Keys on the old server, and the private key into BackupEase.
With ssh-keygen, on any computer
Works on macOS, Linux, and Windows with PowerShell or WSL. The empty -N "" is what leaves the passphrase off.
Generate the pair:
ssh-keygen -t ed25519 -N "" -f ~/.ssh/backupease_migration
Then install the public half on the old server:
ssh-copy-id -i ~/.ssh/backupease_migration.pub [email protected]
If ssh-copy-id is not available, open ~/.ssh/backupease_migration.pub, copy the single line inside it, and append it to ~/.ssh/authorized_keys on the old server. That file must be mode 600 and the .ssh folder mode 700, or the server will ignore it.
The private key to paste into BackupEase is the file without the .pub extension.
A passphrase-less key that opens your old server is worth protecting. Once the migration has finished, remove it from the old server’s authorized keys and delete it from your computer. Clearing the field in BackupEase does not revoke anything on the server.
Step 3: Run the migration
- Review, then start The Ready to Pull summary shows the source, the destination, the file count and whether the transfer will use SSH or HTTP. Check that line reads SSH if you configured it. Then click Run Migration and confirm that it will overwrite the destination.
- Watch the stages Each stage is marked as it runs and finishes, and the list stays on screen for the whole migration. The percentage sits under the progress bar.
- Finish On success the page reloads to refresh your session. Log in with the source site’s credentials: the user table came across with everything else.
Progress is saved to a state file, so if the browser closes or a step is cut off, reopen the Migration page and start again to pick up where it stopped. Leftovers from an earlier attempt are cleared before a new one begins, so repeated attempts do not fill the disk.
When the connection fails
| Symptom | Usual cause |
|---|---|
| SSH test fails with an authentication error, and the key looks right | The key has a passphrase. Generate one without. Or the public key is present on the server but not authorized. |
| SSH test fails after the old server was rebuilt or moved | BackupEase records a server’s host key the first time it connects and refuses a changed one, which is what stops someone impersonating your old server. A genuinely rebuilt server needs its recorded key cleared before it will connect again. |
| Connect to Source fails on the certificate | The message names which of the three it is: expired, self-signed (common on local and staging sites), or issued for a different address. Fix the certificate, or migrate over HTTP from a source with a valid one. |
| The key is rejected as expired | Keys last 24 hours and are single-use. Generate a fresh one on the source. |
| A large site stops with an unclear error from the source | Older versions ran the source server out of memory while packing files. Update BackupEase on the source site as well as the destination. |
After the migration
- Re-save Settings › Permalinks.
- Check URLs, images and forms, then clear any cache or CDN.
- Confirm SSL is active on the new domain.
- Remove the migration key from the old site if you revoked nothing, and delete the SSH key you created for the move.
Older releases left the migration working folder readable over the web, and it held a copy of your database and your wp-config.php. That folder is locked down from 2.1.0 onward, and folders left open by earlier versions are repaired the next time you run a migration. If you ran a migration before updating, change your database password.

