Les pièges d’une migration Shopware apparaissent le plus souvent lorsque les enregistrements sont transférés sans les relations de canal de vente, d’héritage, de règles, de contenu et d’extensions qui déterminent leur fonctionnement réel. Un Product peut exister dans l’Administration tout en restant invisible dans un canal de vente, une variante peut hériter du mauvais prix ou des mauvais médias, et une Shopping Experience peut s’afficher sans les liens Product ou Category qu’elle présentait auparavant.
Les modèles d’échec ci-dessous se concentrent sur ces ruptures de relations. Chacun décrit les signes précurseurs, un contrôle préventif, un exemple réaliste et une condition Pass permettant de démontrer que le risque est maîtrisé.
Piège 1 : importer les Products sans leurs affectations aux canaux de vente
Ce qui se passe mal
Les canaux de vente Shopware peuvent représenter des vitrines, canaux API headless, comparateurs de Products et autres destinations. Products, Categories, langues, devises, domaines, méthodes de paiement, méthodes d’expédition, inscription Customer et thèmes peuvent varier selon le canal. Importer le Product sans sa visibilité par canal peut le laisser présent dans l’Administration mais indisponible pour les acheteurs.
Signes précurseurs
| Signe précurseur | Ce qu’il indique |
|---|---|
| La source comporte plusieurs domaines, régions, marques ou flux marketplace. | Un seul canal de vente par défaut préservera probablement mal le modèle opérationnel. |
| La disponibilité Product diffère selon la vitrine ou le canal. | La propriété de l’assortiment doit être représentée par canal. |
| Les Customers sont liés à des canaux spécifiques. | Le contexte Customer n’est pas globalement interchangeable. |
| Categories ou groupes Product dynamiques alimentent les assortiments des canaux. | La visibilité dépend de relations au-delà du seul enregistrement Product. |
Prévention
Créez une carte de propriété des canaux de vente. Préservez l’affectation Product et Category, la langue, la devise, le domaine, le contexte Customer, les relations paiement/expédition, le point d’entrée de navigation et la clé du canal externe. Ne supposez pas que chaque Product appartient à tous les canaux.
Exemple recommandé
Utilisez un Product disponible dans deux vitrines, un Product limité à un canal régional et un Product exporté vers un canal de comparaison. Représentez chaque affectation séparément.
Condition Pass
Chaque Product représentatif apparaît uniquement dans les canaux prévus avec la bonne langue, devise, arborescence Category, accès Customer et la bonne URL ou relation de flux propre au canal.
Piège 2 : aplatir variantes Product, propriétés et héritage
Ce qui se passe mal
Les propriétés Shopware peuvent décrire les Products, soutenir le filtrage et générer des variantes. Les variantes peuvent hériter du prix, du stock, des médias, dimensions, textes et autres valeurs du parent tant que l’héritage n’est pas désactivé. Aplatir la famille peut dupliquer le contenu parent, perdre les numéros Product des enfants ou écraser des valeurs spécifiques aux variantes.
Signes précurseurs
| Signe précurseur | Ce qu’il indique |
|---|---|
| Les combinaisons sont générées à partir d’options de propriétés mais les IDs enfants manquent. | La famille de variantes ne possède pas d’identité stable au niveau des unités vendables. |
| Le parent et les variantes partagent certains champs mais diffèrent sur d’autres. | Les limites entre héritage et remplacement ne sont pas documentées. |
| La source n’identifie pas les valeurs héritées et celles surchargées. | La cible risque de dupliquer des valeurs ou d’effacer des différences voulues. |
| Les propriétés de filtre sont mélangées aux propriétés générant des variantes. | Les attributs de découverte et les combinaisons vendables sont confondus. |
Prévention
Préservez le Product principal, les propriétés génératrices de variantes, les combinaisons d’options, les numéros Product enfants, l’état d’héritage, les exclusions, prix, stock, médias et état actif. Gardez les propriétés descriptives de filtrage distinctes de celles qui définissent réellement les variantes vendables.
Exemple recommandé
Utilisez une chemise dont les variantes héritent de la description mais remplacent le numéro Product, le prix, le stock et l’image. Incluez une combinaison couleur-taille exclue.
Condition Pass
La famille représentative contient les bonnes variantes et exclusions, les champs hérités restent hérités, les champs remplacés conservent les valeurs enfants et les propriétés de filtre ne créent pas de variantes involontaires.
Piège 3 : recréer les prix sans leurs conditions Rule Builder
Ce qui se passe mal
Les conditions Rule Builder peuvent influencer prix, promotions, expédition, paiement, contenu et autres comportements commerciaux. Copier uniquement le prix ou la remise obtenus supprime le groupe Customer, canal, devise, quantité, période, panier ou contexte d’Order qui explique quand la valeur s’applique.
Signes précurseurs
| Signe précurseur | Ce qu’il indique |
|---|---|
| Plusieurs prix existent pour un même Product sans audience clairement identifiée. | Les conditions qui sélectionnent le prix manquent. |
| Les promotions sont décrites par leur nom mais pas par leurs conditions et priorités. | La logique Rule Builder ne peut pas être reconstruite depuis les libellés seuls. |
| La disponibilité expédition/paiement dépend de propriétés Customer ou panier. | Les méthodes opérationnelles sont gouvernées par des règles, pas seulement par les enregistrements migrés. |
| Des règles référencent groupes Customer, tags, canaux ou champs personnalisés. | Les données dépendantes de la règle doivent rester reliées. |
Prévention
Modélisez la règle séparément de son résultat. Préservez nom, priorité, conditions, opérateurs, entités référencées et module qui consomme la règle. Réaffectez les références Customer, groupe ou canal lorsque les IDs source ne peuvent pas être conservés.
Exemple recommandé
Utilisez un prix par quantité réservé à un groupe Customer grossiste et une règle d’expédition limitée à un canal régional et à une valeur de panier. Préservez conditions et références plutôt que les seules valeurs finales.
Condition Pass
Chaque règle représentative s’applique uniquement dans son contexte prévu, reste inactive hors de ce contexte et référence des Customers, groupes, Products, canaux, devises et champs personnalisés valides dans la cible.
Piège 4 : traiter arborescences de Categories et groupes Product dynamiques comme une même structure
Ce qui se passe mal
Les Categories Shopware peuvent structurer la navigation et le contenu, tandis que les groupes Product dynamiques sélectionnent des Products selon des règles. Une collection source ou un groupe de merchandising peut être pris à tort pour une Category permanente, ou une Category peut être reconstruite sous forme de règle ne fournissant plus hiérarchie, contenu ou route.
Signes précurseurs
- Les collections source combinent adhésion manuelle et sélection par règles.
- Une Category existe principalement pour présenter des Products de campagne.
- Les Products apparaissent dans la recherche mais pas dans la branche de navigation prévue.
- Les groupes dynamiques dépendent de propriétés ou champs personnalisés non normalisés.
Prévention
Classez chaque regroupement selon son propriétaire réel : hiérarchie et route, appartenance Product manuelle, règle de sélection dynamique, Shopping Experience ou assortiment par canal. Préservez les champs utilisés par les groupes dynamiques et les relations Category utilisées par la navigation.
Exemple recommandé
Représentez une Category permanente « Chaussures », un groupe dynamique « Stock faible » et une Category de landing page saisonnière alimentée par un groupe dynamique comme trois structures liées mais distinctes.
Condition Pass
Les Categories permanentes conservent hiérarchie et routes, les groupes dynamiques retournent les Products prévus selon des conditions valides et les mises en page de campagne référencent le bon regroupement sans dupliquer la propriété Product.
Piège 5 : copier les Shopping Experiences sans leur contexte d’affectation
Ce qui se passe mal
Les Shopping Experiences peuvent créer landing pages, pages boutique, mises en page Category et mises en page Product. Leurs sections, blocs, éléments, médias, liens et affectations de données dépendent du type de page et du canal de vente. Copier le contenu de mise en page sans sa Category, son Product ou son canal peut produire une page visuellement correcte mais inaccessible ou trompeuse.
Signes précurseurs
| Signe précurseur | Ce qu’il indique |
|---|---|
| Des mises en page contiennent des liens Product ou Category pointant vers des IDs source. | Le contenu Shopping Experience contient des relations internes rompues. |
| Les pages Category utilisent des mises en page différentes selon le canal. | L’affectation de mise en page dépend du canal. |
| Des éléments de page Product contiennent des surcharges propres à certains enregistrements. | Un template générique ne peut pas reproduire tout le comportement de la vitrine. |
| Des landing pages existent sans documentation de navigation ou route directe. | Le contenu peut migrer sans chemin de découverte exploitable. |
Prévention
Préservez type de mise en page, sections, blocs, éléments, médias, contenu traduit, liens, Categories ou Products affectés, compatibilité de canal et surcharges propres aux enregistrements. Remplacez les IDs source par les références d’entités de destination.
Exemple recommandé
Utilisez une mise en page Category, une landing page autonome et une mise en page Product avec surcharge de texte propre à un Product. Suivez chaque Product, Category, média et route référencés.
Condition Pass
Chaque Shopping Experience représentative est accessible par la route prévue, s’affiche dans le bon canal et la bonne langue et présente des Products, Categories, médias et surcharges valides dans la destination.
Piège 6 : perdre les définitions des champs personnalisés ou l’héritage linguistique
Ce qui se passe mal
Les champs personnalisés Shopware peuvent étendre Products, Categories, Customers, Orders et d’autres entités. La valeur dépend d’un ensemble de champs, d’un type, d’une affectation, d’une traduction et du template ou de la règle qui l’utilise. Copier les valeurs sans leurs définitions crée des données invisibles ou inutilisables. Renseigner uniquement une valeur traduite peut aussi rompre l’héritage depuis la langue par défaut.
Signes précurseurs
- Des valeurs de champs personnalisés existent mais leur ensemble de champs n’est pas documenté.
- Plusieurs langues comportent des valeurs différentes ou manquantes.
- Des règles ou templates référencent des noms techniques de champs personnalisés.
- Des champs créés par des apps sont mélangés à des champs créés par le marchand.
Prévention
Préservez identité de l’ensemble, nom technique, libellé, type, valeurs autorisées, affectation d’entité, valeur de langue par défaut, remplacements traduits et chaque référence Rule Builder, template ou intégration. Gardez les données personnalisées détenues par une application sous leur propriétaire réel.
Exemple recommandé
Utilisez un champ de conformité Product hérité entre langues et un libellé marketing localisé qui remplace volontairement la valeur par défaut.
Condition Pass
Les champs apparaissent sur les bonnes entités, conservent des définitions et valeurs autorisées exploitables, héritent de la langue par défaut lorsque prévu et restent disponibles pour chaque règle, template ou intégration qui les utilise.
Piège 7 : conserver l’en-tête d’Order mais perdre les états, transactions et livraisons
Ce qui se passe mal
Les Orders Shopware peuvent contenir lignes, Customers, adresses, devises, taxes, remises, transactions, livraisons, documents, statuts et références externes. Importer uniquement l’en-tête et le total supprime les transitions et enregistrements opérationnels qui expliquent le paiement et le traitement logistique.
Signes précurseurs
- Les statuts de paiement et de livraison sont compressés en un seul statut générique d’Order.
- Expéditions, suivi, remboursements ou documents sont stockés séparément.
- Les numéros Product des variantes enfants manquent dans les lignes d’Order.
- Des références ERP ou paiement externes n’existent que dans des données d’extension.
Prévention
Préservez l’instantané de l’Order, les lignes, l’identité de variante, les adresses, totaux, taxes, promotions, état de transaction, état de livraison, suivi, documents, commentaires et IDs externes. Gardez l’historique des statuts indépendant des règles et méthodes actuellement actives.
Exemple recommandé
Utilisez un Order payé et expédié, un Order partiellement traité et un Order remboursé contenant une variante et une promotion.
Condition Pass
Chaque Order représentatif reste compréhensible pour le service client, la finance et le traitement logistique, avec des relations valides entre lignes, transactions, livraisons, documents, statuts et références externes.
Piège 8 : reconstruire les URL SEO sans contexte de canal et de canonical
Ce qui se passe mal
Les templates d’URL SEO Shopware et les chemins générés peuvent différer selon le canal de vente. Les Products avec variantes peuvent également utiliser une URL canonical commune ou des chemins propres aux variantes. Recréer les slugs sans template, Category principale, chemin historique et contexte de canal peut produire des pages en double ou rediriger les visiteurs vers la mauvaise vitrine.
Signes précurseurs
- Un même Product possède des chemins différents selon le canal ou la langue.
- Les URL source dépendent de breadcrumbs Category ou de l’affectation d’une Category principale.
- Les pages de variantes utilisent un comportement canonical mixte.
- Les anciennes URL ne sont pas reliées aux routes de destination.
Prévention
Préservez chemins source, Product ou Category de destination, canal, langue, Category principale, réglage canonical et relation de redirection. Reconstruisez les index SEO après toute modification de template afin que les chemins générés suivent les règles prévues.
Exemple recommandé
Utilisez un Product affecté à deux Categories dans deux canaux, plus une famille de variantes utilisant une seule URL Product canonical. Enregistrez chaque chemin source important et sa destination prévue.
Condition Pass
Les routes représentatives se résolvent dans le bon canal et la bonne langue, le comportement canonical reste cohérent entre variantes et les anciens chemins redirigent vers le Product ou la Category actuelle prévus.
Piège 9 : copier les données d’extension sans leur entité ni leur cycle de vie
Ce qui se passe mal
Les extensions et applications Shopware peuvent ajouter entités personnalisées, champs, règles, enregistrements API, processus planifiés, composants de vitrine, données de paiement ou d’expédition, abonnements, liens marketplace et états d’intégration. Copier des champs dans des entités standard ne préserve ni le cycle de vie de l’extension ni ses références.
Signes précurseurs
- Des champs techniques utilisent un préfixe d’app ou de plugin.
- Des entités personnalisées référencent Products, Customers ou Orders via des IDs internes.
- Les équipes utilisent des données qui n’ont aucun module standard dans l’Administration.
- Un système externe met à jour la valeur via API ou webhook.
Prévention
Créez une carte de propriété pour chaque extension. Identifiez ses entités, références parentes, champs techniques, configuration, IDs externes, sens de mise à jour et destination continue. Séparez les éléments historiques de l’état opérationnel en production.
Exemple recommandé
Suivez un enregistrement d’abonnement, une annonce marketplace et un identifiant ERP Product depuis l’entité d’extension jusqu’à l’enregistrement Shopware principal et au système externe propriétaire.
Condition Pass
Chaque enregistrement d’extension conservé possède une entité de destination définie, des références parentes valides, des identifiants externes stables et une application ou intégration capable de l’interpréter et de le maintenir.
Piège 10 : supposer que des données Product correctes garantissent des résultats de recherche corrects
Ce qui se passe mal
La recherche et l’indexation Shopware peuvent dépendre des champs Product recherchables, numéros Product, mots-clés, propriétés, fabricants, Categories, synonymes, actions et configurations d’index propres aux extensions. Des Products importés peuvent exister et être actifs tout en étant absents des résultats ou mal classés si les champs indexés, alias ou traitements de file d’attente sont incomplets.
Signes précurseurs
| Signe précurseur | Ce qu’il indique |
|---|---|
| Les Products sont visibles par URL directe mais absents de la recherche. | L’enregistrement existe mais l’indexation ou la configuration de recherche est incomplète. |
| Les numéros Product, EAN ou valeurs personnalisées ne sont pas recherchables. | Les champs requis ne font pas partie de la configuration active. |
| Les synonymes et actions de redirection de recherche n’ont pas été inventoriés. | Le comportement de merchandising ne suivra pas l’intention source. |
| La création de l’index se termine mais les alias ou traitements en file d’attente restent incomplets. | L’index généré n’est pas encore celui qui sert les requêtes de la vitrine. |
Prévention
Préservez mots-clés de recherche, visibilité Product, champs recherchables, propriétés, données fabricant, synonymes, actions et éventuelle configuration Advanced Search. Incluez création d’index, traitement des files, création des alias et responsabilité de l’indexation continue dans le plan de migration.
Exemple recommandé
Utilisez un Product trouvé par son nom, un par son numéro Product, un dépendant d’un synonyme et un ciblé par une action de recherche. Suivez-les dans les champs et index configurés.
Condition Pass
Les Products représentatifs apparaissent via les noms, numéros, propriétés, fabricants et synonymes prévus ; les actions de recherche mènent vers des destinations valides et les index et alias nécessaires restent à jour.
Priorités communes de prévention
Prévenir les pièges Shopware exige de garder les données Product reliées aux canaux de vente, variantes héritées, conditions Rule Builder, Shopping Experiences, champs personnalisés sensibles à la langue, états historiques des Orders, routes, recherche et propriétaires d’extensions. Un enregistrement Product correct ne compense pas l’absence d’un canal, d’une règle, d’une mise en page ou d’une relation d’indexation.
| Niveau de prévention | Contrôle requis |
|---|---|
| Propriété des canaux | Relier Products, Customers, Categories, domaines, langues et visibilité au bon canal. |
| Contrôle de l’héritage | Distinguer les valeurs héritées du parent des surcharges au niveau variante. |
| Dépendances de règles | Préserver les données utilisées par les conditions Rule Builder pour prix, promotions, paiement et expédition. |
| Affectation des expériences | Maintenir les Shopping Experiences reliées au bon type de page, à la bonne entité, route et au bon canal. |
| Diffusion par la recherche | Aligner champs recherchables, synonymes, indexation, alias et traitements en file d’attente. |
Conclusion
Les migrations Shopware échouent lorsque des structures de plateforme interconnectées sont aplaties en enregistrements isolés. Les canaux déterminent la disponibilité, les propriétés génèrent les variantes, les règles gouvernent le fonctionnement commercial, les Shopping Experiences apportent le contexte et les extensions peuvent posséder des domaines métier complets.
La migration la plus sûre préserve chaque relation et la démontre au moyen d’une condition Pass spécifique à la plateforme. Lorsque Products, canaux, règles, contenu, Orders, URL, recherche et extensions sont cohérents, la boutique migrée fonctionne comme un environnement Shopware complet plutôt que comme une simple collection d’entités importées.
Questions fréquentes
Pourquoi un Product peut-il exister dans Shopware tout en restant indisponible pour les acheteurs ?
Le Product peut être inactif, masqué, exclu du canal concerné, absent de l’assortiment Category du canal ou privé du contexte de langue, devise, domaine ou visibilité nécessaire à cette vitrine.
Les propriétés Shopware correspondent-elles toujours à des variantes Product ?
Non. Les propriétés peuvent décrire et filtrer les Products sans générer de variantes. Seules les options de propriétés sélectionnées par le générateur de variantes définissent des combinaisons vendables.
Pourquoi faut-il migrer les conditions Rule Builder séparément des prix ou remises obtenus ?
Le résultat n’est valide que sous des conditions précises de Customer, canal, devise, quantité, panier, période ou Order. Copier la valeur sans la règle l’applique trop largement ou ne l’applique plus du tout.
Peut-on migrer les Shopping Experiences comme de simples CMS Pages ?
Pas de manière fiable. Leur type de page, sections, blocs, éléments, affectations, contexte de canal, liens et surcharges propres aux Products ou Categories déterminent où et comment la mise en page fonctionne.
Comment gérer les champs personnalisés Shopware entre plusieurs langues ?
Préservez d’abord la définition du champ et sa valeur dans la langue par défaut, puis conservez les remplacements traduits intentionnels. Cela maintient un héritage exploitable pour les templates, règles et intégrations.
Pourquoi des Products Shopware corrects peuvent-ils rester absents de la recherche ?
Les résultats dépendent de la visibilité, des champs recherchables, mots-clés, propriétés, synonymes, actions, création des index, traitement des files, alias et configuration d’extensions. Des enregistrements Product corrects ne garantissent pas à eux seuls une découverte correctement indexée.