Migrer Magento 2 : plan, sauvegardes, rollback et staging (guide 2026)

Migrer Magento 2 : plan, sauvegardes, rollback et staging (guide 2026)

Migrer une boutique Magento 2 (nouveau serveur, nouvel environnement Docker, changement d’infra, ou grosse mise à jour) peut très bien se passer… à condition d’avoir un plan.

Dans ce guide, vous allez construire une migration :

• prévisible (staging et tests avant la bascule)
• réversible (retour arrière possible en quelques minutes)
• avec risque maîtrisé (sauvegardes vérifiées, fenêtre de bascule claire)

Si vous voulez une alternative “plateforme” (déploiement en 1 clic, facturation à l’heure, start/stop, sauvegardes automatiques, scaling CPU/RAM), vous pouvez aussi regarder Magento sur adgents.cloud.

Vidéo (YouTube, FR)

1) Définir le type de migration (ça change tout)

Avant de toucher aux serveurs, clarifie votre scénario :

• Migration d’hébergement (on garde la version Magento, on change d’infra)
• Mise à niveau Magento (ex : 2.4.x → 2.4.y)
• Les deux en même temps (le plus risqué)

Recommandation pragmatique :

• si vous pouvez, sépare en 2 étapes (d’abord l’infra, puis la mise à niveau)
• sinon, prépare un retour arrière “infra + code + DB” prêt à déclencher

pour vous donner une référence de plan de migration côté e-commerce, la logique est proche de Migrer PrestaShop (1.7→8) : plan de migration + risques + tests : staging, tests, bascule, puis monitoring.

2) Préparer un environnement de staging (clone fidèle)

votre staging doit être le plus proche possible de la prod :

• mêmes versions PHP / DB / OpenSearch
• mêmes modules
• même configuration (env, cache, sessions)

Deux règles utiles :

1. base de données copiée depuis prod (avec anonymisation si nécessaire)
2. media copiés (catalogue, thèmes, assets)

si vous utilises Docker Compose, vous pouvez vous appuyer sur une base de déploiement propre comme Installer Magento 2 avec Docker Compose (prod), puis dupliquer l’environnement pour le staging.

3) La stratégie de sauvegarde (et surtout… la restauration testée)

Une migration réussie = une restauration déjà prouvée.

À minima, vous voulez :

• une sauvegarde base de données
• une sauvegarde fichiers/media
• une sauvegarde configuration / secrets (sans les exposer)

Sauvegarde DB (exemple MariaDB/MySQL)

# Exemple : dump gzip côté hôte
mkdir -p ~/backups/magento

docker exec -i $(docker compose ps -q db) mariadb-dump -u${DB_USER} -p${DB_PASSWORD} ${DB_NAME} \
  | gzip > ~/backups/magento/db-$(date +%F-%H%M).sql.gz

Sauvegarde media / fichiers

Ça dépend de votre installation, mais vise une copie de :

• le volume/app (code + config)
• les répertoires media (catalogue, thèmes, etc.)

Exemple générique (à adapter) :

# Exemple : archiver un volume monté dans le conteneur
docker exec $(docker compose ps -q magento) \
  tar -czf /tmp/magento-files-$(date +%F-%H%M).tar.gz /bitnami/magento

docker cp $(docker compose ps -q magento):/tmp/magento-files-$(date +%F-%H%M).tar.gz \
  ~/backups/magento/

Test de restauration (obligatoire)

Sur staging, fais au moins une restauration complèvous :

• importer la DB
• remettre les fichiers/media
• vérifier que le front et l’admin fonctionnent

si vous ne testes pas la restauration, vous n’as pas une sauvegarde… vous avez un espoir.

4) Réduire la perte de commandes (préparer le “delta”)

Le piège classique :

• vous copies la prod vers staging
• vous testes
• puis la prod continue de recevoir des commandes

Au moment de la bascule, vous avez un écart (commandes, clients, stock).

Deux approches :

• fenêtre de gel : vous mettez la boutique en maintenance pendant la copie finale
• réplication / synchronisation : plus complexe, plutôt pour équipes très techniques

Dans la majorité des cas, une fenêtre courte (ex : 15–45 min) + un plan de bascule propre suffit.

5) Plan de bascule (minute par minute)

Prépare un déroulé simple, avec des durées estimées :

1. baisser le TTL DNS (la veille)
2. annoncer la fenêtre
3. activer le mode maintenance (ou bloquer le checkout)
4. faire la sauvegarde “finale” (DB + media)
5. restaurer sur la nouvelle infra
6. passer les tests rapides
7. basculer DNS / load balancer
8. surveiller et corriger

Tests rapides indispensables après restauration :

• home, catégorie, fiche produit
• recherche (OpenSearch)
• ajout panier + paiement (sandbox si possible)
• admin : connexion + indexation + cache

Pour les optimisations qui impactent la vitesse (cache, DB, index), garde sous la main Magento 2 performances : réduire le TTFB, maîtriser le cache, sécuriser l’indexation.

6) Plan de rollback (votre parachute)

votre rollback doit être déclenchable vite, sans débat. Par exemple :

• si le checkout échoue
• si le front est instable
• si l’admin est inaccessible

Rollback “simple” :

• revenir au DNS / LB précédent
• remettre la boutique live sur l’ancien environnement

Important : prévois le point de retour (à quel moment vous “figes” l’ancienne prod) pour éviter de perdre des commandes.

Lancez-vous avec Magento.

Envie de vous lancer avec Magento ? Créez votre site web en quelques clics.

Magento

E-commerce enterprise

Déployer Magento

7) Après la bascule : monitoring et stabilisation

Les 2 heures après la migration font la différence :

• erreurs 500/502 (proxy, PHP-FPM, timeouts)
• latence DB / OpenSearch
• saturation CPU/RAM
• problèmes de cache

Si vous voulez éviter de surdimensionner “au cas où”, une approche flexible (CPU/RAM à la demande + redimensionnement rapide) aide beaucoup : Magento sur adgents.cloud.

Migrer Magento sans gérer l’infra (option simple)

Si votre objectif est de réduire la charge d’exploitation :

• déploiement en 1 clic
• facturation à l’heure
• start/stop
• sauvegardes automatiques
• scaling CPU/RAM

Découvrir : Magento sur adgents.cloud.