# Migrating PrestaShop without interrupting sales

> A well-run PrestaShop migration doesn’t take the shop offline. The real difficulty isn’t the code itself: it’s the data gap that builds up between preparing the new version and switching over to it.

- Source canonique : [https://allaux.fr/en/prestashop/migration/migrer-sans-interruption-de-vente](https://allaux.fr/en/prestashop/migration/migrer-sans-interruption-de-vente)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Build the target version on a full copy, files and database, while the shop keeps selling. At switch-over the only real risk is the data gap: freeze orders long enough to take a final export of ps_orders, ps_customer and stock quantities, push it into the new database, then reopen. Announce the window in advance and pick a quiet hour.

## Working on a copy, never on the live shop

The starting rule is simple: I make a full copy of the shop, files and database, on a separate test environment. All the preparation, testing and fixing happens on that copy. The live site keeps running normally the whole time, with no changes made to it. That removes the main risk of a poorly prepared migration: breaking the live shop while still hunting for the right configuration.

This separation also buys the time actually needed. A migration can take several days of checks, module fixes or theme adjustments. None of that has to affect visitors or in-progress orders while the work is under way.

## The real risk: the data gap at cut-over

Once the copy is made, the live shop keeps going: new orders come in, new customer accounts get created, stock moves. Between the moment the copy was taken and the moment the new version goes live, a gap inevitably opens up. That gap, not the migration itself, is the real problem: ignore it, and the shop switches over to a database missing every order placed in between.

Two approaches handle it. The first is to freeze orders right before the final switch: a short window, announced in advance, during which checkout is briefly disabled while the switch happens. The second is to replay a diff of orders and accounts created during the final test phase, feeding them into the new database before opening to the public. Which one fits depends on daily order volume and how much a brief checkout pause is tolerable.

## How I prepare the switch

1. **Full copy on a test environment** — Files and database duplicated on a separate environment, with no work touching the live site.
2. **Migration and checks on the copy** — The entire version migration, theme adaptation and replacement of incompatible modules happens on that copy, at my own pace, without cut-over pressure.
3. **End-to-end checkout test** — Before opening to the public, I check adding to cart, going through checkout, a test-mode payment where the payment method allows it, and that the confirmation email actually arrives.
4. **Picking a low-traffic window** — The final switch is scheduled for the lowest order-volume window, to minimise how many orders are caught in the data gap.
5. **Switch and verification under real conditions** — The original site stays readable or on standby while I confirm the new version works correctly, before permanently retiring the old one.

## When downtime happens, it’s very short

> The migration itself doesn’t take anything offline: it runs on a copy. When there is an interruption, it’s usually limited to switching the DNS record or updating server configuration at cut-over, not the migration itself.

## Go further

- **Pre-migration checklist** — Everything worth checking and preparing before starting a PrestaShop migration. ([/prestashop/migration/checklist-avant-migration](/prestashop/migration/checklist-avant-migration))
- **Incompatible modules** — How to identify and replace modules that don’t migrate to the new version. ([/prestashop/migration/modules-incompatibles](/prestashop/migration/modules-incompatibles))
- **1.7 to 8 migration** — What actually changes between PrestaShop 1.7 and 8. ([/prestashop/migration/1-7-vers-8](/prestashop/migration/1-7-vers-8))

## FAQ

### Does the site stay online during the whole migration?

Yes. The migration runs on a separate copy, so the live site keeps working normally for visitors throughout the preparation.

### What happens to orders placed while you’re preparing the migration?

They stay in the production database. Depending on the method used, they’re either covered by a short order-freeze window right before the switch, or replayed as a diff into the new database before opening to the public.

### How long will the shop actually be unavailable?

When there is downtime, it’s usually limited to switching the DNS record or updating server configuration, not the migration itself. That’s generally measured in minutes, not hours.

### How do you make sure the new version works before switching off the old one?

I test checkout end to end before opening to the public: adding to cart, going through checkout, a test-mode payment where possible, and confirming the order email actually arrives. The original site stays available as a fallback while I verify.

### Why not migrate directly on the live site?

Because any error during the migration would be immediately visible to your visitors. Working on a copy means theme or module issues get fixed calmly, without ever exposing an unstable shop.