Migrating a Website from a Non-Panel Ubuntu Server to cPanel: A Full Guide to Moving Files and MySQL Safely

Back when I was about two years into my NOC job, one ticket still sticks with me. A client called at nine in the morning with full-on panic in their voice. Their website had to move from an Ubuntu server that a former developer had pieced together by hand, over to a fresh cPanel hosting account. And all they handed me was an SSH username and a password.

No documentation. No notes on paths. Nobody even knew which folder the site lived in. Imagine that. I had to dig through that box one config file at a time — Apache vhosts, the contents of /home, all of it — just to find the domain and its document root. That’s the day I learned that migration itself is easy. Finding your stuff is the hard part.

Why This Scenario Keeps Showing Up

The problem isn’t just “where are the files.” There are layers to it. A non-panel Ubuntu server is like a house your own contractor built and then vanished — only they knew the layout. Sometimes the site lives in /var/www/html, sometimes in /home/site-lama-client.com, and I’ve found live sites sitting in backup folders nobody remembered existed. Because there’s no control panel, every vhost and database was hand-configured, one at a time. So when someone asks you to move it, you work backwards like a detective: read the config, find the ServerName, chase the DocumentRoot, and only then figure out what actually needs a backup.

What makes it messier is that these servers usually run for years with several domains stacked on the same box. Five or six sites isn’t unusual. So when you’re only migrating one, you have to be surgical about what you grab. It stops being a technical problem and becomes an exercise in precision. Pull the wrong thing and you might take down a site that was supposed to stay behind.

And the cost of getting it wrong is real. Website down, email broken, database corrupted — or the classic: forgetting that website files and MySQL databases are two separate things that both need to travel. User trust drops, revenue takes a hit, and honestly, your credibility as an engineer is on the line too. That’s why I keep telling my team that migration is 70% preparation and 30% execution. And preparation starts with knowing exactly what you have on the old box.

Here’s an analogy that helped me when I was starting out. Think of moving houses. A non-panel Ubuntu server is a self-managed place you designed yourself — everything sits exactly where you put it, and only you know where that is. cPanel is a managed apartment building: there’s a storage room, a front desk, it’s tidy. Before you move, you inventory every item and where it lives. Skip that and you’ll show up at the new place missing half your stuff. Website migration is exactly that, except the “stuff” is PHP files, a MySQL database, and domain config hiding inside config files.

Prep Work Before You Touch Anything

Before you SSH into anything, line these up first:

• SSH access to the old Ubuntu server — root or a sudo-capable user. If you don’t have it, ask whoever owns the box.
• Credentials for the new cPanel/WHM server and the name of the cPanel account you’ll use.
• Contact info for the domain owner, because you’ll need to touch DNS later. This one gets forgotten a lot.
• Public IPs of both servers. The old one for reference, the new one for local testing via /etc/hosts.
• Screen or tmux, especially if the transfer is big. Trust me, your connection will drop at the worst moment.

One more thing: keep notes. I usually build a local checklist that looks like this — domain, old server IP, document root, web engine (Apache or Nginx), PHP version, list of databases, list of cron jobs, and any special config (redirects, .htaccess, whatever). In the middle of the chaos, that note will save you.

Step 1: Find the Domain and Document Root on the Ubuntu Server

This is the part that makes people give up. But it’s actually pretty systematic. Log in over SSH and figure out which web server is running first.

Apache: Check the Vhosts

On Apache, vhosts usually live in /etc/apache2/sites-enabled/ (or /etc/httpd/conf.d/ on CentOS, but we’re on Ubuntu, so focus on the first). Let’s see what’s there:

ls -la /etc/apache2/sites-enabled/

Then open the config files one by one. Inside you’ll typically find a ServerName and a DocumentRoot:

grep -RE "ServerName|DocumentRoot" /etc/apache2/sites-enabled/

Output looks like:

/etc/apache2/sites-enabled/site-lama-client.com.conf: ServerName site-lama-client.com
/etc/apache2/sites-enabled/site-lama-client.com.conf: ServerAlias www.site-lama-client.com
/etc/apache2/sites-enabled/site-lama-client.com.conf: DocumentRoot /home/site-lama-client.com/public_html

There it is. The domain is site-lama-client.com and the document root is /home/site-lama-client.com/public_html. It’s not always this clean though. If the DocumentRoot isn’t explicit or there are wildcard vhosts, search across the available configs:

grep -R "DocumentRoot" /etc/apache2/sites-available/ | sort -u

And if Apache is serving on 443 (HTTPS), check the SSL configs too — the document root for HTTPS is sometimes different.

Nginx: Check the Server Blocks

If it’s Nginx, configs live in /etc/nginx/sites-enabled/ or /etc/nginx/conf.d/. Hunt for server_name and root:

grep -RE "server_name|root " /etc/nginx/sites-enabled/

Example output:

