Migrate a WordPress site to NovaPanel

What you'll need

• SSH access to the source server or a way to download a full site archive (WordPress backup plugin, host backup file).
• The source database — credentials or a fresh mysqldump / pg_dump file.
• An empty NovaPanel install with a customer account ready to receive the site.
• Roughly 30 minutes including DNS propagation. The actual file/DB copy is usually under 5.

Step 1 — Create the destination on NovaPanel

In the customer panel: Sites → New Site (the dialog is titled Create Site). Pick the same domain. Don't point DNS yet — we want to land everything in place first, test, then flip DNS.

In Databases → Create database: same name as the source DB if you want minimal config edits, otherwise note the new name + user + password — you'll update wp-config.php later.

Step 2 — Pull files from the old host

SSH into the source server and create a tarball of the WordPress install:

cd /home/<old-user>/public_html  # or wherever the site lives
tar czf /tmp/site.tar.gz .
scp /tmp/site.tar.gz user@new-host:/tmp/

On NovaPanel, unpack into the new site's docroot:

ssh user@new-host
sudo -u <customer-user> tar xzf /tmp/site.tar.gz \
  -C /srv/sites/<customer-user>/<domain>/public_html/

NovaPanel stores every account under /srv/sites/<customer-user>. The account's first site lives directly in /srv/sites/<customer-user>/public_html/; each additional site gets its own folder named after the site (usually the domain), e.g. /srv/sites/<customer-user>/<domain>/public_html/. Extract into whichever docroot matches the site you're migrating.

Or use the File Manager in the customer panel to upload the tarball and extract it with Extract here from the row's ⋮ menu — saves you the SSH dance. That menu only appears in list view, not grid view.

Step 3 — Pull the database

On the source server:

mysqldump -u<old-user> -p <old-db> > /tmp/db.sql
scp /tmp/db.sql user@new-host:/tmp/

On NovaPanel, restore it via the customer panel: DB Tools (its own sidebar item, next to Databases) — pick the target database, drop in the .sql file, and click Import. Or via SSH:

mysql -u<new-user> -p <new-db> < /tmp/db.sql

Step 4 — Update WordPress config

Edit wp-config.php in the new docroot. Update:

define('DB_NAME',     'newdbname');
define('DB_USER',     'newdbuser');
define('DB_PASSWORD', 'newdbpass');
define('DB_HOST',     'localhost');

If the domain is changing or you're testing under a temporary URL, also update WP_HOME and WP_SITEURL — but for a like-for-like migration with the same domain, leave those alone.

Step 5 — Test before flipping DNS

Add a temporary entry to your local /etc/hosts file so your browser resolves the domain to the new server's IP:

192.0.2.42  example.com www.example.com

Visit the site. Confirm the homepage, a few inner pages, the admin login, and a media-rich page all render. Check wp-admin works. If anything's off, fix it now while DNS is still pointing at the old server.

Step 6 — Flip DNS

At the registrar, change the A record (and AAAA if you have IPv6) to the new server's IP. Lower the TTL first if it's set to days — drop it to 5 minutes a day before you cut over so propagation is fast.

Caddy on the new server provisions a fresh Let's Encrypt cert on its own as soon as the site's config is loaded — it doesn't wait for a visitor, so the certificate is normally already in place before you flip DNS. Watch journalctl -u caddy on the new host if you want to see it happen (Caddy runs as its own systemd unit, separate from novapanel).

Step 7 — Decommission the old host

Wait at least 24 hours after the DNS change before tearing down the old server — late DNS caches will still send some traffic there. Once cache TTL has expired everywhere, you're safe to cancel.

Common gotchas

• File permissions. Pulled tarballs sometimes carry weird ownership. Run chown -R <customer-user>:<customer-user> /srv/sites/<customer-user>/<domain> after extracting.
• PHP version mismatch. If the old host ran PHP 7.4 and the new one is on 8.3, some plugins might break. The Sites page lets you pick a PHP version per site — start with the same version you had, then upgrade after.
• Email DNS. If the old host was also handling mail (MX records pointing there), set up email separately before flipping DNS, or you'll have a window where mail bounces.