WordPress Migration Guide

NebuaCloud can import an existing WordPress site — database, uploads, themes, and plugins — from wherever it's currently hosted. From your organization's dashboard, go to Migrations and select WordPress to open the migration page (/dashboard/:id/wordpress-migration). There are two ways to point it at your source site, depending on what access you have.

VPS / SSH access#

Use this when the source site is on a VPS or dedicated server you can SSH into.

Fill in:

• Site Name — a label for this migration, shown in the "Your Migrations" list.
• Host — the SSH host, e.g. ionos.example.com.
• Port — defaults to 22.
• Username — the SSH user.
• Password or Private Key — provide one of the two. A private key is preferred where the host allows it.
• Remote WordPress Path — the absolute path to the WordPress install on the remote host, e.g. /var/www/html.

Click Start Migration. NebuaCloud connects over SSH, dumps the database, and copies wp-content directly — no plugin required on the source site.

Shared hosting (no SSH)#

Use this when the source site is on shared hosting with no SSH access — the common case for budget hosting plans.

1. Click Download Companion Plugin on the migration page. This downloads nebuacloud-migration-helper.zip.
2. On the source site's wp-admin, go to Plugins → Add New → Upload Plugin, upload the zip, and click Install Now.
3. Activate the plugin.
4. Still on the source site, go to Tools → NebuaCloud Migration. Activation generates a random token here — copy it.
5. Back on the NebuaCloud migration page, fill in:
   • Site Name — a label for this migration.
   • Site URL — the source site's full URL, e.g. https://client-site.com.
   • Plugin Token — the token from step 4.
6. Click Start Migration.

NebuaCloud first calls the plugin's status endpoint on your site to confirm it's reachable and the token matches, then triggers an export and pulls the database dump and wp-content archive through the plugin's REST endpoints — all over HTTPS, no SSH needed.

The plugin only exists to make this one export possible. Once the migration completes, you can deactivate and delete it from the source site.

After migration starts#

Progress shows up under Your Migrations on the same page, polling automatically every few seconds. Each entry shows a running log and, once finished, a link to the new site's NebuaCloud subdomain. A failed migration shows its last error inline in the same list.

Troubleshooting#

"Could not reach NebuaCloud Migration Helper plugin on the source site (HTTP 404)"#

This means the request to the plugin's REST endpoint didn't reach the plugin at all, even though the plugin may be installed, activated, and the token correct. Check, in order:

1. Permalinks on the source site. Go to Settings → Permalinks on the source site and confirm it's not set to "Plain". WordPress's pretty /wp-json/... REST URLs require a non-default permalink structure to work; sites left on "Plain" (common on fresh shared-hosting installs) will 404 on /wp-json/... even with a fully working plugin. Selecting any other option (e.g. "Post name") and saving regenerates the rewrite rules.
2. Plugin is actually active. Confirm under Plugins on the source site that "NebuaCloud Migration Helper" shows as Active, not just installed.
3. Site URL is correct and reachable. The Site URL field should be the exact base URL the source site is served on (no trailing path). If the site sits behind a redirect (e.g. http:// → https://, or a www. redirect), use the final URL.
4. Security/firewall plugins. Some security plugins block or rate-limit /wp-json/* for requests that don't look like a browser. If the above checks pass and it still 404s, temporarily allow-list NebuaCloud's requests or disable REST API blocking rules in the security plugin, then retry.

"HTTP 401" instead of 404#

The plugin was reached, but the token didn't match. Re-copy the token from Tools → NebuaCloud Migration on the source site — it's regenerated only on plugin activation, so deactivating and reactivating the plugin invalidates the old one.

Migration stuck or failed partway through export#

Check the log entries under Your Migrations for the last successful step. Since the plugin re-verifies wp core is-installed-style state on each call, a transient timeout on a large wp-content directory (many uploads) is usually safe to retry by starting the migration again with the same Site URL and token.