How to Migrate to a Dedicated Server

Confirm a dedicated server is the right move

Move to a dedicated server when CPU, RAM or disk faults persist for weeks after caching and plugin work, or when isolation and compliance demand a machine of your own. A VPS handles the same contention for less when the workload fits inside it.

• Evidence of a limit: sustained CPU or memory faults in the cPanel graphs for weeks, not one bad afternoon.
• Database working set larger than the RAM a shared or entry VPS plan gives you.
• IO wait that survives a storage upgrade, which points at disk throughput rather than CPU.
• An architecture or compliance rule that needs a machine, a kernel or a firewall you control.

If a VPS removes the contention, buy that first. A dedicated box costs more and asks more of you, and moving twice is more work than sizing once.

Step 1: audit what the site actually uses

Size the new machine from measurements, not from a plan name. Run these on the old account over SSH, or read the same numbers in cPanel.

• du -sh /home/USER and du -sh /home/USER/mail for disk and mailbox size.
• mysql -e "SELECT table_schema, ROUND(SUM(data_length+index_length)/1024/1024) AS mb FROM information_schema.tables GROUP BY table_schema;" for database size.
• php -v and the extension list, so the new box can match them exactly.
• crontab -l for the account, plus system cron entries the site depends on.
• Mailboxes, forwarders, SSL certificates, DNS records and the document root for each domain.

Write the numbers down. The disk figure plus a year of growth decides the new disk, and the database figure decides how much RAM the buffer pool needs.

Step 2: build the new server to match the old stack

Install the same OS family, the same panel and the same PHP version before any data lands. A version mismatch produces a site that loads and then misbehaves in ways that look like a migration bug.

1. Install the panel, set the hostname and secure WHM with its own SSL certificate.
2. Enable the PHP extensions the audit listed, and pin the same PHP version per domain.
3. Set the timezone and locale to match the old server, or scheduled posts and cron will fire at the wrong hour.
4. Open the firewall for 80, 443 and your SSH port, and restrict SSH to known addresses if the team has fixed IPs.
5. Create the accounts and set DNS on the new machine, but do not point the public A record at it yet.

Test the empty shell before copying anything: a fresh PHP info page, a database connection and a mail send. Fixing those now is easier than debugging them under a live cutover.

Step 3: copy files and databases while both servers run

Copy while the old server still answers, then copy again to pick up the delta. Nothing in this step changes DNS, so a mistake costs time rather than visitors.

• Files: rsync -avz --progress /home/USER/public_html/ USER@NEWIP:/home/USER/public_html/ from the old server, then run the same command again.
• Database: mysqldump --single-transaction --routines --triggers DBNAME | gzip > DBNAME.sql.gz, copy it over, then gunzip < DBNAME.sql.gz | mysql DBNAME on the new box.
• Configuration: copy wp-config.php or its equivalent, and edit the host, database name, user and password for the new server.
• Mail: copy the mail directories, or recreate mailboxes and sync them over IMAP if the panel versions differ.

Verify before DNS: compare SELECT COUNT(*) FROM wp_posts; on both servers, load a page through a hosts-file entry that points at the new IP, and check that uploads and forms work.

Step 4: lower the TTL, test, then switch

Lower the TTL on the A and MX records to 300 seconds a day before the cutover. Then test the new server from your own machine before the world sees it.

• Add NEWIP example.com www.example.com to /etc/hosts (or the Windows hosts file) and browse the site.
• Check the panel's SSL certificate covers the domain, and that mixed-content warnings are gone.
• Switch the A record, then the MX records, and update SPF and DKIM if mail moves with the site.
• Confirm with dig +short A example.com from two networks, and remove the hosts-file entry once the public DNS answers with the new IP.

If something breaks, revert the A record. With a 300-second TTL that is a five-minute fix, which is the whole reason for lowering it first.

Step 5: verify the site, mail and cron after the switch

A site that loads is not a migration that worked. Walk this list on the live domain before you cancel anything.

File ownership is the quiet failure behind half of these. If uploads fail, check that the files belong to the account user and not to root after the rsync.

Step 6: keep the old server for a week, then retire it

Leave the old machine running for a week, still accepting mail and still reachable by SSH. Take a final backup on the new server, then cancel the old one in writing.

Plan the IP before you need it. A primary IP address does not follow you to a new machine, so if sending reputation matters, ask for an additional IP and move it rather than inheriting a fresh address with no history.

Reverse DNS is the other detail worth a ticket: the new IP should resolve to your mail hostname before the first campaign goes out, or receivers score the mail lower.

What WebJi® does for a dedicated migration

WebJi® quotes dedicated server work by email before payment, and the starting hardware figure is printed on that page. Send the audit numbers from step 1 and the team sizes the machine to them rather than to a template.

The migration team moves cPanel accounts, databases and mail, subject to terms and approval, and the managed dedicated server option keeps patching, monitoring and backup checks with the provider. Write to support@webji.services with the account list and the window you want; email support answers in Hindi and English 24/7, average first reply under 60 minutes.