/etc/nginx/sites-enabled/site-lama-client.com: server_name site-lama-client.com www.site-lama-client.com;
/etc/nginx/sites-enabled/site-lama-client.com: root /var/www/site-lama-client.com;

Still nothing? Check the main /etc/nginx/nginx.conf, or grep for the domain name across /etc/nginx/:

grep -R "site-lama-client.com" /etc/nginx/

Check DNS and /etc/hosts

If the configs come up empty, don’t panic. Confirm whether DNS for the domain still points at this server:

dig +short site-lama-client.com
dig +short www.site-lama-client.com

If the IP that comes back matches the old server, DNS still points here. Good — that means you can test things directly. Then check /etc/hosts on the box in case there’s a manual override:

cat /etc/hosts

If you see something like “203.0.113.10 site-lama-client.com”, there’s a manual mapping you’ll need to account for later.

Check Who’s Listening on Port 80

Last resort, and honestly a solid one: see who’s actually listening on ports 80 and 443.

sudo ss -tlnp | grep -E ":80|:443"

Output:

LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("apache2",pid=1234,fd=4))
LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("apache2",pid=1234,fd=5))

That confirms which web server is active. And if you’re curious what the site actually serves, hit it directly:

curl -sI http://site-lama-client.com | head -20

That shows you the server header and, usually, whether it’s serving content directly or through a proxy.

Step 2: Identify What the Site Is

Once you have the document root, go inside and take a look:

ls -la /home/site-lama-client.com/public_html/

The contents will usually tell you the CMS. Spot a wp-config.php? It’s WordPress. An artisan file or .env? Laravel. CodeIgniter? Look for application/config/database.php. Also check for a .htaccess, because it often carries rewrite rules that need to come along:

cat /home/site-lama-client.com/public_html/.htaccess

Jot down the PHP version the old server uses, so you can match it on cPanel later:

php -v

Though php -v shows the CLI version, which isn’t always what the vhost uses. The most accurate answer lives in the vhost config or the PHP-FPM pool. But at least you’ll have a ballpark.

Step 3: Back Up the Website Files (Do This Before Anything)

Archive the website files from the document root you found. From the old server, move into the parent directory first so the paths inside the tarball stay clean:

cd /home
tar -czf /tmp/site-lama-client.com-files-$(date +%Y%m%d).tar.gz site-lama-client.com/

Make sure hidden files — .htaccess, .env, .user.ini — are included. tar includes them by default, but verify anyway. Then confirm the archive is real and not empty:

ls -lh /tmp/site-lama-client.com-files-*.tar.gz
tar -tzf /tmp/site-lama-client.com-files-*.tar.gz | head -30

Make sure .htaccess is in that list. If it’s missing, it didn’t get backed up — and that’s dangerous, because on cPanel .htaccess can decide whether your site lives or dies.

Step 4: Back Up the MySQL Databases

Two things must travel: the files AND the database. Bring only the files and you’ll have a hollow shell of a website. First, list what databases exist:

mysql -u root -p -e "SHOW DATABASES;"

If root login doesn’t work, use the credentials from the app’s config file. For WordPress, open wp-config.php and note the DB_NAME, DB_USER, and DB_PASSWORD:

grep "DB_" /home/site-lama-client.com/public_html/wp-config.php

That tells you which database is actually relevant. Now dump it. Important: dump per-database so the restore on cPanel is straightforward:

mysqldump -u root -p --single-transaction --routines --triggers client_production > /tmp/client_production-$(date +%Y%m%d).sql

If the database is huge, split it per table, or compress on the fly:

mysqldump -u root -p --single-transaction --routines --triggers client_production | gzip > /tmp/client_production-$(date +%Y%m%d).sql.gz

Verify the dump again — an empty SQL file is the worst kind of false success. Make sure there are actual INSERT statements inside:

grep -c "INSERT INTO" /tmp/client_production-*.sql

If that number is zero, your dump failed. Don’t move forward until this is right.

Step 5: Transfer the Files and SQL to the cPanel Server

Your data is sitting in /tmp on the old server. Move it over with scp or rsync. From the cPanel server (or from the old one — depends which direction the network allows), something like:

scp root@203.0.113.10:/tmp/site-lama-client.com-files-*.tar.gz /home/client_user/
scp root@203.0.113.10:/tmp/client_production-*.sql.gz /home/client_user/

For bigger files, rsync is more forgiving — it can resume if the connection drops:

rsync -avzP root@203.0.113.10:/tmp/ /home/client_user/migrasi-tmp/

Verify the transfer by comparing sizes. Even a small difference usually means a corrupted file:

ls -lh /home/client_user/site-lama-client.com-files-*.tar.gz

Step 6: Restore on cPanel — Files and Database

Upload and Extract the Files into public_html

Log into the cPanel account you’re using. First, set up the matching addon domain or subdomain under “Domains”, so the target folder (public_html or the addon’s folder) actually exists. Then upload the tarball into that document root via File Manager or SFTP.

Now extract. Via terminal, for an account whose document root is /home/client_user/public_html:

