What Happens to Your Licenses When You Move Servers

The license lives on an IP, not on disk

Migration plans are usually written around data: rsync, database dumps, DNS. Licenses sit at the bottom of the list in the "we'll sort it out" box. Then, on cutover night, WHM throws a license error, LiteSpeed refuses to start, yum can't reach the CloudLinux repos, and a one-hour job stretches across the whole night.

The reason fits in one sentence: nearly every hosting license binds to the server's IP address, not to a file on the machine. Files like /usr/local/cpanel/cpanel.lisc are just caches — time-limited copies pulled down from a licensing server. The record that matters is a row somewhere saying "this product is licensed for this IP", and that row is not on your disk.

Three practical consequences follow:

• There is nothing to back up. Copying the license file to the new box does nothing; it won't match the new IP and gets discarded on the first check.
• One license is valid on exactly one IP at a time. There is no moment when both the old and the new server are licensed. Your migration's real downtime window comes from this, not from network speed.
• The moment you change the IP, the old address drops off the record. In the panel this is instant, there is no approval step, and the new address is usually live within a minute.

The old server doesn't die at once — it rots quietly

What is instant is the license *record*. How quickly the software on the old machine notices varies wildly by product, and most of the nastiest migration surprises come out of that gap.

• cPanel/WHM: the cached license file stays valid until it expires. The next cpkeyclt run fails and WHM and cPanel lock you out — but Apache or LiteSpeed keeps serving sites and Exim keeps accepting mail for a while longer. This is where "the sites load, so we're fine" comes from.
• LiteSpeed: the running process stays up. The failure shows up on the first restart or graceful reload, when the license can't be validated and the web server won't come back. Whoever edits a vhost three days after the move gets the surprise.
• CloudLinux: the system keeps running, but the CLN repositories close. Nothing looks wrong until yum update errors out.
• KernelCare, Imunify360, cxs, CPGuard: the agent falls back to unregistered and stops pulling patches and signatures. For security products that's the worst failure mode — it looks alive and protects nothing.

One rule comes out of all this: do not restart anything on the old server after the move. Leave it completely alone until traffic has drained.

Which products install without a license, and which don't

This is the question that actually determines your ordering.

Install first, move the IP later

Here the installation completes with no license at all. The product sits in an unlicensed state and snaps into place with one command once the IP has moved — so you can build the entire new server and leave licensing to the very end.

• cPanel & WHM — installs unlicensed, then /usr/local/cpanel/cpkeyclt once the IP has moved
• Plesk — installs unlicensed; the key is applied with plesk bin license -i KEY and re-pulled with plesk bin license --retrieve
• JetBackup, Softaculous, SitePad, WP Toolkit — install fine, activate afterwards, and revalidate on their own schedule

Products that block until the IP has moved

• CloudLinux: the cldeploy conversion validates the license during installation, and the box has to be rebooted afterwards before you are running the LVE-enabled kernel. That means the CloudLinux license has to be pointing at the new IP beforehand. Conversion plus reboot drags the work to the *front* of your window — treating it as a final step is a classic planning mistake.
• Imunify360: the agent installs, but nothing activates until imunify360-agent register IPL runs, and that command needs the IP on record.
• LiteSpeed: the package installs, but lshttpd will not start against a license bound to a different IP. In practice you cannot test the new server's web stack with real traffic beforehand.

DirectAdmin is its own case

On current DirectAdmin builds (1.63.8 and later) the license is a plain-text key file: /usr/local/directadmin/conf/license.key. Write the key there and run systemctl restart directadmin. Even so, the same key cannot hold a session on two servers at once, and if the license has IP restrictions the service won't run until the new address is on the record. So it is still an ordered step, not a file copy.

The two groups pull in opposite directions. If a box runs both CloudLinux and cPanel, the order is: move the CloudLinux license, convert, reboot, then move the cPanel license and run cpkeyclt.

Three ways to deal with the unavoidable gap

Since a license can't sit on two IPs at once, there is always a window. You have three options.

