La migration de Magento vers BigCommerce est possible pour n'importe quel catalogue, mais les boutiques B2B échouent plus souvent que les boutiques B2C, car Magento et BigCommerce gèrent différemment les produits configurables, les groupes de clients et les règles de tarification. Le thème et le contenu se migrent facilement. Ce n'est pas le cas de la logique de tarification et de la structure des produits, et c'est sur cet écart que la plupart des projets perdent plusieurs semaines.
Nous avons procédé à des migrations de plateforme dans les deux sens, et nous n'avons pas de plateforme à défendre ici. Il s'agit d'un regard sans concession sur ce qui pose réellement problème.
Que vous utilisiez Adobe Commerce ou Magento Open Source, le modèle de données de base est le même ; c’est pourquoi une migration d’Adobe Commerce vers BigCommerce et une migration de Magento Open Source se heurtent à des problèmes structurels identiques. La différence entre les deux éditions de Magento réside dans des fonctionnalités telles que la mise en ligne progressive du contenu et les règles de tarification du catalogue avec des conditions complexes, qui sont toutes deux propres à Adobe Commerce. Si vous utilisez la version Open Source, certaines des lacunes mentionnées dans ce guide ne vous concerneront pas, car vous n’avez jamais disposé de ces fonctionnalités et n’avez donc rien à perdre. Si vous utilisez Adobe Commerce, prévoyez-en la prise en compte.
La plupart des ressources consacrées à la migration traitent de la conversion des thèmes et de l'importation de contenu. C'est la partie la plus simple du projet. Ce qui détermine si vos clients B2B pourront toujours passer correctement une commande groupée dès le premier jour, c'est le modèle de données, et plus précisément la manière dont chaque plateforme gère les variantes de produits, les tarifs spécifiques aux clients et la structure des URL.
Les raisons qui poussent les entreprises à passer de Magento à BigCommerce sont généralement d'ordre opérationnel, et non esthétique. Cinq d'entre elles reviennent le plus souvent dans nos échanges avec nos clients :
Aucune de ces raisons n'est erronée. Elles ne reflètent toutefois pas toute la réalité, car aucune d'entre elles ne vous permet de savoir si votre catalogue spécifique restera intact après la migration. Cela dépend de ce qui se cache derrière les pages produits.
Chaque migration de données entre Magento et BigCommerce se heurte aux trois mêmes points de friction : la manière dont sont structurés les produits proposant des variantes, le mode de calcul des prix spécifiques aux clients et le nombre de groupes de clients auxquels un même compte peut appartenir. Si ces éléments ne sont pas correctement pris en compte, la vitrine en ligne peut sembler fonctionnelle alors que le moteur de tarification sous-jacent est en réalité défaillant.
La cause profonde est d'ordre philosophique. Magento a été conçu pour prendre en charge des catalogues d'une complexité illimitée, basés sur des règles, et il expose cette complexité au commerçant. BigCommerce a été conçu pour un modèle SaaS, où la flexibilité provient principalement d'un ensemble défini de fonctionnalités (variantes, ensembles d'options, listes de prix) plutôt que d'un moteur de règles ouvert. Aucune de ces deux approches n'est erronée. Elles ne correspondent simplement pas l'une à l'autre de manière biunivoque.
C'est particulièrement important dans trois domaines, que nous allons passer en revue un par un :
Une migration de données entre Magento et BigCommerce réalisée à l'aide d'un outil permettra de transférer sans grande difficulté les intitulés, les descriptions et les images des produits. Elle ne permettra toutefois pas de déterminer lesquelles de vos quarante combinaisons d'attributs doivent devenir des variantes et lesquelles doivent constituer des produits distincts. Cette décision nécessite l'intervention d'une personne qui maîtrise les deux plateformes et qui connaît bien votre catalogue.
C'est là qu'un guide de migration doit entrer dans les détails ; prenons donc un exemple concret : un gant de travail proposé en quatre tailles (S, M, L, XL) et trois matériaux (cuir, nitrile, mélange de coton).
Dans Magento, il s’agit d’un produit configurable. Le produit parent est une coque sans prix ni stock propre. La taille et la matière sont des attributs à portée globale, et chacune des douze combinaisons taille-matière existe en tant que produit simple à part entière, avec sa propre référence (SKU), son propre prix et son propre enregistrement de stock. Le prix affiché du produit parent configurable est extrait des produits enfants disponibles en stock ; il n’est stocké nulle part au sein du produit parent lui-même. Si vous avez besoin d’un prix spécifique au client uniquement pour le gant en nitrile taille XL, vous le définissez sur ce produit simple.
Dans BigCommerce, cela correspond à un produit unique proposant deux variantes (taille et matière), ce qui génère les mêmes douze variantes au niveau des références (SKU). Le fonctionnement semble similaire à première vue, mais les contraintes diffèrent. Par défaut, les variantes BigCommerce héritent de la plupart des données au niveau du produit (images, description, champs SEO, champs personnalisés) du produit parent. Seul un ensemble limité de champs (référence, prix, poids, dimensions, stock) peut varier au niveau de la variante, à moins que vous ne créiez manuellement du contenu spécifique à chaque variante.
Voici les points à régler avant que le moindre disque ne soit déplacé :
Aucun de ces éléments ne figure parmi les options à cocher dans la liste des fonctionnalités d’un outil de migration. Il s’agit d’un choix d’architecture du catalogue, pris famille de produits par famille de produits, et c’est l’étape qui prend le plus de temps dans toute migration de Magento vers BigCommerce impliquant un catalogue comptant plus de quelques centaines de références.
C'est là que les catalogues B2B se heurtent à des difficultés particulières, car la tarification B2B se résume rarement à une simple « remise de 10 % pour les grossistes ».
La structure tarifaire de Magento comporte deux niveaux : les groupes de clients (qui contrôlent la visibilité du catalogue et peuvent appliquer des remises à l'échelle de la boutique, par catégorie ou par produit) et les règles de prix du catalogue, qui viennent s'ajouter par-dessus et vous permettent de définir des tarifications conditionnelles (tel groupe de clients, tel ensemble d'attributs, telle plage de dates, tel seuil de quantité) sans aucune limite de complexité. Les commerçants utilisant Adobe Commerce ont souvent des dizaines de règles de prix du catalogue imbriquées les unes dans les autres afin de générer des prix nets spécifiques à chaque client, que nul écran ne peut afficher dans leur intégralité.
La structure tarifaire de BigCommerce comprend des groupes de clients (disponibles à partir du forfait « Growth », permettant d’appliquer des remises à l’échelle de la boutique, par catégorie et par produit) et des listes de prix, disponibles dans les forfaits « Performance » et « Enterprise », qui permettent de définir des prix spécifiques par variante en fonction d’un groupe de clients et d’un canal de vente. La contrainte qui prend souvent les migrations au dépourvu : un groupe de clients ne peut être associé qu’à une seule liste de prix à la fois, et les remises issues des listes de prix et des groupes de clients ne peuvent pas être combinées au sein d’un même groupe. Vous choisissez un seul mécanisme par groupe, et non une combinaison des deux.
Ce qui ne correspond pas parfaitement :
BigCommerce B2B Edition ajoute à ce modèle de tarification des comptes d'entreprise, des rôles d'acheteurs et la création de devis par les commerciaux ; pour de nombreux commerçants, elle remplace ainsi les extensions qui avaient été ajoutées à Magento pour obtenir des fonctionnalités similaires. Elle ne remplace toutefois pas les règles de prix du catalogue. Si votre logique de tarification repose sur des règles conditionnelles plutôt que sur des remises forfaitaires par groupe, prévoyez du temps en temps réel pour la repenser, et pas seulement pour la migrer.
Chaque migration de Magento vers BigCommerce modifie le format de vos URL ; il est donc nécessaire de planifier les redirections.
Magento génère les URL des produits à partir d’une clé d’URL et, éventuellement, du chemin d’accès à la catégorie, ce qui donne généralement un résultat du type /femmes/hauts/sweats-à-capuche/nom-du-produit.html. Les chemins d’accès aux catégories peuvent être activés ou désactivés à l’échelle de la boutique, et chaque réécriture est enregistrée dans la table « url_rewrite », qui constitue votre seule source fiable d’informations sur les résolvations actuelles.
BigCommerce génère les URL différemment : en général, /nom-du-produit/ pour les produits et /nom-de-la-catégorie/ pour les catégories, sans l'extension .html et sans respecter, par défaut, la convention de Magento concernant les chemins d'accès imbriqués pour les catégories.
La méthode de mappage des redirections qui fonctionne vraiment :
La structure des catégories mérite une attention particulière. Si votre arborescence de catégories Magento ne correspond pas exactement au modèle de catégories de BigCommerce, définissez la nouvelle structure avant de générer les redirections, et non après. Rediriger vers une structure que vous êtes sur le point de modifier à nouveau revient à gaspiller le budget d'exploration que vous essayez de préserver.
Plutôt que de citer des extensions spécifiques, qui évoluent trop rapidement pour constituer une référence fiable d'ici un an, voici ce qu'il faut rechercher par catégorie, et comment réagir dans chaque cas :
La tendance est la même dans les sept catégories : l'écosystème d'applications de BigCommerce couvre bien les cas courants, mais mal la logique personnalisée. Si votre site Magento reposait largement sur un développement sur mesure plutôt que sur des extensions prêtes à l'emploi, attendez-vous à un travail de refonte proportionnellement plus important.
Il n'existe pas de durée précise et fiable pour une migration de Magento vers BigCommerce, car celle-ci dépend de la complexité du catalogue et de la logique de tarification, et non pas uniquement du nombre de références. Nous pouvons toutefois vous donner une fourchette par étape, ainsi que les variables qui influencent chaque étape :
Au total : la plupart des migrations B2B que nous évaluons s’étendent sur une période comprise entre 4 et 8 mois, du lancement jusqu’à la stabilisation après la mise en service, et non pas sur les 6 à 8 semaines que laissent entendre certaines campagnes marketing d’outils de migration. D’après notre expérience, le facteur qui influence le plus cette durée n’est pas la taille du catalogue, mais le nombre de règles de tarification conditionnelles existantes et la qualité de leur documentation avant le début de la phase d’analyse.
C'est la partie que la plupart des guides de migration omettent, et c'est précisément pour cette raison que nous pensons que celui-ci mérite d'être lu avant de signer un cahier des charges. La migration d'Adobe vers BigCommerce n'est pas la bonne solution pour tous les commerçants B2B, et nous préférons vous le dire dès maintenant plutôt qu'après le versement d'un acompte.
Voici trois cas de figure dans lesquels nous vous le déconseillons :
Si l’une de ces situations correspond à votre boutique, la prochaine étape la plus judicieuse consiste à réaliser un audit de votre situation actuelle, et non à lancer une migration. Nous avons approfondi ce processus de décision dans notre précédent article de blog, « Les raisons les plus courantes pour lesquelles les entreprises migrent d’Adobe Commerce vers BigCommerce », qui examine en détail les cas où il est plus avantageux financièrement de rester sur Adobe Commerce ou de passer à une plateforme entièrement différente. Nous vous recommandons également de consulter notre page thématique consacrée à la refonte des plateformes de e-commerce si BigCommerce figure parmi les plateformes encore présélectionnées, ainsi que notre guide de migration de BigCommerce vers Magento si vous envisagez le chemin inverse, afin de mieux comprendre comment le problème du modèle de données se présente dans l’autre sens.
Pas directement. Les règles de tarification du catalogue Magento prennent en charge une logique conditionnelle que les listes de prix de BigCommerce ne reproduisent pas à l'identique. La tarification spécifique à chaque client doit être repensée sous forme de groupes de clients associés à des listes de prix ou, dans certains cas, via une application de tarification personnalisée.
Aucun outil de migration ne gère correctement la tarification B2B dès son installation. Ces outils transfèrent correctement les fiches produits et clients. La logique de tarification, en particulier celle qui repose sur les règles de prix du catalogue Magento, nécessite un mappage manuel et des tests par rapport au modèle de liste de prix de BigCommerce.
La plupart des migrations B2B que nous évaluons durent entre 4 et 8 mois, de la phase d'analyse jusqu'à la stabilisation après le lancement ; cette durée dépend principalement de la complexité des règles de tarification et de la structure du catalogue, plutôt que du seul nombre de références.
Les deux plateformes partagent le même modèle de données de base ; les défis structurels abordés dans ce guide s'appliquent donc aux deux. Les marchands utilisant Adobe Commerce disposent de fonctionnalités supplémentaires, telles que les règles de tarification du catalogue avec des conditions complexes et la mise en place progressive du contenu, qui n'existent pas dans Magento Open Source et qui n'auront donc pas besoin d'être remplacées si vous utilisez la version Open Source.
Le plus grand risque consiste à considérer la migration comme un simple exercice d'exportation et d'importation de données. Le véritable risque réside dans les décisions relatives à la structure configurable des produits et à la logique de tarification, qui nécessitent un jugement humain sur votre catalogue spécifique, et non un mappage automatisé des champs.
