# Moving an Account to Another Server

> Rebuild an account on another CorePanel server from its backup, through a shared destination or an uploaded archive, and what happens to its DNS and certificates.

Source: https://www.corepanel.net/docs/backups/moving/
Last updated: 2026-10-02
Part of the CorePanel documentation — https://www.corepanel.net/docs

---

The archive is self-contained, so rebuilding an account elsewhere is just a
[restore](https://www.corepanel.net/docs/backups/restoring) on the other machine. The account's uid/gid, home path
and limits come from the archive, and its hosting package is re-mapped by name if the ID
differs on the target. What is left to decide is how the archive gets there.
(Coming from cPanel rather than CorePanel? See [Transferring accounts](https://www.corepanel.net/docs/backups/transfers).)

![A diagram of an account moving between two CorePanel servers. On the old server, srv1.example, the account acme.example and its backup archive. The archive reaches the new server, srv2.example, by one of two routes: pushed to a shared destination (an S3 bucket or SFTP host added on both servers) and restored from there, or downloaded to your computer and uploaded through Import / Export. On the new server the restore — dry run first, then for real — recreates acme.example with the same uid/gid and home. Below, what the new server does on its own: it regenerates the DNS zone and rewrites the old address in the account's own records, issues its own certificates once DNS points to it while uploaded certificates travel in the archive, and matches the hosting package by name; the delegation is not automatic](https://www.corepanel.net/_astro/backup-move-servers.BEWL9fQT.svg)

## 1 · Through a shared destination

If both servers can reach the same [destination](https://www.corepanel.net/docs/backups/destinations), nothing has
to be copied by hand. Take the backup on the old server with **Copy to** pointing at it,
add the same destination on the new server, list what is stored there, and restore the
archive you want:

```bash
corepanel backup-destination add offsite --type s3 --endpoint ... --bucket ...
corepanel backup-destination archives offsite
corepanel account restore --dest offsite --remote-key cpbackup-pxdemo-20260802T031500Z-j42.tar --dry-run --wait
corepanel account restore --dest offsite --remote-key cpbackup-pxdemo-20260802T031500Z-j42.tar --wait
```

Restoring from a destination works on every edition, so the new server does not need Pro
or Business just to read the archive — only the old one needed it to push.

## 2 · Through your computer

Otherwise, **Download archive** from the backup's menu on the old server, and
[upload it](https://www.corepanel.net/docs/backups/uploading) on the new one: it appears on the **Import / Export**
tab, with **Restore from this backup** in its menu. Or skip the
browser: copy the `.tar` across yourself (`scp`, `rsync`) and restore it from its path
with the CLI.

Either way, run the restore as a **dry run** first: a domain that already exists on the
new server is the collision you want to find before, not during.

## After the restore

The DNS zone is **regenerated by the new server**, so its records point at the new machine
rather than the old one, and the records the account added are merged back in — with the
old server's address rewritten to the new one's. What is not automatic is the delegation:
the domain keeps resolving to the old server until its nameservers or records are changed.

Certificates the old server issued itself are not carried; the new server issues its own
once the domain's DNS points at it. Uploaded certificates travel with the archive.

Until the delegation changes, both servers hold a copy of the account and the old one is
still the one receiving mail and visitors. Anything written there after the backup — new
mail, new orders, a changed file — is not on the new server. Change the DNS soon after the
restore, and suspend or delete the old account only once the new one is the one answering.