Skip to main content
A move puts a site on another machine and leaves the old one exactly where it is. It is the Move tab on the site, next to Copy, and the difference between the two is the whole reason they sit together: a copy leaves the original serving, a move takes the site off one machine and puts it on the other. Moving a site needs the same permission as deleting one. Somebody who can deploy and edit a site can read the Move tab and cannot press anything on it.

​
What actually happens

The order is chosen so the site is serving for as much of it as possible.
1

Check both machines

The destination has to be another machine in the same organization, one that serves sites, and one in a state to accept work. A machine that is none of those is not offered.
2

Build the site on the destination

A second site is made on the far machine — its own row, its own vhost, its own database. Both exist at once for the whole of the move, and that is what makes the cutover reversible.
3

Copy the files across

While the site carries on serving. Nothing about it has changed yet, and abandoning the move at this point costs nothing but the disk on the far machine.
4

Hold the source down

The freeze. This is the outage, and the only one.
5

Copy what changed, and the database

A second pass over the files for anything written since the first, and then the database. The length of this step is the length of the outage.
6

Point the source at the destination

The cutover. The old machine stops serving the site and starts passing every request to the new one.
7

Move the name, where Shipways holds it

Only for a free subdomain in this installation’s own zone. A domain you own is yours to move, and there is no hurry — see below.
The data goes directly between the two machines when they can reach each other privately, and through Shipways when they cannot. The panel says which, because the two fail differently: the direct path is bounded by the disks, and the fallback is bounded by memory and refuses rather than falling over when a site is too big for it.
The site stays up until the database is copied. Everything before the freeze happens with the site serving normally. That is why the panel asks you to confirm the outage before it starts — the tick is about those two steps, not about the whole move.

​
The cutover, and why there is no rush after it

Once the flip has happened the old machine is a proxy: it takes every request for the site and passes it to the new machine. Visitors reach the same application either way, so there is no deadline and no moment anybody has to be awake for. That period exists for DNS. Point your name at the new machine whenever it suits you, wait as long as your records say to wait, and the site behaves identically throughout. A resolver somewhere that never expires anything is somebody else’s problem rather than yours, because the old address still works. The move sits at this point until you pick one of the two endings. Nothing advances on its own.

​
Finishing

Finishing is what makes the destination the site. It hands over the things only one of the two sites may hold — the webhook, its secret, the deploy hook, the deploy key registration, auto-deploy, and the free subdomain — and takes the proxy down. The registrations are moved rather than recreated, so the webhook you set up at your provider years ago goes on working: a new one would mean a new URL and a trip to their settings page, which is what this avoids.
Finishing deletes nothing. The old site, its files and its database stay on the old machine, still answering for anybody who asks it directly. Removing them is a separate decision, made from that site’s own settings, and it is worth leaving for a few days rather than doing the same afternoon.
That is deliberate. Every other step in a move is reversible or repeatable; deleting the source is neither, and automating it would mean picking a signal — no requests for an hour, a health check, a timer — that is wrong in some perfectly ordinary case. The cost of waiting is some disk. The cost of being wrong is a customer’s data.

​
Rolling back

Rolling back puts the site back on the machine it came from. Before the cutover this costs nothing. After it, it costs the writes. The destination has been taking them for however long the proxy has been up, and going back means the old machine starts serving its own database again — the one frozen at the cutover. Every order, signup and upload since then stays on the new machine and is not brought back. The panel asks you to type the site’s domain before it will do it, and says so in the same words. It exists because the alternative is worse. Discovering an hour in that the destination is wrong — the wrong PHP version, a firewall nobody opened, a machine that turns out to be too small — should be one press to get back, not a second migration in the other direction. The old machine is still sitting there intact, because nothing deleted it. The stranded data is not deleted either. It stays on the destination for you to go and get; the site simply stops using it.

​
A move that stops part-way

Pressing start again on a move that failed carries that one on. It does not begin a second move beside it, and it goes back to the machine the first one was going to. Steps that already finished are skipped. A site can only be in one move at a time, which is what stops two machines each being told they are where the site now lives. To move somewhere else instead, roll the stopped move back first. If the run failed after the freeze, the hold is lifted — a failed move never leaves a site showing a holding page nobody chose.