How to move from cPanel to a new server without downtime

Where the downtime comes from

Copying a site does not take it offline. The old server keeps answering while the files and databases are read. Downtime comes from two other places.

The first is the gap between the moment the data was copied and the moment DNS moves. An order placed on the old server in that gap is not on the new one. The second is DNS itself: resolvers keep the old address for as long as the record's TTL allows.

So the plan is always the same. Copy while the old server serves, look at the copy before anybody else can, shorten the TTL in advance, and make the final step as small as possible. In KLYRN that is four steps: analyse, copy, verify, cut over.

1. Analyse: get a plan before anything is written

With root on the cPanel server, one command packages an account with cPanel's own pkgacct, streams it across and turns it into a plan:

klyrn import ssh --host old.example.com --user root --account acmeuser
klyrn import list
klyrn import show 1

show lists every domain, database, database user and cron entry, with conflicts and with anything that will not come across. Nothing exists on the new server yet. The plan is a document.

The archive route has one limit you should know before choosing it: it has no second pass. Everything written on the old server after the archive was made is missing from it. For a brochure site that is fine. For a shop it is not, and there is another route for that.

klyrn import ssh --host old.example.com --user acmeuser --key ~/.ssh/id_ed25519 --mode files --domain example.com --path public_html

This reads the document root and its databases directly. Database credentials are found in wp-config.php or .env, so a WordPress site usually needs nothing typed. It copies in two passes, which is what makes a short cut-over possible.

2. Copy while the old server keeps serving

klyrn import apply 1
klyrn import state 1

On the two-pass route this is the pre-copy. Nobody is waiting on it, and when it finishes the site is live on the new server with nothing pointing at it. state prints every phase with its duration, bytes and file counts.

The source is never suspended or deleted. KLYRN runs the tools the old server already has and installs nothing on it.

3. Verify before DNS moves

The migrated site gets a verification report in the panel: eleven checks on the new server, each passed, warning or action required, each with its evidence. The report also hands you the lines to see the copy yourself while the public still sees the old server:

curl -sS -I --resolve example.com:443:203.0.113.10 https://example.com/

The report does not connect to the old server and cannot tell you the two pages look the same. That comparison is yours, and it is the step worth doing: a blank page returns HTTP 200.

4. Cut over

1. Lower the TTL at your DNS provider hours before, not at the cut-over.
2. Settle mail first. KLYRN never changes an MX record. Leave MX on the old server, or bring the mail across and move MX yourself once it is checked.
3. Take the final sync on the two-pass route. Its wall time is the only downtime. A WordPress source can be put into maintenance for exactly that long.
4. Change the records. The import result ends with the exact records to set.
5. Let the certificate arrive. Ask for it, or wait: the scheduler retries every ten minutes once the name resolves to the new server.

klyrn import sync 1 --freeze
klyrn dns point example.com
klyrn site ssl example.com

klyrn dns point writes the records when the DNS provider is connected to the panel. Otherwise change them by hand.

If it goes wrong

Point DNS back. The old server has every file, database and mailbox it had before, because nothing on it was changed. Keep it running for a week after the cut-over, longer if it still answers for mail.

The cPanel guide is blunt about what has and has not been tested against real cPanel servers. Read that section before you plan a move around it.