How to Migrate to Vanta Panel

Moving to Vanta Panel is a copy-based migration: you build the new server alongside the old one, copy everything across, test it privately, and only then switch DNS. The old server is never modified, so the rollback plan is simply "don't switch". The sequence is the same whether you come from cPanel, Plesk or a hand-built LAMP box: inventory, lower DNS TTLs, install the panel on a fresh VPS, create accounts, move files, databases and mail, test with your hosts file, switch DNS, issue SSL, then run the post-migration checks. A single WordPress site takes an afternoon, and the cPanel importer does most of the work.

Before you start: two routes

Route A, from cPanel. vWHM's built-in Import from cPanel reads a full cPanel account backup and recreates the account: files, the databases you tick, mailbox folders with their messages, cron jobs with paths rewritten, and the database credentials in wp-config.php, Laravel's .env and Joomla's configuration.php rewritten automatically. You still redo mailbox passwords, custom DNS records, SSL, addon domains and FTP accounts by hand. The full cPanel migration guide shows every screen.

Route B, from anything else. Plesk, DirectAdmin, a managed WordPress host, a plain Ubuntu box. No importer, so steps 5 to 7 use rsync, mysqldump and the panel's own tools (install rsync with apt-get install -y rsync on any server that lacks it). More typing, not more risk.

Still deciding? Why self-host your control panel makes the case and is honest about the downsides.

Step 1: inventory the old server

Per site, write down: every domain, addon domain and subdomain with its document root; each database, which app uses it and its size; every mailbox, forwarder, autoresponder and mailing list; cron jobs; the PHP version; FTP accounts and SSH keys; anything outside public_html such as .env files; and total disk usage, so you size the VPS correctly.

Then export the DNS zone and highlight every record that is not a plain A record: MX, SPF, DKIM and DMARC TXT records, verification records for Google, Microsoft or your payment provider, and CNAMEs to external services. A missing SPF record does not break the website; it breaks mail three days later.

Step 2: lower DNS TTLs now

At your current DNS provider, set the TTL on the site's A records (@, www, mail) to 300 seconds, at least a day ahead, because resolvers cache the old TTL until it expires. A 300-second TTL makes the cutover propagate in minutes.

Step 3: install the panel on a fresh VPS

Rent a VPS running Ubuntu 22.04 LTS or newer, or Debian 12 or newer, with at least 2 GB of RAM and 3 GB of free disk, and nothing already serving ports 80 or 443. Then, as root:

curl -fsSL https://get.vantapanel.com | sudo bash

The installer verifies the release signature and prints your vWHM URL and admin login (also saved to /root/vantapanel-install.txt). The installation guide lists the optional settings such as DOMAIN=; the install on Ubuntu walkthrough has more detail.

Straight away in vWHM, enable two-factor authentication on the admin login and activate your licence if you are moving more than one account: Vanta Panel's Free tier runs one account, one mailbox and one database; Basic is $5 per server for five of each; Unlimited is $10 per server (pricing). The check fires when you create the second account.

Step 4: create the accounts

Route A (cPanel): on the old server run /scripts/pkgacct <user> as root and scp the resulting /home/cpmove-<user>.tar.gz into /var/lib/vantapanel/cpimports/ on the new server. Open vWHM → Import from cPanel, select the archive, click Scan selected archive, set the new username and password, tick what to import, and click Create account & import. When it finishes, ~/.vanta-import-report.txt in the account's home lists every config file that was rewritten. Without root on the old server, cPanel → Backup → Download a Full Account Backup gives the same archive to upload in the browser.

Route B: open vWHM → Create Account and enter the primary domain, a username (3 to 16 lowercase characters; it becomes the Linux user, the /home/<username> path and the database prefix, and cannot be changed later), a password, and optionally a package. The account gets its own Linux user, Apache vhost and vPanel login; your first hosting account covers the form. Add addon domains and subdomains from vPanel → Domains, and set the PHP version under MultiPHP if needed. One account per site keeps Linux users, quotas and PHP-FPM pools separate, which hosting multiple websites on a VPS explains.

Step 5: move the files

Skip this on Route A; the importer did it. On Route B, from the old server:

rsync -avz /home/olduser/public_html/ newuser@203.0.113.10:/home/newuser/public_html/

Use the new account's own SSH login rather than root, so ownership lands correctly, and make sure hidden files (.htaccess, .env, .user.ini) came across.

