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.

Two storefront models with order slips moving toward the new location.
At cutover, one system must own each new write.
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.

Comments

No comments yet. Share the first perspective.

Related articles

Hosting & Servers articles →

Categories