Payments are experiencing issues due to temporary restrictions in Russia. If your payment does not go through, please submit a support request.Our support team is available 24/7 — we are always here to help with hosting and server issues.We are now accepting requests for dedicated server rental and colocation services in our data center.Reminder: we recommend enabling backups for additional data protection.A new VPS/VDS lineup with NVMe storage and improved performance is now available.Maintenance work on some servers has been completed. All services are operating normally.
Article5 min readViews2

How to Migrate an Online Store to a New VPS Without Losing Orders

A step-by-step plan for migrating an online store to a new VPS: backup, test launch, final synchronization, DNS, payment notifications, and rollback.

АльбинаCommunity author★ 73Discuss0
Two server racks and a backup drive during the online store migration to VPS
In this article

A standard website can be migrated overnight and checked in the morning. For an online store, that is not enough: while files and the database are being copied, customers are placing orders, payment systems are sending notifications, 1C is updating stock levels, and background tasks are generating exports.

The main risk of migration is not a few minutes of downtime, but data divergence between the old and new servers. Therefore, the migration must be designed as a controlled cutover with a checkpoint and a clear rollback procedure.

Map the data that changes

Before starting work, list everything that changes in real time:

  • orders, payments, statuses, and returns;

  • shopping carts and user sessions;

  • stock levels, prices, and reservations;

  • new accounts and customer addresses;

  • uploaded files, images, and documents;

  • email queues, background jobs, and 1C integration;

  • notifications from banks, delivery services, and marketplaces.

This map determines the final synchronization method. A one-time database copy is insufficient if the old server continues to accept records.

Check the target VPS before copying

The new server must be compatible with the application: operating system version, web server, PHP, database management system, extensions, scheduler, and search engine. For 1C-Bitrix: Site Management, it is useful to pre-check the environment using the system's built-in tools and compare PHP settings, encoding, and time zone.

Resources are selected based on metrics, not just the number of products. Review peak CPU load, memory usage, database size and growth rate, disk operations, background jobs, and the time required to generate heavy pages. The VPS must have headroom for indexing, imports, and backups.

Before the migration, configure security updates, separate user accounts, a firewall, TLS, monitoring, logging, and store backups outside the new server.

Create a copy and verify restoration

A backup is considered valid only after a test restoration. Copy the database, user files, application configuration, cron jobs, web server settings, and external integration details. Secrets should not be stored in an unencrypted archive without access control.

Deploy the store on a new VPS using a technical address or a local hosts entry. Block the copy from buyers and search engine crawlers so it does not accept real orders and is not indexed.

On the test copy, check the homepage, catalog, search, product card, cart, checkout, personal account, and admin panel. Additionally, test email delivery and background job execution.

Minimize the change window

One or two days before the switch, reduce the DNS TTL values if the current setup allows it. A low TTL does not move the site by itself and does not guarantee an instant update for all providers, but it shortens the lifespan of the old address in most caches.

You can copy the bulk of files in advance and transfer only the changes before the switch. For the database, choose a strategy:

  • short maintenance window with a final dump;

  • replication followed by a switch;

  • temporary suspension of write operations;

  • application-level synchronization if the system supports it and the team can manage conflicts.

For most medium-sized stores, a short maintenance mode is clearer and safer than complex bidirectional writing. It is better for a buyer to see an honest message for a few minutes than to place an order into a database that is no longer the primary one.

Execute the final switch according to the checklist

At the start of the maintenance window, stop background jobs, imports, queue processing, and 1C synchronization on the old server. Block new write operations or enable maintenance mode. Record the last order number and timestamp.

Create a final copy of the database and changed files, transfer them, update the connection configuration, and launch the application on the new VPS. Only switch DNS, load balancers, or external IPs after verification.

On the new server, ensure the scheduler and queues run in exactly one location. If cron continues running on both servers, the store may send duplicate emails, deduct stock twice, or process the same order twice.

Verify the entire order flow

After the switch, simply opening the homepage is not enough. Place a test order and follow its path:

  1. The product is added to the cart with the correct price and stock level.

  2. The order receives a unique number following the last live order.

  3. The email or other notification is sent only once.

  4. The payment system returns a successful status to the new endpoint.

  5. The order is forwarded to 1C or another accounting system.

  6. The status update is reflected on the website.

  7. The delivery service receives and returns data.

Check incoming webhooks. Some external services use whitelisted IPs, dedicated callback addresses, or request signatures. Server migration can break integrations even if the website pages load correctly.

Do not shut down the old server immediately

The old VPS should be switched to a mode that rejects orders and stops background tasks, while remaining accessible to the team for an agreed period. Logs from both the old and new servers will help identify customers still accessing the old address.

Define rollback conditions in advance: critical payment errors, lost orders, database unavailability, or response time exceeding limits. A rollback is not just about reverting DNS. You must determine if any records exist on the new server that are missing from the old one, and how to safely move them back.

After stabilization, restore the standard TTL, update documentation, remove temporary access credentials, and verify the new backup system. A few days later, perform a recovery test using a copy from the new VPS.

A successful migration is measured not only by uptime. Order numbers must remain continuous, payments must align, inventory levels must match, background tasks must not duplicate, and the team must have proof that the backup can actually be restored.

GENERAL IT

Help with your project

GENERAL IT

Read more on this topic

Discussion0

Share your experience and ask questions. Comments without links appear after editorial review.

No comments yet. Start the discussion.