How to Migrate a cPanel Site to HestiaCP

A control panel migration is usually not the hard part. The hard part is moving files, databases, mail, DNS, and PHP settings without discovering at 2 a.m. that an old cron job was doing something useful.

To migrate a cPanel site to HestiaCP, treat the new server as a clean rebuild rather than a place to dump a full cPanel backup. cPanel and HestiaCP organize users, domains, mailboxes, database names, and web roots differently. Copy the parts your site needs. Leave behind the panel-specific clutter.

This is a practical migration process for people who are comfortable with SSH, database dumps, and reading an error log when something fails.

Before You Migrate a cPanel Site to HestiaCP

Start by inventorying the current account. Do not assume the site is only the contents of public_html. Check addon domains, subdomains, redirects, cron jobs, email accounts, DNS records, databases, and the PHP version in use. A small WordPress site may take an hour. A site with several domains, custom mail routing, and scheduled scripts needs more planning.

Lower the DNS TTL at least a day before the cutover if you control the existing zone. A value of 300 seconds is usually enough. This does not eliminate propagation, but it reduces the time visitors can be sent to the old server after you change records.

Take backups before touching anything. Download a cPanel backup if you want one for disaster recovery, but do not rely on it as your migration method. A full backup contains cPanel account metadata that HestiaCP does not use. For the actual move, collect a file archive or use rsync, export each database with mysqldump, and document DNS and email settings.

You should also record the current runtime details: PHP version, PHP extensions, document root, application environment variables, cron commands, and any custom .htaccess rules. HestiaCP uses Nginx in front of Apache by default. Most standard Apache rules work, but an application with unusual rewrite rules or custom server directives deserves a test before DNS changes.

Build the HestiaCP Account First

Create the HestiaCP user and add every domain before moving content. You can do this in the control panel or from the command line. On a server where you have root access, the basic workflow looks like this:

bash v-add-user username strong-password [email protected] v-add-web-domain username example.com v-add-web-domain username www.example.com

Use the domain setup that matches your existing site. If www.example.com redirects to example.com, set that behavior in HestiaCP rather than maintaining two separate copies of the site. Add subdomains individually if they have their own content or application configuration.

HestiaCP places a primary site document root at:

text /home/username/web/example.com/public_html

That is not the same as a typical cPanel account layout. Addon domains are especially worth checking. In cPanel, an addon domain may live inside the main site’s public_html directory. In HestiaCP, each web domain normally gets its own directory. Moving the old nested layout blindly can create broken paths, accidental public files, or duplicate applications.

Create the destination database and user before importing data. Database names in HestiaCP are commonly prefixed with the Hestia account name, so do not expect the old cPanel credentials to carry over unchanged. Update your application configuration after the import. For WordPress, that means wp-config.php. For Laravel, it is usually .env. For other applications, check the config file rather than guessing.

Move Website Files Without Moving Junk

For a small static site, an archive and secure copy may be enough. For a live WordPress, Drupal, or Laravel site, rsync is usually the cleaner option because you can run it once before cutover and again just before switching DNS.

From the new server, a basic transfer can look like this:

bash rsync -avz --progress olduser@old-server:/home/olduser/public_html/ /home/username/web/example.com/public_html/

Adjust the source path to match the old account. If you do not have SSH access to the cPanel server, create an archive of the actual site files in File Manager and upload it to the new account. Extract it inside public_html, not one directory above it.

Do not copy cPanel-generated directories unless you know the application needs them. Files such as error logs, old backup archives, cPanel metadata, and abandoned installers consume disk space and add nothing to the new server. This matters on a budget plan with finite storage. Keep the site, uploads, configuration, and application code. Leave the baggage behind.

Set ownership after transferring files if you moved them as root:

bash chown -R username:username /home/username/web/example.com/public_html

Normal file permissions are usually 644 for files and 755 for directories. Avoid using 777 to make an error disappear. If an application needs write access, identify the specific directory, such as WordPress uploads or Laravel storage, and fix ownership and permissions there.

Export and Import the Database

Export each cPanel database from SSH or phpMyAdmin. SSH is more predictable for larger databases:

bash mysqldump -u old_db_user -p old_database > old_database.sql

Copy the SQL file to the HestiaCP server, then import it into the new database:

bash mysql -u new_db_user -p new_database < old_database.sql

After import, update the application with the new database name, username, password, and host. The host is normally localhost, but use the value configured on your server.

If the domain name is not changing, do not run a search-and-replace across the database just because you migrated hosts. It can damage serialized data in WordPress and create work you did not need. A database URL replacement is only needed if the actual site URL changes.

Test the application before public DNS points to the new server. The cleanest method is a temporary hosts-file entry on your own computer that maps the domain to the new server IP. That lets you check the real domain, real paths, and real configuration without sending visitors to the unfinished server.

Log in to the admin area, submit a form, upload an image, test a password reset if mail is configured, and inspect the error log. For Laravel or similar apps, confirm writable directories, queue workers, and scheduled tasks. For WordPress, check permalinks and plugins that depend on server-side image processing or cache rules.

Email, Cron Jobs, and DNS Are Separate Jobs

Website files do not include email. If email is hosted on the cPanel account, create the required mailboxes in HestiaCP first. Then copy existing messages with an IMAP migration tool or client-side synchronization. Mailboxes can be large, and mail transfer may take longer than the web migration, so start it before the final cutover.

Check DNS records one by one. At minimum, review A records, www, MX, SPF, DKIM, DMARC, and any records for third-party services. Do not replace a working DNS zone with a default one and hope for the best. A forgotten TXT record can break email delivery, domain verification, or a payment provider integration.

Recreate cron jobs manually. cPanel cron entries do not automatically appear in HestiaCP. Confirm the command path, PHP version, and execution user. A job that ran under /usr/local/bin/php on the old machine may need a different PHP binary or command on the new one.

Cut Over, Then Issue SSL

When the site works through your local test and the final database sync is complete, change the DNS A record to the new server. If you use external DNS, update it there. If HestiaCP manages DNS, make sure the domain is actually using the new nameservers before expecting its zone to matter.

Wait until the domain resolves to the new server, then issue a Let’s Encrypt certificate from HestiaCP. SSL validation will fail if the request still reaches the old host, if a proxy points elsewhere, or if the domain’s web root is wrong. Test both the root domain and www version after the certificate is installed.

Keep the old hosting account active for several days. Watch access logs, mail flow, and application errors. Run one final rsync if users can still upload files to the old site during propagation. Once traffic and mail are clearly landing on the new server, cancel the old service on your schedule, not five minutes after changing DNS.

HestiaCP is a good fit when you want a straightforward open source stack and do not need a host to perform the migration for you. Ular.Host is built for that same kind of self-managed setup: low cost, familiar tools, and no pretend concierge layer. Do the inventory first, test before DNS, and the move stays boring. That is the goal.