Choisir la bonne approche de migration vers Adobe Commerce exige une décision fondée sur le modèle d’exploitation, et pas seulement sur le nombre d’enregistrements. Adobe Commerce peut combiner Products configurables, plusieurs websites, stores et store views, comptes d’entreprise B2B, catalogues partagés, tarification propre à certaines entreprises, groupes de Customers, contenu planifié, attributs personnalisés, intégrations et données détenues par des extensions. L’approche de service doit distinguer les structures qui relèvent de données standard prises en charge, celles qui nécessitent une configuration côté cible, celles qui peuvent être traitées au moyen d’Add-ons à périmètre délimité et celles qui exigent un examen adapté via Custom Service.
Un projet Adobe Commerce de grande taille n’exige pas automatiquement le service le plus complexe. Standard Service peut rester approprié lorsque le parcours de migration est pris en charge, que les données de la source utilisent des structures reconnaissables et que le client peut exploiter et valider le service de façon autonome. Managed Service devient utile lorsque la coordination et la charge de validation sont élevées. Les Add-ons répondent à des besoins précis et pris en charge de filtrage d’enregistrements, transformation de valeurs ou remapping de champs. Custom Service constitue la bonne voie d’escalade lorsque le résultat attendu dépend d’enregistrements non pris en charge, modules personnalisés, transformations spécifiques, structures B2B non standard, identifiants de systèmes externes ou logique de migration personnalisée.
Dans les services de migration Next-Cart, ces éléments permettent de distinguer le périmètre pris en charge, la responsabilité d’exécution, les besoins délimités relevant des Add-ons et les exigences Adobe Commerce nécessitant un traitement adapté.
Commencer par le modèle d’exploitation Adobe Commerce
Les projets Adobe Commerce doivent être classifiés selon le modèle d’exploitation que la plateforme cible devra soutenir. Une boutique B2C monomarque avec un seul website et des Products conventionnels pose une décision de migration très différente d’une implémentation d’entreprise comportant plusieurs websites, store views régionales, comptes d’entreprise, catalogues partagés, tarification propre aux acheteurs et systèmes ERP ou PIM étroitement connectés.
Adobe Commerce utilise une hiérarchie website, store et store view. Les websites peuvent disposer de domaines distincts et de périmètres de processus de commande distincts. Les stores peuvent utiliser des Categories racines et catalogues différents. Les store views servent souvent aux variations de langue ou de présentation. Les catalogues partagés B2B peuvent contrôler quels Products et prix sont visibles pour les entreprises auxquelles ils sont affectés. Ces structures appartiennent à l’architecture cible ; ce ne sont pas de simples libellés ajoutés aux données migrées.
| Question sur le modèle d’exploitation | Signal de complexité plus faible | Signal de complexité plus élevée |
|---|---|---|
| Périmètre website et store | Un website, un store, peu de store views | Plusieurs websites, stores régionaux, Categories racines différentes, domaines séparés ou configuration propre à certains périmètres |
| Structure de catalogue | Products simples et configurables utilisant des attributs reconnaissables | Bundles, Products grouped, types personnalisés, jeux d’attributs complexes, contenu planifié ou relations créées par des extensions |
| Modèle client | Customers et groupes Customer ordinaires | Entreprises, utilisateurs d’entreprise, catalogues partagés, tarification négociée, autorisations, crédit ou processus d’approbation |
| Responsabilité d’intégration | Peu de références externes | ERP, PIM, OMS, WMS, CRM, marketplace, fiscalité, paiement ou systèmes de traitement logistique contrôlant des valeurs critiques |
| Personnalisation | Champs plateforme standards et enregistrements pris en charge | Modules personnalisés, colonnes de base de données, tables d’extension, API personnalisées, processus spécifiques ou identifiants externes |
L’approche doit être choisie une fois ce modèle documenté. Sinon, un projet peut être cadré comme simple transfert de catalogue alors que l’entreprise attend en réalité un fonctionnement B2B et multi-site de niveau entreprise immédiatement opérationnel.
Quand Standard Service peut être le bon choix
Standard Service convient lorsque le parcours entre la plateforme source et Adobe Commerce est pris en charge, que les données sont accessibles via la connexion prise en charge et que le résultat attendu reste dans le fonctionnement standard de migration. Avec ce service Next-Cart, le client reste responsable de la préparation, des informations de connexion, des choix de configuration, des décisions d’exécution et de la validation.
Un bon candidat à Standard Service présente généralement :
- un périmètre clair pour Products, Customers, Orders et contenus ;
- des types de Products et relations de variantes reconnaissables ;
- des SKU et identifiants Product cohérents ;
- des Categories, attributs et valeurs d’attributs compréhensibles ;
- des Customers et adresses ordinaires ;
- des Orders historiques qui ne dépendent pas d’un contexte caché appartenant à des systèmes externes ;
- une destination website/store/store view définie ;
- aucune attente selon laquelle extensions, modules B2B ou intégrations seraient reconstruits par la migration standard des enregistrements ;
- une équipe capable d’examiner en détail les résultats de Demo Migration et Full Migration.
Standard Service ne doit pas être écarté simplement parce que le catalogue est volumineux. Le volume d’enregistrements relève du Entity Points Plan sélectionné. La question la plus importante est de savoir si les données restent dans des structures prises en charge et si le client peut valider le résultat de manière autonome.
Le service devient moins adapté lorsque les Products dépendent de types personnalisés, que la tarification d’entreprise est stockée hors de structures B2B reconnaissables, que des identifiants externes contrôlent le traitement logistique ou que le marchand attend de la configuration cible et de l’implémentation de modules qu’elles découlent automatiquement du transfert des données.
Quand Managed Service est plus sûr
Managed Service convient lorsque la migration reste largement dans un fonctionnement pris en charge mais que le client a besoin que les spécialistes Next-Cart prennent en charge l’exécution et fournissent une coordination structurée. Cela peut réduire la pression opérationnelle dans les projets avec gros catalogues, plusieurs équipes métier, fenêtres de lancement strictes ou responsabilités de validation importantes.
Managed Service est souvent plus sûr lorsque :
- le volume de catalogue, Customers et Orders crée une charge de revue importante ;
- plusieurs websites, stores ou store views doivent être validés par des responsables différents ;
- les équipes métier ont besoin d’un calendrier de migration coordonné ;
- les parties prenantes B2B, régionales ou par canal doivent approuver des échantillons représentatifs ;
- les données sources sont compréhensibles mais suffisamment incohérentes pour nécessiter une revue opérationnelle attentive ;
- le marchand ne peut pas gérer seul avec confiance la configuration et l’exécution de la migration ;
- la fenêtre de lancement exige un suivi maîtrisé des problèmes et des escalades.
Managed Service n’élargit pas automatiquement la prise en charge standard. Il change la responsabilité de l’exécution et de la coordination. Si le résultat attendu inclut des structures d’entreprise non prises en charge, données de modules personnalisés, transformations spécifiques ou relations externes non standard, Custom Service peut rester nécessaire pour ces exigences.
Une règle de décision utile consiste à séparer charge d’exécution et charge de personnalisation. Managed Service traite la première. Custom Service traite la seconde. Certains projets d’entreprise ont besoin des deux : exécution managée et personnalisation cadrée séparément.
Où interviennent les Add-ons
Les Add-ons sont adaptés lorsque la migration principale reste standard mais qu’un besoin pris en charge et bien délimité modifie le résultat attendu. Pour Adobe Commerce, les contrôles pertinents couvrent notamment le filtrage d’enregistrements à partir de conditions sur les champs de chaque type de données, la transformation de valeurs par expression et le remapping de champs sources pris en charge.
Exemples dans Adobe Commerce :
- appliquer des conditions sur les champs Product pour exclure des Products inactifs ou obsolètes ;
- appliquer des conditions sur les champs Customer ou Order pour exclure des Customers de test ou des Orders historiques non pertinents ;
- utiliser des expressions pour transformer des valeurs de champs prises en charge pendant la migration ;
- remapper des champs sources standards et pris en charge de Product, Category, Customer ou Order vers des champs cibles compatibles et pris en charge, sans modifier la valeur ;
- préserver certains contenus ou informations SEO lorsque le parcours de migration le prend en charge ;
- utiliser Data Filter, Advanced Data Mapping ou Data Transformation pour un besoin pris en charge et clairement défini.
Les Add-ons ne doivent pas devenir un terme générique pour toute exigence complexe d’Adobe Commerce. Remapper un champ pris en charge est différent d’extraire des enregistrements depuis un module B2B personnalisé. Filtrer d’anciens Orders au moyen d’une condition sur un champ Order est différent de reconstruire un processus d’approbation d’entreprise. Le premier besoin peut relever d’un Add-on ; le second nécessite un examen Custom Service ou une implémentation cible séparée.
La bonne frontière est la suivante : le besoin reste-t-il à l’intérieur du fonctionnement de migration pris en charge ? Si oui, un Add-on peut suffire. S’il nécessite extraction, transformation, logique ou interprétation de responsabilité non standard, il relève de Custom Service.
Quand envisager Custom Service
Custom Service doit être envisagé lorsque le résultat requis ne peut pas être obtenu uniquement avec les enregistrements standards pris en charge et des Add-ons délimités. Dans Adobe Commerce, cette pression apparaît souvent à cause de l’écosystème d’extensions, des structures B2B, du périmètre multi-site et des dépendances aux systèmes externes.
Signaux d’escalade typiques :
- types ou relations de Products personnalisés créés par des modules ;
- attributs personnalisés nécessitant une transformation cible spécifique ;
- comptes d’entreprise, utilisateurs d’entreprise, catalogues partagés ou tarification négociée stockés dans des structures non standard ;
- champs personnalisés du processus de commande ou données d’Orders stockées dans des tables d’extension ;
- identifiants ERP, PIM, OMS, WMS, CRM, fiscaux ou logistiques devant être conservés dans un champ cible précis ;
- règles spécifiques d’affectation website/store/store view ;
- enregistrements non pris en charge provenant de modules marketplace, abonnement, fidélité, devis, approbation ou retours ;
- colonnes de base de données, API ou tables d’intégration personnalisées ;
- présence d’une Custom Platform d’un côté ou de l’autre du parcours de migration ;
- exigences modifiant la logique standard de migration.
Custom Service n’inclut pas automatiquement le développement de modules Adobe Commerce, l’installation d’extensions, la configuration B2B, la création de catalogues partagés, la construction de websites ou store views, l’implémentation de thème, la configuration du paiement ou de la livraison, le déploiement d’intégrations ni la reconstruction complète de la boutique cible. Ces responsabilités ne sont incluses que si elles sont explicitement convenues dans le périmètre du service.
Entity Points et planification du périmètre d’entreprise
Entity Points fournit un cadre de capacité pour les enregistrements éligibles migrés. Lors d’activités Adobe Commerce ultérieures, les enregistrements éligibles déjà comptabilisés restent comptés une seule fois sur le même parcours de migration ; la complexité des websites, store views, structures B2B et extensions est évaluée séparément. Categories, attributs, entreprises, catalogues partagés, websites, store views, champs personnalisés, modules et identifiants externes peuvent augmenter la complexité sans devenir des types d’enregistrements Entity Points distincts.
Cette distinction est essentielle pour Adobe Commerce. Deux projets peuvent utiliser le même Entity Points Plan tout en exigeant des approches de service très différentes. Un grand catalogue de Products ordinaires peut convenir à Standard Service. Un catalogue plus petit peut nécessiter Custom Service si chaque Product dépend d’attributs personnalisés, de prix propres à l’entreprise ou d’identifiants contrôlés par une intégration.
Lors d’activités Adobe Commerce ultérieures, les enregistrements éligibles déjà comptés restent comptés une seule fois sur le même parcours ; les nouveaux Products, Customers, Orders ou Blog Posts éligibles peuvent consommer des Entity Points lorsqu’ils sont migrés pour la première fois.
La planification doit répondre aux questions suivantes :
| Question de planification | Pourquoi elle compte |
|---|---|
| Quels enregistrements éligibles appartiennent au périmètre approuvé ? | Détermine le Entity Points Plan approprié. |
| Quels enregistrements sont obsolètes, dupliqués ou inutiles au lancement ? | Aide à décider du filtrage et évite de consommer inutilement de la capacité. |
| Quels enregistrements ont déjà été comptés dans la migration achetée et son parcours fixe ? | Évite les hypothèses erronées de double consommation. |
| Quels nouveaux enregistrements éligibles peuvent être créés avant le lancement ? | Aide à planifier la capacité des migrations ultérieures. |
| Quelles structures complexes ne constituent pas des types Entity Points séparés ? | Maintient la distinction entre complexité et volume. |
Entity Points aide à dimensionner la migration. Il ne prouve pas que les exigences B2B, multi-site, extensions ou intégrations sont prises en charge.
Ce que Demo Migration doit démontrer
Demo Migration doit tester la décision d’approche avec des enregistrements représentatifs et difficiles. Ne sélectionner que des Products simples peut créer une fausse confiance dans un projet Adobe Commerce.
L’échantillon doit inclure, lorsque pertinent :
- Products simple, configurable, bundle, grouped, virtual ou downloadable ;
- Products avec attributs complexes et valeurs propres à certaines store views ;
- Categories utilisées par différents stores ou catalogues racines ;
- Customers issus de groupes importants ou de contextes d’entreprise ;
- Orders comportant remises, fiscalité, remboursements, statuts inhabituels ou identifiants externes ;
- CMS Pages, Blog Posts et enregistrements sensibles aux URL qui sont prioritaires ;
- données influencées par des extensions ou intégrations ;
- exemples provenant de chaque website, store ou store view important pour le lancement.
Demo Migration doit répondre à quatre questions :
- Les enregistrements standards sont-ils représentés correctement ?
- Les relations de périmètre de boutique et B2B conservent-elles leur sens ?
- Quels écarts peuvent être résolus par une configuration prise en charge ou des Add-ons ?
- Quels écarts nécessitent Custom Service ou une implémentation cible séparée ?
Une Demo Migration réussie n’est pas une simple comparaison de nombres d’enregistrements. Elle fournit les éléments permettant de vérifier que l’approche choisie est suffisamment robuste avant Full Migration. Si l’échantillon révèle des structures non prises en charge ou des responsabilités cachées, l’approche doit être modifiée avant d’exécuter le périmètre complet.
Additional Migration Options pour Adobe Commerce
Les Additional Migration Options prennent en charge les activités de migration ultérieures lorsque la source reste active, que la configuration cible change ou que le marchand a besoin d’un résultat de migration différent. L’action choisie doit refléter la validité de la configuration précédemment acceptée.
| Action actuelle | Situation adaptée | Points à revalider dans Adobe Commerce |
|---|---|---|
| Continue the Migration with the Last Used Configuration | La mise en correspondance et le périmètre acceptés restent valides et l’activité plus récente de la source doit être traitée avec la même configuration. | Nouveaux Products, Customers, Orders, Blog Posts, valeurs liées au périmètre de boutique, URL et identifiants connectés aux intégrations. |
| Continue the Migration with a New Configuration | Le parcours de migration reste identique, mais filtrage, mise en correspondance, affectation aux stores ou autres réglages pris en charge doivent changer. | Structures Product modifiées, affectation website/store/store view, mise en correspondance des attributs, périmètre B2B, contenu et comportement des URL. |
| Perform a New Migration | Le marchand a besoin d’un résultat de migration distinct au lieu de poursuivre la configuration précédente. | Périmètre cible complet, hiérarchie B2B et stores, modèle Product, responsabilité des intégrations, SEO et critères d’acceptation. |
Ces actions n’implémentent pas automatiquement modules Adobe Commerce, catalogues partagés, autorisations d’entreprise, intégrations externes, thèmes ni configuration cible. Elles fonctionnent dans le périmètre du service de migration convenu et conservent inchangé le parcours plateforme source → plateforme cible acheté. Une plateforme source ou plateforme cible différente nécessite l’achat d’une migration séparée.
Décision finale sur l’approche de service
La meilleure approche Adobe Commerce est le service le plus léger capable de préserver le sens métier requis et de produire un résultat que le marchand peut valider avec confiance.
| Éléments observés | Approche probable |
|---|---|
| Enregistrements pris en charge, structures ordinaires, périmètre clair, exécution et validation pilotées par le client | Standard Service |
| Périmètre pris en charge mais coordination, validation ou calendrier de lancement exigeants | Managed Service |
| Migration standard avec besoins délimités de filtrage d’enregistrements, transformation de valeurs ou remapping de champs | Standard Service ou Managed Service avec Add-ons |
| Enregistrements non pris en charge, modules personnalisés, transformations spécifiques, complexité B2B ou intégrations hors fonctionnement standard | Custom Service, éventuellement avec Expert Handle et Add-ons convenus |
La décision doit être documentée avant Full Migration et confirmée par les éléments issus de Demo Migration. Un projet ne doit pas être monté en gamme simplement parce qu’Adobe Commerce est une plateforme d’entreprise, ni rester sur une approche légère lorsque le résultat cible accepté dépend de structures d’entreprise non prises en charge.
Conclusion
Le choix de l’approche de migration vers Adobe Commerce dépend de la relation entre volume des enregistrements, structure d’exploitation d’entreprise, responsabilité d’exécution et personnalisation. Standard Service peut convenir aux parcours de migration propres et pris en charge. Managed Service aide lorsque la coordination et la charge de validation sont fortes. Les Add-ons répondent à des besoins délimités et pris en charge. Custom Service traite les exigences adaptées et non standard.
La décision finale doit tenir compte de la hiérarchie website/store/store view, des types de Products, du contexte des entreprises B2B et catalogues partagés, des systèmes externes, des Entity Points et des éléments produits par Demo Migration. Les Additional Migration Options doivent ensuite être choisies selon que la configuration acceptée reste valide, doit être ajustée ou doit être remplacée par un nouveau résultat de migration.
Questions fréquentes
Un grand catalogue Adobe Commerce peut-il utiliser Standard Service ?
Oui. Le volume seul ne détermine pas l’approche. Un grand catalogue peut utiliser Standard Service lorsque le parcours est pris en charge, que les structures Product sont reconnaissables et que le client peut exécuter et valider le service. Entity Points couvre la capacité des enregistrements éligibles, tandis que la complexité structurelle est évaluée séparément.
Quand Managed Service est-il plus approprié pour Adobe Commerce ?
Managed Service est utile lorsque la migration reste dans le fonctionnement pris en charge mais que l’exécution, la coordination ou la validation sont exigeantes. Il est particulièrement pertinent pour les projets impliquant plusieurs équipes, plusieurs périmètres de vitrines, de fortes charges de revue et des calendriers de lancement stricts.
Les Add-ons couvrent-ils les modules Adobe Commerce personnalisés ?
Pas en général. Les Add-ons couvrent des besoins délimités dans le fonctionnement de migration pris en charge. Les données stockées dans des modules personnalisés, tables d’extension, structures B2B spécifiques ou systèmes externes nécessitent généralement un examen Custom Service.
Que doit démontrer Demo Migration pour Adobe Commerce ?
Elle doit démontrer que les Products, Customers, Orders, contenus, périmètres de boutique, relations B2B, URL et champs liés aux intégrations restent compréhensibles et exploitables. Elle doit aussi révéler si les écarts relèvent de la configuration, des Add-ons, de Custom Service ou d’une implémentation cible séparée.
Quelle Additional Migration Option faut-il sélectionner ?
Utilisez Continue the Migration with the Last Used Configuration lorsque la configuration acceptée reste valide, Continue the Migration with a New Configuration lorsque des réglages pris en charge doivent changer, et Perform a New Migration lorsqu’un résultat distinct est requis et qu’une revalidation complète est nécessaire.