Move customers to another Dashmox server

This is how you move customers to another Dashmox server, such as a bigger machine, a different region, or a second server as you grow. Leaving a different control panel is a separate job with its own guide: moving a website over SSH. Here both ends are Dashmox, which is what makes the handover safe to automate.

Use Issue a pairing code, tick the customers it covers, and confirm with your password. The panel asks again, because this grants another machine the right to read those accounts. Then copy the pairing code now: like any other secret here, it is shown once.

Customers    Jo Smith, Acme Ltd, Riverside Cafe
Valid for    4 hours

Code (shown once, copy it now):
  dmx1.AbCd3F...

The code is narrow by design, in three separate ways. It reaches the customers you named and nobody else. It works once. And it only works against a server that finds this one presenting its own certificate, so a code intercepted on its way somewhere else reaches nothing.

On the receiving end, bringing accounts across is bounded too: at most 200 accounts in one run. A larger move is several runs, which is also easier to check as you go.

Paste the code on the new server and it fetches a manifest describing what would come across. The preview changes nothing, and it says what would stop the move, such as a domain already in use or something the new server cannot accommodate, before you have committed to anything.

The manifest describes and carries nothing that signs in anywhere: no passwords, no keys, no session. It is a description of work to be done, not the work itself.

Starting the move records a migration per website and copies each one: the website is made, its files arrive and are swapped into place the way a restored backup is, each database is made and loaded, and the settings that live on the machine are applied. Both servers then take an inventory and compare them, so "it finished" means the two ends agree rather than that no error was printed.

An account that served several names is read for what each one was served from, and each is treated as what it was: a name sharing the main folder becomes another name for the website, a name served from a folder inside it becomes a subdomain of it, and a name served from somewhere else entirely is a separate website. The last of those is listed in the migration's log and left where it is, because its files are not in the website you are bringing across.

The switch-over is a separate step and it asks for a fresh pairing code from the old server. That is not an oversight: the authority to repoint a customer's records is granted at the moment it is used, not borrowed from a code issued earlier in the day.

Lower the record lifetimes first and the switch is a short read-only window, measured and shown to you beforehand rather than discovered afterwards. It can also be undone, which is the other reason the traffic moves separately from the data.

Where Dashmox holds the domain's DNS it knows which address the records should point at, and it changes them itself. Where the DNS is at a registrar or at Cloudflare, which is the ordinary installation, it does not know and it asks: give the address this server answers on, which is the address you are about to put into the records yourself.

It is used for that switch and not stored. A saved one could go stale and send a customer's records at a server their website had since left, and the address is one you already know because you are about to type it somewhere else anyway.

The preview lists the exact records to change and what to point each one at, so you can read them before starting. Give it the address there and it fills them in. The old server goes on serving by proxying here until the records take, and the MX records are deliberately left alone: mail moves last, with one final copy.

All guides