Migration

One guide per source

Every source ends with a plan you read, a site you look at before DNS moves, and a verification you can paste into a ticket. Start with the guide for the machine you are leaving.

DirectAdmin

The live server is read over SSH with one command, planned per domain, and moved with a pre-copy and a final delta. A DirectAdmin user backup archive also works. Migrating from DirectAdmin.

cPanel/WHM

Packaged on the source by pkgacct as root, or by cPanel's own API as the account itself, or an archive you already have. A nested homedir.tar is handled. Migrating from cPanel and WHM.

A Linux server over SSH

No panel at all: a document root and its databases, pre-copied while the site stays live. wp-config.php and .env are read for credentials. Migrating a Linux server over SSH.

Another KLYRN server

The Move. The source mints a read-only grant for one account, and the destination pulls over the pinned panel port. The configuration travels with it. Moving between two KLYRN servers.

An archive is inspected, extracted and parsed, then applied in one pass. A site reached over SSH is measured in place and copied in two passes into the site it will live in. The plan looks the same either way. Each guide says where the downtime is.

From an archive

klyrn import cpanel /root/backup-acme.tar.gz
klyrn import directadmin /root/user.acme.tar.gz
klyrn import archive /root/backup.tar.gz      # detect the kind

klyrn import list
klyrn import show 1        # what was found and what will be created
klyrn import apply 1
klyrn import delete 1

show lists the domains, the databases, the cron entries, the PHP version the source used and anything KLYRN cannot carry across. Nothing exists on the server until apply.

klyrn import apply 1 --account acme
klyrn import apply 1 --domains example.com,shop.example.com
klyrn import apply 1 --databases acme_wp
klyrn import apply 1 --no-cron --no-ssl

In the panel the archive is uploaded with a progress bar, the plan is reviewed on screen, and the results end with the DNS cut-over list.

Over SSH from a live server

# A live cPanel server, with root on the source
klyrn import ssh --host old.example.com --user root --account acmeuser

# A cPanel account, without root on the source
klyrn import ssh --host old.example.com --user acmeuser --password '…'

# Any server at all: a document root and its databases
klyrn import ssh --host old.example.com --user deploy --key ~/.ssh/id_ed25519 \
  --mode files --domain example.com --path public_html \
  --db acme_wp:acme_wp:secret

Authentication is a password or a private key file. Encrypted private keys are not supported yet.

--fingerprint SHA256: pins the source's host key. The key is compared during the handshake, and a mismatch is refused before the password is offered, naming both fingerprints. What each refusal means.

Without --fingerprint, the key a host answers with the first time is recorded, and every later connection must present the same key. A changed key is refused with both fingerprints side by side. Recording is not approval. A key counts as checked only once a person approves it in Migrate.

--db is repeatable and takes name:user:password[@host[:port]]. In files mode KLYRN also reads wp-config.php and .env under the document root, so a WordPress site usually needs no --db at all.

.htaccess and what does not come across

nginx does not read .htaccess. KLYRN reads it, translates the rules it understands into the site's nginx configuration, and shows you the translation before applying it. Rules it cannot translate are listed.

• Mail is copied only from cPanel, DirectAdmin and Plesk. Mailboxes come across from all three and forwarders from cPanel and DirectAdmin. KLYRN never changes the MX records for you.
• DNS zones are copied only when this server is the nameserver. Otherwise the cut-over list at the end says exactly which records to change.
• Anything the source refuses to give up. A missing document root, or one that is the home directory itself, is reported and never guessed at.
• Apache-specific behaviour beyond the rules KLYRN can translate. It is listed, so you can decide.

Previewing before DNS moves

The imported site is live on the new server the moment apply finishes, and nothing points at it yet. The preview asks the new server's own nginx for the site by name, as a visitor will once DNS points here. It covers the primary, www if the site serves it, and every alias and redirect. Redirects are not followed, so you see where each name sends people.

The report also gives you the lines to do the same from your own machine, with your names and address filled in:

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

The preview is a request to the new server. It does not fetch the old one and cannot tell you the two pages look the same. Compare them yourself: a blank page returns HTTP 200.

Verifying and cutting over

After an import, and before any DNS changes, KLYRN produces a verification report on the new server. It has eleven checks. Each is passed, warning or action required, and each carries its evidence. The report includes curl --resolve and hosts-file lines for looking at the imported site while the old server still serves the public.

The report checks the new server only. It does not connect to the source and cannot tell you the two pages render the same. Comparing them is yours to do. What each check proves, and what “verified” does not mean.

1. Import and applyThe sites, databases and cron entries exist on the new server, but nothing points at it yet.
2. VerifyCompare against the source. Fix what differs.
3. Lower the TTL at your DNS providerDo it hours before the cut-over.
4. Change the recordsThe cut-over list names them. If Cloudflare holds the zone, klyrn dns point writes them.
5. Issue certificatesklyrn site ssl <domain>, or wait: the scheduler retries every ten minutes.
6. Keep the old server for a weekLong enough for every cached record to expire and for anything you missed to surface.

Full walk-through with screenshots: Migrating to KLYRN.