# Migration and updates

> Migrating a shop covers three different situations: upgrading version on the same platform, switching platform, or switching host. Each carries its own risks, and I treat them differently rather than applying one default method.

- Source canonique : [https://allaux.fr/en/services/migration](https://allaux.fr/en/services/migration)
- Langue : EN
- Dernière mise à jour : 2026-08-03

## Three types of migration, three levels of risk

A version upgrade on the same platform stays the most contained: the core system doesn't change, but modules or a customised theme can become incompatible. A platform switch is heavier: catalogue, customer accounts, order history and business logic have to be rebuilt or transferred, which almost always means choices to make, not a straight copy.

A hosting change on its own is often the simplest technically, but still sensitive: DNS, certificates, server configuration and email all have to switch over without extended downtime.

## How a migration runs

1. **Audit of the existing setup** — Inventory of modules, customisations, data volumes and external dependencies before any pricing.
2. **Written switch plan** — What's carried over as-is, what's rebuilt, and the order of operations, including a rollback plan if needed.
3. **Migration on a separate environment** — The work happens on a copy, never directly on the live site.
4. **Switch and verification** — Going live at an agreed time, then checking critical journeys: ordering, payment, customer accounts.
5. **Post-migration follow-up** — Close monitoring in the days that follow, to confirm nothing was missed.

## What I don't promise

> I don't guarantee a migration with zero downtime or a pixel-perfect identical result: some platform changes involve losing specific features or visual adjustments. A full, verified backup before any operation is a non-negotiable condition, not an option.

## FAQ

### Is SEO affected by a migration?

It's a real risk, especially with a platform or URL change. I set up the necessary redirects, but a temporary SEO impact remains possible and I flag it in advance.

### How long is the site down during the switch?

It depends on the type of migration. I aim to minimise downtime, but I don't quote it as a guaranteed figure until the audit of the existing setup is done.

### Is all my data carried over?

Catalogue, customers and order history are the priority. Some data very specific to a third-party module may have no equivalent on the new platform; I flag this at audit stage.

### Can I roll back if something goes wrong?

That's built into the switch plan, provided a backup of the initial state exists. That's exactly why it's mandatory before starting.

### Should I migrate in one go or can it be done in stages?

Both are possible depending on the size of the project. A staged migration reduces overall risk but extends the total timeline; the choice is made case by case.

### What happens to the old site after the migration?

I recommend keeping it accessible, taken offline publicly, for a safety period after the switch. It's a simple, low-cost safeguard that avoids relying solely on the backup if a check is ever needed.