• Move the server, not the IP. If you are staying with the same provider, many platforms let you detach an address from the old machine and attach it to the new one (floating IPs, IP failover). Do that and the license never moves at all — downtime is just the reroute. When it's possible this is by far the best answer, and nobody tends to mention it.
• Accept the window. With data pre-synced, TTLs already low and the refresh commands ready to paste, real downtime is measured in minutes. For most shared hosting boxes that is entirely acceptable.
• Run a second license through the transition. For products you cannot test unlicensed — LiteSpeed, CloudLinux — this is the only genuine zero-downtime path: open a separate monthly license for the new server, test the migration without a stopwatch running, and drop the old one when you're done. Monthly licenses run to the end of the period, with no commitment and no cancellation fee. The cost is one month; what you buy is the ability to roll back.

Sequencing against DNS

The general rule: the license moves before DNS, and DNS moves only after the license is verified. Never flip a record while the new server is still unlicensed and untested.

• Drop TTLs to 300 seconds 48 hours ahead. Not just the apex A record: www, the server hostname, whatever the MX points at, and the mail, webmail and cpanel subdomains.
• If you run your own nameservers, remember glue records. They aren't governed by your TTLs but by propagation on the parent zone's side, and can take hours. If a nameserver IP is changing, start a week early.
• Test the new server before touching DNS by adding 203.0.113.20 example.com www.example.com to your workstation's /etc/hosts and browsing the real hostname. SSL, redirects, database connectivity — all of it becomes visible without a public change.
• After the flip, the old server keeps taking traffic for the length of the TTL. It is unlicensed but functional. Just don't restart it.
• Treat mail separately. Some sending servers cache MX answers far longer than they should; leave Exim running on the old box for at least 48 hours and do a final mail sync before you shut it down.

A cutover checklist

T-7 days

• inventory the licenses: product, current IP, renewal date
• if a renewal falls near the migration date, renew first — don't stack both jobs on one night
• confirm the new server's primary IP (cat /var/cpanel/mainip on cPanel). On NAT'd providers ip -4 addr shows a private address, while the license binds to the public one

T-2 days

• TTL 300 on every relevant record
• build the OS and install everything that installs unlicensed
• if CloudLinux is in the stack, move its license now and get the conversion and reboot out of the way
• first bulk data sync

T-0, quiet hour

• final sync, stop cron jobs, close new account creation
• change the IP in the license panel — read the address twice, because a typo leaves *both* servers unlicensed
• run each product's refresh command and actually read the output
• verify sites and panels through the hosts file
• flip DNS

T+7 days

• keep the old server's data for a week before destroying it
• before powering the box off, check one last time that the license record shows the new IP

Refresh commands

• cPanel: /usr/local/cpanel/cpkeyclt
• CloudLinux (IP-based license): /usr/sbin/clnreg_ks --force
• KernelCare: kcarectl --update
• Imunify360: imunify360-agent register IPL, then imunify360-agent rstatus
• LiteSpeed: /usr/local/lsws/bin/lshttpd -r, then /usr/local/lsws/bin/lshttpd -V to verify
• Plesk: plesk bin license --retrieve
• DirectAdmin: write the key to /usr/local/directadmin/conf/license.key, then systemctl restart directadmin

When one of these fails, check first whether the IP on the license record matches the server's actual outbound address. Second suspect: the firewall. Validation doesn't always run over 80/443 — cPanel's license check needs outbound 2089/TCP, and a freshly built server rarely has the same permissive egress rules as the one you're leaving.

WHMCS is its own problem

WHMCS doesn't only look at the IP — it also binds to the domain and the directory it's installed in. Copying the files across is not enough; the license record has to be reissued. The license line in configuration.php stays the same; what changes is the record. Seeing a license warning on the first page load after a move is normal — fix the record and reload. If you're changing the domain too, plan that as a separate step rather than squeezing it into the same night.

If you migrate often, use the API

For a hosting company, moving servers isn't an annual event, it's routine work. Because the IP change is available over REST, it can simply be the last step of your migration script: final rsync completes, the script calls the license API to move the IP, runs the refresh command on the new box, and logs the result. The same API covers creation, renewal and suspension, so wiring it into WHMCS or your own panel collapses new-server provisioning into a single job. If you resell under your own brand, those endpoints are open to your sub-resellers too — details on the reseller page.

The hard part of a migration is not the data. It's the order.

Three sentences to take away: don't change the license IP before the new server is standing, don't flip DNS before the license validates, and don't restart anything on the old server. You make the IP change yourself from the panel — no ticket, no waiting for approval — which means the timing of the cutover is entirely yours to pick.