Migrating a WordPress Site to a New Dedicated Server Without Downtime (What Actually Worked)

Why this migration was overdue

The old server had served UniApplyForMe well for years. But with traffic growing and the platform expanding — more tools, more users, more concurrent requests during peak application season — it was time to move to something more capable. The new machine: 64GB RAM, dual 960GB NVMe drives in RAID1. A meaningful upgrade.

The stack on both ends

Both servers run cPanel on AlmaLinux with LiteSpeed as the web server. That made the migration more straightforward than it would have been across different stacks — the file structures, config paths, and database handling are consistent. If you’re ever choosing a server stack for a WordPress hosting environment and you want migrations to be sane, consistency matters more than you’d think.

The actual process

I used cPanel’s built-in Transfer Tool for the bulk of the account migration. It handles files, databases, email accounts, DNS zones, and SSL certificates in one pass. It’s not perfect — there are always edge cases — but it gets you 90% of the way there without manual rsync commands.

The critical part: do not change DNS until the new server is fully verified. I ran the new server in parallel for 48 hours, accessing it via the IP directly and through a hosts file edit locally, confirming every subsite, form, API endpoint, and cron job was working before touching a single DNS record.

What actually went wrong

Two things. First: WP_DEBUG logs on the new server surfaced a few plugin conflicts that weren’t visible on the old one — different PHP minor version. Fixed by updating the offending plugins and adjusting the PHP handler in cPanel.

Second: the LiteSpeed cache had to be fully cleared and reconfigured on the new server. Carrying over the old cache config caused intermittent 503 errors on certain pages. The fix was straightforward once identified, but it took longer to diagnose than it should have because the errors weren’t consistent.

The DNS cutover

I lowered the TTL to 300 seconds 24 hours before the planned cutover. When everything was confirmed working, I updated the A records and waited. Total downtime: zero. The overlap period meant some traffic hit the old server for a few minutes while DNS propagated globally, but both servers were serving the same content so users never saw anything broken.

Lessons

Run parallel for longer than you think you need to. Check your WP_DEBUG logs on the new environment before going live — don’t assume a clean transfer means a clean install. And lower your TTL early. These are obvious in hindsight but easy to skip when you’re in a hurry.