Migration

TNS Panel migrates server to server. You install it on a clean new server and import from the old panel, which keeps serving customers meanwhile. You verify each account on the new server, then cut over by changing DNS. If something is wrong you point DNS back to the old server; nothing was changed there.

Migration is in Migration in the admin interface and in the panel migra-* commands. It is admin-only.

Ways to migrate

Supported source panels

1. Look before touching anything

panel migra-inventario -host old.example.com -panel cwp -usuario root

The command reads the old server and lists its accounts, sites, databases, mailboxes, aliases and FTP accounts. It writes nothing, there or here. The first contact does not guess: it shows the old server's SSH fingerprint and refuses to continue until you re-run with -huella SHA256:... after comparing it with the real one (shown on the old server with ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub). There is no way to skip this check.

Everything read from the old server is treated as untrusted input. An account whose home is /, /etc or /root is discarded and reported. The inventory states what it could not read (for example credentials), so "zero" is never presented as "none".

Over SSH no password hashes are copied. Mailboxes and FTP accounts are recreated and their owners set new passwords. Hashes only travel through backup files, where you already hold the package. Password hashes that need a method this panel does not support (for example MD5) are not imported.

2. Import an account

# from the old server
panel migra-cuenta -host old.example.com -panel cwp -cuenta acme [-renombrar acme2]

# from the old panel's backup file (place it somewhere other than /tmp, for example /root/backups/)
panel migra-archivo -archivo /root/backups/acme.tar.gz

What it does: creates the client, assigns the reseller and plan when the source panel states them, creates sites and aliases, copies the home directory, creates databases and users, and loads database dumps when the backup contains them (cPanel and CWP Pro archives; the others report that the database contents must be loaded another way). Dumps are imported with a temporary limited identity, never with administrative rights, because an imported dump is arbitrary SQL. If a prior attempt stopped half-way, add -continuar; add -sin-archivos to build only the structure.

Mail:

• If the backup carries the mailboxes, they are recreated with their password hashes.
• Before creating any mail domain, the panel asks the real DNS where that domain's mail lives. If the MX points outside this server (Google Workspace, Microsoft 365, another provider), it does not create local mailboxes: doing so would make this node treat that domain as local and deliver other tenants' mail to empty local mailboxes instead of sending it out. The report states the real MX and how many mailboxes were left out. If the answer cannot be determined it is treated as "not safe".
• To copy existing messages over IMAP (including a second pass just before cutting over, which only fetches what arrived since the first), use the mailbox import in Email. The destination mailbox must be new and empty.

Names that this panel serves itself (such as webmail. and autoconfig.) and artifacts of the old server (ipv6. names, temporary hosting domains) are not carried over, and the report lists them.

3. Verify before you cut DNS

panel migra-verificar -host old.example.com -panel cwp -cuenta acme -destino acme

or Migration → Verify. Read-only on both sides. For each account it checks, against the old inventory:

• every site responds on this node (it requests the page with the right Host header, because DNS still points to the old server);
• every database exists and has the same number of tables (a half-loaded dump has the right name but too few tables);
• mailboxes and aliases are present.

Each item has three outcomes: OK, missing, or could not be verified (for example a timeout). A network problem is never reported as "missing" or "fine". Extra items that exist here but not there are listed too.

Migration → Discover shows where a domain's DNS really lives (name servers and who runs them, MX, SPF/DMARC, registrar where available), asked of a public resolver and not of this node, so you know whether to move the zone here or only change records elsewhere.

4. Cut over

1. Make sure the final IMAP pass is done and any database written to since is re-synced.
2. Change the nameservers at the registrar (or the A/MX records if the DNS is elsewhere).
3. Keep the old server running until traffic has moved.
4. To go back, point DNS at the old server again.

Migrating from a single account (no server access)

Migration → Account brings one customer in using only what the customer can give you:

The report says that there is no plan, reseller or quota information because there is no server to read it from. Use this for Ferozo and any hosting you cannot log in to as an administrator.

Importing a CSF firewall configuration

Security → Firewall → Import CSF reads csf.conf and the allow and deny lists, so your existing firewall rules come with you.

After the migration

• Reissue certificates by visiting each site's certificate page, or wait for the scheduler; the domain must point to this node first.
• Review the report's "pending" list. It lists passwords to reset, databases without a dump, names that were changed, and anything left out. This list is the part to read before cutting DNS.