Migration de Magento vers PrestaShop : alléger la maintenance sans perdre le catalogue

Une migration de Magento vers PrestaShop remplace les montées de version que le calendrier d’Adobe fixe pour Adobe Commerce. Au 14 octobre 2026, le support standard d’Adobe Commerce ne couvre plus que les lignes 2.4.7, 2.4.8 et 2.4.9. Le catalogue se reprend à condition de réorganiser produits configurables, jeux d’attributs et vues de magasin, et de lire les commandes ailleurs que dans l’export natif.

• Le calendrier d’Adobe fixe l’échéance de chaque boutique Adobe Commerce
• Une montée de version Magento se compare au devis de migration vers PrestaShop
• Le catalogue Magento se réorganise avant d’entrer dans PrestaShop
• L’export de Magento s’arrête aux produits, aux prix et aux clients
• Les mots de passe Magento se convertissent à la première connexion
• Les extensions Magento se remplacent fonction par fonction
• Les adresses en .html de Magento changent toutes sur PrestaShop
• Les produits enfants, les vues abandonnées et l’ancien serveur alourdissent la migration
• Sources consultées
• Foire aux questions

Le calendrier d’Adobe fixe l’échéance de chaque boutique Adobe Commerce

Adobe accorde à chaque ligne d’Adobe Commerce trois ans de support standard, comptés depuis sa disponibilité générale, c’est-à-dire sa sortie officielle. Sa table de cycle de vie donne, au 14 octobre 2026 :

• 2.4.6 : disponible le 14 mars 2023, support standard jusqu’au 11 août 2026, support étendu jusqu’au 31 août 2027 ;
• 2.4.7 : disponible le 9 avril 2024, support standard jusqu’au 31 mai 2027, support étendu jusqu’au 31 mai 2028 ;
• 2.4.8 : disponible le 8 avril 2025, support standard jusqu’au 31 mai 2028, date de support étendu non fixée ;
• 2.4.9 : disponible le 12 mai 2026, support standard jusqu’au 31 mai 2029, date de support étendu non fixée.

La FAQ d’Adobe sur la fin de support, mise à jour le 24 septembre 2026, écrit qu’une version arrivée à ce terme ne reçoit plus de correctifs de sécurité et n’est plus conforme à la norme PCI DSS des cartes de paiement ; une licence ne donne alors droit à aucun support logiciel sur elle. Ce que couvre le support étendu, ces pages ne le détaillent pas : demandez-le par écrit.

Ces tables ne nomment qu’Adobe Commerce, l’édition sous licence. Elles ne disent rien de Magento Open Source, l’édition gratuite, ni de Magento 1, absent de la liste. Demandez à votre développeur, par écrit, quels correctifs reçoit votre boutique et jusqu’à quand.

Une montée de version Magento se compare au devis de migration vers PrestaShop

Posez deux devis côte à côte : la montée de version de votre ligne Magento vers la 2.4.9, et la migration vers PrestaShop.

Ajoutez au premier vos frais annuels : hébergement, renouvellement des extensions, heures de développement passées sur les correctifs, licence Adobe Commerce le cas échéant. Multipliez par le nombre d’années avant la prochaine fin de support de votre ligne, lue dans la liste ci-dessus.

Le devis de migration, lui, suit le nombre de vues de magasin, de jeux d’attributs et de produits configurables. S’y ajoutent les extensions porteuses de données (fidélité, prix négociés, connecteur de gestion) et la reprise éventuelle de l’historique des commandes. Exigez qu’il dise qui paie si la bascule casse la boutique : Magento reste installé, fermé aux clients, tant que PrestaShop n’a pas été validé, et son rétablissement revient au prestataire.

Le catalogue Magento se réorganise avant d’entrer dans PrestaShop

Magento connaît sept types de produits, dont la carte cadeau, propre à Adobe Commerce. Côté PrestaShop, le choix se limite à quatre : produit standard, produit à déclinaisons, pack, produit virtuel.

Le produit configurable, présenté comme un produit unique à listes d’options, correspond au produit à déclinaisons : ses options deviennent les déclinaisons d’un seul produit PrestaShop. Virtuels et téléchargeables deviennent des produits virtuels. Le bundle, que le client compose lui-même parmi des options, ne trouve rien de comparable : un pack PrestaShop vend un lot défini à l’avance. Même constat pour le produit groupé.

Les jeux d’attributs, ces modèles de fiche propres à chaque type de produit, se séparent en deux familles. Ce que le client choisit au moment d’acheter (taille, coloris) devient un attribut de déclinaison ; ce qui décrit le produit (matière, origine, entretien) devient une caractéristique, affichée sur la fiche et utilisable en filtre.

Les vues de magasin, souvent une par langue, deviennent des langues de PrestaShop. Plusieurs sites Magento sur une même installation deviennent plusieurs boutiques du mode multiboutique.

Décrire mon besoin →

L’export de Magento s’arrête aux produits, aux prix et aux clients

L’outil System > Data Transfer > Export propose six types d’entités, exportées en fichiers CSV : produits, prix avancés, clients, adresses des clients, données financières des clients et sources de stock. Les commandes n’y figurent pas : il faut les chercher dans les tables de Magento, avec un outil de migration ou un script. Les fichiers d’images ne figurent pas non plus dans cette liste : demandez d’où le prestataire les prélève. Pour l’enchaînement complet, de la copie de travail aux commandes de dernière minute, voyez les cinq passes de la reprise des données.