Step 6: move the databases

On the old server, dump each database without locking it:

mysqldump --single-transaction --routines --triggers olddb > olddb.sql

In vPanel → MySQL Databases, create a database and a user for the site; names are prefixed with the account username, so newuser_shop rather than shop. Import with the CLI (mysql -u newuser_shop -p newuser_shop < olddb.sql) or phpMyAdmin, then point the application's config (wp-config.php for WordPress) at the new name, user and password with localhost as the host.

Step 7: move the email

Create each mailbox in vPanel → Email Accounts with a fresh password; the old hashes are not portable from any panel. Mail is stored as Maildir at ~/mail/<domain>/<mailbox>/, so on Route A the messages are already there. On Route B, rsync the old Maildir into that path (or an IMAP-to-IMAP sync tool), then recreate forwarders, autoresponders and mailing lists.

Click Set up mail DNS automatically on the same page to create MX, SPF, DKIM and DMARC, or copy the values it shows into your external zone. Clients connect to mail.<your-domain> on port 993 (IMAP) and 587 (SMTP) with the full address as the username; the mail client setup guide has per-device settings.

Step 8: test with your hosts file, before touching DNS

Point only your own computer at the new server. On macOS or Linux edit /etc/hosts; on Windows open C:\Windows\System32\drivers\etc\hosts as Administrator. Add:

203.0.113.10   example.com www.example.com

Reload and click through everything: deep pages, admin login, a contact form, a checkout. Expect a certificate warning; Let's Encrypt cannot validate a domain that does not yet resolve to the server, so the placeholder certificate is self-signed on purpose. When everything works, remove the hosts line.

Step 9: switch DNS

Two options:

• Keep your current DNS provider. Recreate every custom record from your inventory first, then change the A records for @, www and mail to the new IP. With the 300-second TTL, the world follows within minutes.
• Use the panel as the DNS server. Set up private nameservers (ns1 and ns2 on the same VPS, served by PowerDNS, with glue records at your registrar), then change the domain's nameservers at the registrar. It is the right end state for a hosting business, but nameserver changes take hours, so many people switch A records first and move nameservers a week later.

Confirm with vPanel → DNS Tools: A should return the new IP, MX should return mail.<domain>, and TXT should show your SPF.

Step 10: issue SSL

Once the domain resolves to the new server, open vPanel → Domains, tick force HTTPS, and click Install SSL on each domain card. The panel requests a certificate for the bare name and www, falls back to the bare name if www does not resolve, and rolls back automatically if Apache's config test fails. Renewal is automatic. Then in vWHM → SSL / TLS click Sync trusted mail SSL now so mail.<domain> gets a trusted certificate. See the SSL guide for Cloudflare-proxied sites.

Step 11: post-migration checks

For every site:

You have no backup history on the new machine yet: enable a daily database schedule and a weekly full backup in vWHM, point them at an off-site destination, and test one restore before cancelling the old plan.

Rollback plan

Before the DNS switch, rollback is free: the old server never changed, so keep using it. After the switch, rollback means changing the A records back, which takes minutes. The catch is data written in between: orders, comments and incoming mail land on the new server from the moment DNS flips, so a later rollback means re-syncing those or accepting the loss. For sites with constant writes, put the old site into maintenance mode, take the final mysqldump, and flip DNS immediately after the import.

Keep the old server for one to two weeks, then cancel it. If you came from cPanel, cPanel pricing explained shows what that cancellation is worth per year.

FAQ

How long does a migration to Vanta Panel take?

About an afternoon for a single WordPress site on Route A, most of it copying the archive and waiting for DNS; twenty accounts is a few evenings, because you repeat steps 4 to 10 per account.

Will there be downtime?

No. The old server keeps serving until DNS flips, and at a 300-second TTL the flip is a few minutes, which is why you freeze content for the switch.

What does the cPanel importer not carry across?

Mailbox passwords, custom DNS records, SSL certificates, addon domains and FTP accounts. Files, selected databases, mail folders, cron jobs and common app config files come across automatically.

Do I need to move DNS to the panel's nameservers?

No. Changing A records at Cloudflare or your registrar is the simplest cutover; private nameservers on the VPS are optional and better done once the sites are stable.

cPanel® and WHM® are trademarks of their respective owners. Vanta Panel is an independent product, not affiliated with them; your cPanel server is never modified.