Migrating from a non-cPanel host manually

If your current provider does not run cPanel, there is no backup file to restore, so you migrate manually: recreate the account in WHM/cPanel, copy the files, export and import the database, repoint DNS, then verify. Done carefully, a small site moves with only a few minutes of visible downtime, and search engines see no disruption because the content and URLs stay identical.

Before you start: take an inventory

Non-cPanel stacks (a raw VPS, a proprietary panel like Plesk, or a managed WordPress host) store things in their own layout. List what actually powers the site so nothing is missed:

• Document root and all site files, including hidden files such as .htaccess and .env.
• Each database: name, character set, and the app user that connects to it.
• Email accounts, forwarders, and any cron jobs.
• Current DNS records and, importantly, the domain's TTL values.
• The PHP version the app currently runs on.

Step by step

1. Lower your DNS TTL to 300 seconds a day before the move. This shortens how long the old IP is cached, so the final cutover propagates quickly.
2. In WHM, create the account under Account Functions > Create a New Account. Pick a package and set the correct PHP version in MultiPHP Manager to match the source.
3. Copy the files. From the old server, archive the document root, for example tar czf site.tar.gz ., then move it across. The cleanest transfer is server to server over SSH: rsync -avz -e ssh user@oldhost:/var/www/html/ ~/public_html/. If SSH is unavailable, download the archive and upload it through cPanel File Manager, then extract.
4. Create the database in cPanel under MySQL Databases, create a database user, and grant it all privileges. Import your dump with phpMyAdmin, or on the shell: mysql -u dbuser -p dbname < backup.sql.
5. Update the app config with the new database name, user, and host (usually localhost). For WordPress this is wp-config.php; recreate any secrets or API keys from your inventory.
6. Recreate email accounts, forwarders, and cron jobs in cPanel. These do not travel with the files.
7. Test before cutover using the server hostname or a local hosts file entry pointing the domain at the new IP, so only you see the new server.

Cut over and verify

Once the test copy loads correctly, update the domain's A record to the new server IP at your DNS provider. Because you lowered the TTL, most visitors reach the new server within minutes. Keep the old account running for a few days so late-cached requests still resolve. After that, raise the TTL back to a normal value such as 3600.

Verify the essentials: the site loads over HTTPS with a valid certificate (issue one from cPanel's SSL/TLS tools if needed), forms and logins work against the new database, and redirects behave. Confirm nothing broke in indexing by watching Google Search Console over the following week; Google's own guidance on debugging traffic drops is a good sanity check if numbers move.

Where the dedicated IP fits

On our platform each site can sit on its own dedicated Class C IP. That is a footprint-control and reliability measure: it isolates your site from unknown neighbors and keeps its network identity distinct. It is not a ranking boost, and moving hosts will not by itself lift your positions. Rankings still come from content quality and genuine value; the migration simply preserves what you already have. For WordPress specifics see our WordPress SEO hosting guide, and if you would rather we handle the transfer, reach out through contact us.