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 → Add 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 /home/<customer-user>/sites/<domain>/public/

Or use the File Manager in the customer panel to upload the tarball and extract via the right-click menu — saves you the SSH dance.

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: Databases → <db> → Import and pick the SQL file. 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 will provision a fresh Let's Encrypt cert within seconds of the first HTTPS request from a real visitor. Watch journalctl -u novapanel on the new host if you want to see it happen.

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> /home/<customer-user>/sites/<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.