cd /home/client_user/public_html
tar -xzf /home/client_user/site-lama-client.com-files-*.tar.gz

Watch the folder structure here. If the old server’s document root held the site files directly (index.php, wp-config.php), then public_html should hold those files directly too — not a nested site-lama-client.com folder. If you spot that nesting, move the contents up one level. It’s the most common migration mistake and it’s why people end up staring at a 404.

Create the Database on cPanel and Import the SQL

In cPanel, go to “MySQL Databases”, create a new database and a new user, then attach the user with all privileges. Note the names — they usually get prefixed with the account username, like client_user_dbname. Then import the SQL in phpMyAdmin: pick the database you just created, open the “Import” tab, choose the .sql or .sql.gz file, go.

Or via terminal:

cd /home/client_user
gunzip -k client_production-*.sql.gz
mysql -u client_user_dbuser -p client_user_dbname < client_production-20260730.sql

Make sure there are no fatal errors like “database already exists” or “duplicate entry”. If there are, go back to the SQL file and fix it — don’t just shrug.

Step 7: Fix the Application Configuration

This is where people stall. Files are moved, database is imported, but the site still errors. Why? Because the app config still points at the old server. Fix it per CMS.

WordPress — edit wp-config.php:

define('DB_NAME', 'client_user_dbname');
define('DB_USER', 'client_user_dbuser');
define('DB_PASSWORD', 'new-cpanel-password');

If the URL changed, update siteurl and home in wp_options via phpMyAdmin, or force them in wp-config.php:

define('WP_HOME', 'https://site-lama-client.com');
define('WP_SITEURL', 'https://site-lama-client.com');

Laravel — edit the .env file:

DB_DATABASE=client_user_dbname
DB_USERNAME=client_user_dbuser
DB_PASSWORD=new-password

Then run migrations and fix storage permissions so uploads don’t break. For other CMSs, find the database config file and fix the same three values.

Don’t forget to check the .htaccess or any Nginx config that came along — rewrite rules might reference old paths. And set the PHP version in cPanel (“MultiPHP Manager”) to match the old server. PHP version mismatch is one of the most common causes of blank pages after a migration.

Step 8: Point DNS and Cut Over

Before the cutover, test the site from the new server without touching DNS. Edit /etc/hosts on your laptop (or a temporary box):

203.0.113.20 site-lama-client.com www.site-lama-client.com

Replace 203.0.113.20 with the new cPanel server’s IP. Then open the browser or check with curl:

curl -sI http://site-lama-client.com | head -10

If it responds and the HTML comes back, it’s cutover time. Drop the DNS TTL to something small (say 300 seconds) a day before, so the change spreads fast. Then repoint the A records for site-lama-client.com (and www) to the cPanel IP. Wait for propagation and test from a few different networks.

Once everything checks out, don’t wipe the old server right away. Leave it for a few days until DNS propagation is done and everyone’s happy. Clean up after that.

Step 9: Final Verification Before Handover

Before you close the ticket, run through this checklist:

• Site loads normally via the real domain (not just /etc/hosts).
• Key pages work: homepage, product pages, contact, form submissions.
• Images and static files load (quick test: fetch a couple of image URLs).
• Admin/CMS login works and can save data.
• HTTPS/SSL is active — install via AutoSSL in WHM or manually in cPanel.
• Domain email works if it moved too.
• Cron jobs from the old server are recreated in cPanel (“Cron Jobs”) — this one gets forgotten constantly.

All green? The migration is done. Oh, one more that slips through: check the PHP version and extensions the CMS needs (mysqli, gd, mbstring, etc.). Missing one and your site breaks in the weirdest ways.

Troubleshooting: Common Errors After Migration

Field Notes and Pro Tips

• Always write down the old config before changing anything. It takes five minutes and saves hours.
• If you can, test on staging before flipping DNS. Don’t make production the test environment.
• For transfers over the public internet, use rsync over SSH. And use safe access — don’t paste passwords into public chats.
• Name the cPanel database clearly and store the password in a password manager, not a sticky note.
• If the old server also handles email, don’t shut it down until every mailbox is confirmed moved.
• Match the PHP version exactly if the app is old and sensitive. PHP upgrades can wait for a later phase.

FAQ

Related Reading

• Complete guide to zero-downtime VPS KVM migration
• Troubleshooting MySQL crashes on small-RAM VPS
• How to troubleshoot high load on a cPanel server
• How to check SSL certificates before they expire

Closing Thoughts

So that’s my story from back then. It felt terrifying at first, but once you know the method, migrating from a non-panel Ubuntu server to cPanel is really just: find the goods (document root and database), wrap them up neatly, move them, and reassemble in the new place. The one key ingredient is preparation. Never rush into execution until you’re sure everything is found and backed up.

If you’re in the same spot I was, I hope this guide saves you. And if you hit a case that isn’t covered here, drop it in the comments — you never know which night-shift engineer it might help next.