Running a live migration

Moving a customer off a running server onto CoreCP without the site being down for hours. This is the guided version: one wizard that puts the steps in the order somebody actually does them, may run for days, and survives you closing the la

Written for: Administrator

The wizard is in the panel under Migration → Live migrations, and the same steps are commands on the node. It is one record: what you start in the browser you can finish on the server, and the other way round.

The nine phases

Phase	What happens
Connect	credentials per service (SSH, FTP, MySQL, IMAP), and a test that says what does and does not work
Discover	the source is read: sites, databases, mailboxes, zones
Plan	what goes where, plus a dry run of the real transfer commands
Approve	a person approves the plan; only then may data move
Sync	the first pass, and as many deltas as the week needs
Verify	HTTP comparison, mailbox counts, row counts, zone completeness
Ready for cutover	the green signal: plan approved and every check green
Cutover	you (or the customer) move the nameservers or A records — CoreCP does not
Finalise	final delta under a short freeze, certificates, and advice about the old machine

The phase is derived from the record and stored nowhere. If a colleague runs a delta from the command line while you are watching the browser, there is no second copy of "where are we" to go stale.

Getting started

In the panel: Migration → Live migrations → New migration. You fill in the details per service — one tab per service — and press test. What does not work may be missing: without SSH the wizard runs in "degraded" mode over FTP, IMAP and MySQL-over-TCP, and the report says which route it used.

From the node that is:

ssh root@stck1.corecp.dev
corectl migrate source add web1 --keep-for-delta --retain-days 30 < creds.json
corectl migrate source test lm-1786… --install-key

--install-key sets up a key pair that exists for this migration only; that is the preferred path over passing a password around.

Discover, plan, approve

corectl migrate discover lm-1786…   # read the source
corectl migrate plan     lm-1786…   # plan + dry run
corectl migrate approve  lm-1786…   # a person approves

The dry run is not an estimate: it is the transfer engines themselves with their own --dry-run. What you read is what will happen. Approval is a step of its own because it is the one place where somebody can say "that is wrong" before any data moves.

Sync

corectl migrate sync lm-1786… --pass initial
corectl migrate sync lm-1786… --pass delta     # as often as you like

A pass runs the plan's items in parallel, throttled — three at a time — because the source is a live server still serving its own customers. Each item is its own step with its own log, shown in the panel in a slide-over.

Everything is resumable. A step left "running" by a reboot is honestly labelled partial — interrupted, run the pass again to resume after six hours.

Verify, and the green signal

corectl migrate checklist lm-1786…
corectl migrate status    lm-1786…

[corecp] live migration lm-1786… → web1 (ready)
  discovery:   ssh, directadmin layout — 2 site(s), 1 database(s), 1 mailbox(es), 1 zone(s)
  plan:        5 item(s), approved 2026-08-10 11:02 by admin@corecp.dev
  READY FOR CUTOVER — every check is green.

"Ready for cutover" means exactly two things at once: the plan is approved and every check is green. Every new pass drops the checklist, because a green tick that predates the data it is ticking is the one failure this wizard cannot have. A checklist with no checks in it is not green either.

Cutover and finalise

Move the nameservers or the A records. CoreCP does not do this for you: it is the one step whose consequences the customer carries.

corectl migrate cutover  lm-1786…   # confirm DNS has been switched
corectl migrate finalise lm-1786…   # final delta, certificates, advice

The final round does files with a quick pass, mail with a flag resync, and the databases again under a short freeze. Certificates are requested after that, HTTP-01 per name: before the switch the challenge is still answered by the old server. A name that has not propagated is a warning with the retry command, not a failed migration.

The advice about the old machine is advice. CoreCP does not switch off a server it does not own.

Cleaning up

corectl migrate source forget lm-1786…

This is not optional housekeeping: until it runs, this node holds a working login to a machine the customer is about to stop paying for. corectl migrate expire does it by itself if nobody remembers, and migrate source show says how long that still is.