Moving Shop Servers Without Losing Orders: A Runbook

A shop is not a static website. It writes constantly: orders, baskets, customer accounts, stock levels, payment states, logs. Every copy of its database is out of date the moment it is finished. When a static site moves, this does not matter - whether a visitor reaches the old or the new machine, they see the same content. With a shop, exactly this question decides which database an order lands in. And as long as both machines are reachable and both accept orders, there are two truths that nobody merges.

The consequences rarely show on moving day itself. They surface days later: as a customer who can produce an order confirmation for which the system holds no order. As a payment the provider considers successful while the order in the new shop still says “open”. As a shipping label printed twice because the export ran on both servers. Anyone who plans the move purely as a DNS task will not see any of these errors coming. The DNS layer itself is covered in the article on DNS maintenance with DNSSEC and registrar lock; this one is about the application on top of it.

The database is the part of the move that loses orders when it is treated as a one-off copy. The robust procedure has three steps. The first dump runs days before the date, during normal operation: it fills the new server, serves as a dry run and measures how long export, transfer and import really take. With this data the new shop is played through - catalogue, search, basket, checkout in test mode, invoicing. Errors from this dry run cost nothing, because no customer sees the new server yet.

On moving day the write freeze follows. From that moment the old shop no longer accepts orders: checkout and customer account show a maintenance page, the catalogue can stay readable if desired. The back office is locked so that nobody changes prices, stock or orders in the background. Then the final sync runs: either a second full dump, if the dry run showed it is fast enough, or the transfer of all changes since the first dump. Which variant fits is decided by the duration measured in the dry run, not by hope. Before the write freeze, a verified backup belongs in place, as the backup service provides - it is the way back if the final sync fails.

Files move along with the database: product images, uploaded documents, generated invoices and delivery notes. They too are transferred twice - once in full with the first dump, once as a difference during the write freeze. Otherwise an invoice generated after the first dump exists only on the old server. The same goes for sessions: if they are kept in files rather than in the database, customers lose their basket at the switch. That is not data loss in the strict sense, but an abandoned purchase that announcing the window can avoid. Finally, the search index and caches on the new server are rebuilt after the final sync so that catalogue and prices match the transferred state.

Along with the server, everything that runs on a schedule is copied: crontab entries, system timers, the shop system's scheduled tasks and the workers that process queues. After copying they are active on both machines - working against two databases or, worse, against the same external targets. The order export goes to the ERP system twice, the newsletter goes to the list twice, payment reconciliation runs twice. The rule is simple and easily lost in the pressure of a move: at any point in time, background tasks run on at most one machine. On the new server they stay off until the switch; on the old one they are stopped with the write freeze. How silent failures of such tasks can be detected is described in the article on cron jobs and background jobs in the shop.

Payment and shipping providers report status changes to a stored address. They resolve this name themselves, with their own resolvers and their own caches. If a notification reaches the old server and the server accepts it, the provider considers it delivered - but the payment state then sits in the old database. If the old server instead rejects it with an error, providers as a rule retry delivery according to their own rules. The forwarding from the previous section solves both. In addition, every stored notification address needs checking, as does every allowlisting by IP address: interfaces of ERP, shipping or marketplaces often accept requests only from known addresses, and the new server has a new one. How these interfaces are maintained is covered in the article on payment APIs and webhook failures.

For outgoing mail, the move shifts the sending address. If the shop sends order confirmations directly from the server, its new IP address must be in the domain's SPF record before the first mail goes out, and the DKIM key has to move too. The SPF record has a hard limit: evaluation may trigger at most 10 DNS lookups (RFC 7208), otherwise it ends in a permanent error. Anyone who simply adds another include entry for the move can exceed this limit and thereby make the check fail for every mail of the domain. If mailboxes are also hosted with the old provider, incoming mail follows the same logic as notifications: if the old mail server is unreachable, nothing is lost at first, because a sending server queues the mail and tries again later. RFC 5321 recommends an interval of at least 30 minutes (RFC 5321) between attempts and a give-up time of at least 4 to 5 days (RFC 5321). If the old server keeps accepting instead, the mail lands in the old mailbox and has to be collected there before it is deleted. More on deliverability is in the article on DMARC and shop email.

The certificate has to be valid on the new server before the first visitor reaches it. There is a trap in the process here: with the widely used HTTP check of the ACME procedure, the certificate authority fetches a validation file under the domain, and this request goes to port 80 (RFC 8555) of the server the domain currently points to - before the switch, that is the old one. A new certificate can be issued this way only after the switch, and until then the first visitors see a certificate warning. Three ways out: take over the existing certificate including its key, run the validation via a DNS record, or forward the validation path on the old server to the new one. After the move, automatic renewal runs only on the new server; how certificate management monitors this is part of ongoing maintenance.

The script answers the three questions that matter after the switch: are there orders that exist only on the old server? Are cron jobs still running twice anywhere? Which resolvers still hand out the old address? During the run-out it runs several times a day until the first list is empty, only one server reports active cron lines and all checked resolvers return the new address.

A move is complete when this can be demonstrated, not when the home page loads. The home page also loads when the checkout points to an outdated interface, the order export is not running and the confirmation emails land in the spam folder. Sign-off therefore checks the paths on which revenue is created and the places where it can get lost.

The test order is the most important item on the list because it touches almost all the others. It shows whether the payment notification reaches the right server, whether the export runs and whether the mail arrives. How the order path can then be monitored permanently is described in the article on checkout monitoring.