Migration Magento 1 vers Magento 2 : étapes et contrôles
Migrer de Magento 1 vers Magento 2 est une reprise de plateforme, pas une simple mise à jour.
Les données, le thème, les extensions et le code spécifique suivent des parcours différents.
Adobe a confirmé la fin du support officiel de Magento 1 en juin 2020.
Une boutique encore sur cette génération demande une analyse de ses dépendances et un plan de migration.
Définir la cible avant de transférer les données
Choisissez l’édition et le modèle d’hébergement.
Magento Open Source, Adobe Commerce et ses modèles de déploiement ne présentent pas le même périmètre ni les mêmes conditions d’exploitation.
Vérifiez la version cible, ses prérequis et les compatibilités des extensions.
Le transfert doit être préparé avec les outils correspondant aux versions réellement installées.
Ce qui se migre et ce qui doit être refait
| Élément | Travail à prévoir |
|---|---|
| Données et réglages | Cartographie, outil de migration compatible et contrôles. |
| Thème | Reconstruction ou adaptation du design sur la nouvelle plateforme. |
| Extensions | Remplacement ou reprise selon les versions et les données propres. |
| Code spécifique | Réécriture, adaptation et tests métier. |
| Médias et URL | Transfert des fichiers et cartographie des adresses publiques. |
La documentation du Data Migration Tool distingue les étapes de réglages, de données et de reprise des changements.
Elle ne présente pas le thème et les extensions comme un transfert automatique.
Faire l’inventaire de l’ancienne boutique
Recensez les produits, variantes, clients, commandes et médias.
Ajoutez les données des extensions, les règles de prix, les moyens de paiement et les connexions à vos outils.
Identifiez les URL qui reçoivent du trafic ou portent des liens.
Une migration doit conserver les adresses utiles lorsque c’est possible et préparer les redirections lorsque la structure change.
Attribuez un responsable à chaque flux : stock, commande, expédition et facturation.
Les erreurs de synchronisation et les doublons doivent avoir une procédure de traitement.
Répéter la migration sur une copie
Travaillez d’abord sur une copie protégée de la boutique et vérifiez les sauvegardes.
L’environnement de test doit empêcher les courriels et les transactions de test d’atteindre les clients ou les services de production.
Le plan de migration recommandé par Adobe prévoit une répétition et des contrôles. Les médias et les adaptations spécifiques demandent une prise en charge distincte.
Comparez les volumes et des échantillons représentatifs : clients, commandes, taxes, remises, variantes et stocks.
Un total identique ne suffit pas si les données sont rattachées au mauvais produit ou client.
Valider la nouvelle boutique avant la bascule
- Tester le catalogue et la recherche avec des produits réels.
- Exécuter une commande complète, puis un remboursement.
- Vérifier les courriels, les factures et les accès clients.
- Contrôler les connexions et le traitement des erreurs.
- Tester les redirections, les canonicals et l’indexabilité.
Conservez les résultats de recette et faites valider les fonctions indispensables par les responsables métier.
Les anomalies bloquantes doivent être corrigées avant l’ouverture.
Préserver les commandes pendant le changement
La boutique peut continuer à recevoir des ventes après la copie initiale.
Il faut définir comment reprendre ces changements, à quel moment figer les écritures et comment rapprocher les paiements.
La phase de reprise incrémentale de l’outil, appelée « delta », ne dispense pas de contrôler les données spécifiques aux extensions.
Les restrictions pendant la bascule doivent être convenues à l’avance.
Préparez un retour arrière qui conserve les nouvelles commandes.
Une restauration ancienne sans réconciliation peut faire perdre des ventes ou provoquer des doubles traitements.
Après la bascule, surveillez les commandes, les flux, les erreurs et les pages importantes.
Pour clarifier la cible, notre guide Magento Open Source et Adobe Commerce distingue les offres et les responsabilités.
Magento 1 et Magento 2 : pourquoi parle-t-on de migration et non de mise à jour ?
Magento 2 n’est pas une évolution que l’on applique à Magento 1 comme un correctif classique. L’architecture, le thème, les extensions et de nombreuses couches techniques ont changé. C’est pourquoi le projet doit être traité comme une migration de plateforme avec inventaire, reprise de données, reconstruction de certains composants et recette.
| Sujet | Conséquence pour la migration |
|---|---|
| Thème | Reconstruction ou nouvelle intégration sur le front Magento 2 |
| Extensions | Vérifier équivalent Magento 2, compatibilité et données propres |
| Code spécifique | Audit puis réécriture ou suppression si la fonction n’est plus nécessaire |
| Données métier | Mapping, migration, delta et contrôles de cohérence |
| SEO | Conserver les URL quand possible et planifier les redirections |
Le Data Migration Tool : ce qu’il fait, et ce qu’il ne fait pas
Adobe fournit un Data Migration Tool pour migrer des réglages et des données depuis Magento 1 vers Magento 2. Il prend aussi en charge une phase delta pour récupérer certains changements survenus après une migration initiale.
Cet outil ne transforme pas automatiquement un thème Magento 1 en thème Magento 2 et ne garantit pas que les extensions tierces disposent d’un équivalent. Ces éléments doivent être audités séparément.
Combien de temps dure une migration Magento 1 vers Magento 2 ?
La durée dépend beaucoup plus du niveau de personnalisation que du nombre de produits seul. Une boutique avec quelques extensions standard peut être plus simple à reprendre qu’un catalogue plus petit mais fortement connecté à un ERP, un PIM, plusieurs transporteurs et du code métier spécifique.
Le planning doit intégrer audit, environnement cible, thème, extensions, développements spécifiques, migrations à blanc, recette, correction, delta final et période de surveillance après ouverture. Demander une estimation fiable sans cet inventaire crée un faux sentiment de précision.
Les risques à surveiller pendant la migration
- Perte ou duplication de commandes pendant la bascule.
- Extension indispensable non disponible ou incompatibilité avec la version cible.
- Régression sur taxes, promotions, stocks ou règles de livraison.
- Changement d’URL non accompagné de redirections 301.
- Perte de données SEO, canonicals ou données structurées.
- Emails de test envoyés à de vrais clients.
- Synchronisation ERP/PIM/paiement non testée en scénario d’erreur.
Quand profiter de la migration pour repenser la boutique ?
Une migration n’oblige pas à reproduire toutes les décisions historiques. C’est le bon moment pour identifier les extensions devenues inutiles, simplifier le tunnel, revoir les gabarits, nettoyer le catalogue ou réorganiser les flux. Mais chaque changement ajouté augmente aussi le périmètre et le risque : distinguez ce qui est indispensable à la migration de ce qui relève d’une amélioration produit.
Article publié le 6 décembre 2023. Mis à jour le 1er octobre 2026 par Olivier Robé.