Move a Website Without Losing New Orders
DNS changes do not move orders. Give the old and new hosts a clear handoff and verify the last transaction before reopening checkout.

IN THIS ARTICLE+
Copying a website is easy until someone places an order between the copy and the cutover. The old database accepts payment, the new one has never heard of it, and DNS faithfully directs the next customer to whichever address their resolver still has. The migration problem is deciding which system may accept writes at each moment.
Rehearse with a copy
Restore a recent backup into an isolated environment. Disable real outgoing mail, payment calls and scheduled jobs there. Test a cart, login, upload and administrative edit using the intended hostname and TLS configuration. Record how long the final restore takes. If that time exceeds the acceptable interruption, choose replication or a different cutover method before migration day.
Inventory state outside the database. Uploaded files, queued jobs and session storage often live elsewhere. A database backup alone cannot recreate a recently uploaded product photo.
Establish one writer
For a small store, a brief write freeze is often easier to verify than running two writable sites. Stop new orders at the application boundary, account for in-flight transactions and payment callbacks, then take the final consistent copy. Use the payment provider's documented retry or reconciliation mechanism for events that arrive during the freeze. Start workers on only one side.
Lowering DNS TTL in advance can shorten the transition, but a DNS change cannot stop the old application accepting writes. Keep the old endpoint in maintenance mode or securely forward it to the new writer while cached answers expire.
Define when rollback changes meaning
Before reopening checkout, compare the latest order IDs, totals, upload references and pending jobs. Place a controlled test order and verify exactly one processing event. Once the new host accepts real orders, switching DNS back to the old database is no longer a simple rollback. First reconcile or replicate the new writes, or keep the new database authoritative while restoring the old application version.
Further reading
PostgreSQL: Backup and restore
Related guide: VM Snapshots and Backups Solve Different Problems.
No comments yet. Share the first perspective.