Plan a website migration to a new VPS without losing orders

Inventory before copying

List application runtime versions, database version, scheduled jobs, private uploads, object storage, mail dependencies and DNS records. Record the existing server IP, current SSL certificate and any third-party callback URLs. Take both database and file backups with a timestamp.

Lower DNS TTL before the change if the DNS provider permits it, but remember cached responses may outlive the requested TTL. Do not remove the old server before users stop reaching it.

Rehearse on the new server

Restore the data on the new VPS and use a hosts-file override or test hostname to exercise sign-in, transactions, downloads and background jobs. Confirm database character set and time zone. Run a test order without triggering a real payment or duplicate customer notification.

If the application can receive writes, plan a brief write freeze or an appropriate replication strategy for the final sync; copying database files while transactions continue can create inconsistent data.

Cut over and prove rollback

Switch DNS only after TLS, firewall, cron, queue workers, storage paths and callbacks have been verified. Monitor errors and key business actions from outside the VPS. Keep the previous host available in read-only or recoverable state until you have enough evidence that traffic moved successfully.

A rollback must specify which data is authoritative after a failed cutover, especially for orders, payments and customer messages. Write down the exact rollback trigger before migration day.

Does Rokocloud guarantee the features described in this guide?

No. This is practical evaluation and setup advice. Available plans, pricing, network controls, OS images, licensing and backups must be confirmed for the selected service before purchasing.