Les mots de passe Magento se convertissent à la première connexion

D’après le code de Magento 2, chaque mot de passe se range sous la forme « empreinte:sel:version ». L’empreinte désigne le mot de passe rendu illisible par calcul, le sel une valeur aléatoire propre au compte, la version l’algorithme noté dans le code : md5, sha256 ou argon2id.

PrestaShop ne connaît que deux méthodes de contrôle, celle intégrée à PHP et celle de ses versions 1.6 : aucune ne lit ce format. Son outil d’import du back-office re-hache aussi la colonne « passwd », ce qui rend une empreinte Magento collée là inutilisable. Seule une empreinte transférée en base avec la table des clients, clé de chiffrement reprise, reste intacte, et il faut alors un module de connexion qui la contrôle au premier passage du client, puis la remplace par une empreinte PrestaShop.

Exigez un test sur un compte de chaque version présente dans votre base. Sans ce module, chaque client redéfinit son mot de passe depuis le lien prévu à cet effet.

Les extensions Magento se remplacent fonction par fonction

Dressez l’inventaire des extensions installées sur trois colonnes : la fonction rendue, le module PrestaShop pressenti, les données à transférer. Une extension de paiement se remplace ; un connecteur vers votre logiciel de gestion se reconfigure ; une extension qui gère comptes professionnels et prix négociés demande un cadrage à part, celui d’un espace B2B.

Les adresses en .html de Magento changent toutes sur PrestaShop

Magento accepte un suffixe html ou htm et, par défaut, n’inscrit pas la catégorie dans l’adresse d’un produit : une fiche répond par exemple en /sac-cabas-cuir.html. Chez PrestaShop, l’adresse d’un produit contient obligatoirement son identifiant numérique : elle devient par exemple /12-sac-cabas-cuir.html. Les réécritures d’adresses que Magento a enregistrées (« URL Rewrites » dans la documentation d’Adobe) donnent la base du plan de redirections, dont les règles relèvent du SEO de migration.

Les produits enfants, les vues abandonnées et l’ancien serveur alourdissent la migration

Importer les produits enfants d’un configurable comme fiches autonomes double le catalogue. Chacun porte sa propre référence chez Magento ; repris tel quel, il crée des pages vides de sens. Seul le parent devient un produit PrestaShop.

Reprendre les vues de magasin abandonnées et les produits désactivés depuis des années. Chaque élément repris se traduit, se teste et se maintient : triez avant l’import.

Laisser tourner l’ancien serveur Magento après la bascule. Il garde la base clients sans recevoir de correctifs ; archivez la base sur un support déconnecté, puis éteignez-le.

Dans le message du formulaire de cette page, reportez votre ligne et votre édition de Magento, le nombre d’extensions et le nombre de vues de magasin.

Décrire mon besoin →

Sources consultées

• Adobe, « Software lifecycle policy », documentation Adobe Commerce, consulté le 14 octobre 2026.
• Adobe, « Adobe Commerce Software End of Support FAQ », mise à jour du 24 septembre 2026, consulté le 14 octobre 2026.
• Adobe, « Export data », guide d’administration d’Adobe Commerce, consulté le 14 octobre 2026.
• Adobe, « Catalog and product URLs », guide d’administration d’Adobe Commerce, consulté le 14 octobre 2026.
• Adobe, « Create a product », types de produits, consulté le 14 octobre 2026.
• Magento, code source de Magento 2, fichier « Encryptor.php », branche 2.4-develop, consulté le 14 octobre 2026.
• PrestaShop, code source du logiciel, fichiers « AdminImportController.php », « Hashing.php » et « Dispatcher.php », branches 8.2.x et develop, consulté le 14 octobre 2026.
• PrestaShop, documentation utilisateur de PrestaShop 9, « New product page (PrestaShop 9.1) », types de produits, consulté le 14 octobre 2026.

Foire aux questions

Faut-il monter de version Magento avant de migrer ?

Non, si la migration aboutit avant la fin du support de votre ligne. Sinon, appliquez le dernier correctif publié pour votre ligne, limitez l’accès à l’administration Magento et resserrez le calendrier. Une montée de version faite pour quelques mois paie deux fois le même travail de tests.

Une boutique Magento 1 se migre-t-elle de la même façon ?

Les pages d’Adobe consultées ne la mentionnent pas : rien ne permet d’affirmer ici ce que son export ou sa base contiennent. Demandez au prestataire s’il a déjà repris une boutique de cette génération, et faites-lui décrire par écrit les tables qu’il lira.

Que deviennent les prix par groupe de clients et par quantité ?

Ils sortent de Magento par l’export des prix avancés. PrestaShop les reçoit sous forme de prix spécifiques, réglés par groupe de clients et à partir d’une quantité donnée. Faites vérifier trois cas réels après import : un client grossiste, un palier de quantité, une promotion datée.

Un PrestaShop multiboutique remplace-t-il plusieurs sites Magento ?

Oui, quand les sites partagent l’essentiel du catalogue. Le mode multiboutique pilote plusieurs boutiques depuis un seul back-office, avec des prix, des stocks et des thèmes propres à chacune si besoin. Des sites sans produits communs gagnent parfois à rester des installations séparées.