Si Shopware est retenu comme plateforme cible, la préparation doit définir comment les enregistrements de la boutique source se relieront aux canaux de vente, produits et variantes, propriétés, champs personnalisés, clients, commandes, Shopping Experiences, règles, médias, URL, extensions et systèmes externes. Un export complet ne suffit pas lorsque le même produit peut apparaître dans plusieurs canaux, que les variantes héritent ou remplacent des valeurs parentes, que les propriétés peuvent servir au filtrage comme à la génération de variantes et que le fonctionnement commercial dépend de règles affectées.
Chaque action de préparation doit avoir un responsable, un élément de validation et une condition de préparation atteinte. Le dossier doit aussi distinguer les éléments issus de la source de l’implémentation cible. Les relations produit, le contexte des commandes historiques, les URL existantes, les identifiants externes et les enregistrements appartenant aux extensions relèvent de la préparation de la migration ; le paiement, la livraison, la fiscalité, les processus, le thème et le fonctionnement des canaux en production restent des décisions d’implémentation côté cible.
Sécuriser les accès Shopware, hébergement, base de données et fichiers
Confirmez l’accès à l’administration Shopware, à l’hébergement ou au cloud, à la base de données lorsqu’elle est disponible, aux fichiers applicatifs, au stockage des médias, aux tâches planifiées, aux identifiants d’intégration et à la gestion des extensions. Documentez la version Shopware, le modèle de déploiement, PHP et la base de données pour les installations auto-hébergées, ainsi que les canaux, langues, devises, extensions, code spécifique et systèmes connectés.
| Action de préparation | Responsable | Élément de validation | Condition de préparation |
|---|---|---|---|
| Confirmer l’accès administratif | Administrateur Shopware | Compte fonctionnel et synthèse des droits | Produits, clients, commandes, règles, canaux, extensions et contenus peuvent être inspectés. |
| Créer des sauvegardes restaurables de la source | Responsable infrastructure | Export base de données, archive fichiers/médias, archive de configuration et responsable de restauration | La boutique source peut être restaurée indépendamment de l’environnement en production. |
| Documenter l’environnement technique | Responsable technique | Inventaire Shopware, PHP, base, hébergement, déploiement et versions des extensions | Les données dépendantes de la version et les personnalisations sont documentées. |
| Capturer code spécifique et extensions | Responsable développement | Liste extensions, plugins/apps spécifiques, fichiers modifiés, entités personnalisées et notes de déploiement | Chaque donnée ou fonctionnement hors cœur possède un responsable. |
| Cartographier les systèmes externes | Responsables intégration | Identifiants ERP, PIM, WMS, CRM, marketplace, recherche, paiement et traitement des commandes | Les systèmes de référence et clés de synchronisation sont connus. |
Conservez les identifiants internes des produits, variantes, catégories, propriétés, canaux de vente, clients, commandes, médias, champs personnalisés et systèmes externes. Ils seront nécessaires pour rapprocher les relations Shopware et reconnecter les intégrations.
Préparer les canaux de vente, domaines, langues et périmètre client
Les canaux de vente Shopware peuvent représenter vitrines, contextes headless, flux de comparaison de produits, réseaux sociaux ou autres points de contact. Produits, catégories, domaines, langues, devises, paiements, livraisons, thèmes et relations clients peuvent dépendre du canal.
| Domaine du canal | Éléments à préparer | Condition de préparation |
|---|---|---|
| Inventaire des canaux | ID, type, statut, domaine, langue, devise, périmètre client et responsable | Chaque contexte actif orienté client est répertorié une seule fois. |
| Disponibilité produit | ID produit/variante, niveau de visibilité, canaux affectés et exclus | Le périmètre produit n’est pas déduit de la seule présence dans le catalogue global. |
| Contexte domaine/langue | Domaine, chemin, locale, devise, intention hreflang et comportement de repli | Les contenus localisés sont reliés au bon contexte public. |
| Liaison client | Inscription, relation client-canal, doublons d’e-mail et politique de compte | Les identités client ne sont pas fusionnées entre canaux sans éléments justificatifs. |
| Configuration propre au canal | Responsables paiement, livraison, taxe, thème, outils d’analyse et contenu légal | La configuration en production est séparée des données à migrer. |
Documentez les vitrines, régions, marques, langues, parcours grossistes, marketplaces et expériences headless de la source. Décidez lesquels resteront distincts et lesquels seront volontairement consolidés avant de normaliser le catalogue et les données clients.
Préparer les produits, variantes, propriétés et champs personnalisés
Les produits Shopware peuvent reposer sur des relations parent-variante, propriétés, fabricants, médias, catégories, prix avancés, champs personnalisés, délais, quantités d’achat et visibilité par canal. Les propriétés peuvent soutenir le filtrage et générer les variantes, sans que ces deux usages soient automatiquement identiques.
| Structure catalogue | Éléments à préparer | Condition de préparation |
|---|---|---|
| Produit simple | ID, numéro produit, prix, stock, taxe, fabricant, catégorie, médias et visibilité | Le produit peut être interprété sans dépendance d’extension cachée. |
| Famille de variantes | ID parent et enfants, combinaisons, valeurs héritées/remplacées, SKU, stock, prix, poids et images | Chaque unité vendable est reliée au bon parent et aux bonnes options. |
| Propriété filtrable | Groupe, valeurs, affectations produit, usage comme filtre et traductions | Les données descriptives de découverte restent distinctes de l’identité de variante achetable. |
| Champ personnalisé | Ensemble, nom technique, type, entité, valeurs, traductions et processus consommateur | Les usages par équipes, vitrine, règles et intégrations sont documentés. |
| Produit multi-canal | ID produit/variante, canaux, niveaux de visibilité, catégorie principale et chemin SEO par canal | La disponibilité par canal est explicite. |
| Produit riche en médias | Média principal/galerie, images de variante, contexte alt, ordre et stockage externe | Chaque actif média a un propriétaire produit ou variante identifié. |
Répertoriez séparément les produits inactifs, masqués, abandonnés, en rupture commandable, en liquidation, numériques, assimilables à des bundles ou abonnements, ou créés par des extensions. Ne les normalisez pas tous en produits actifs ordinaires pour simplifier l’inventaire.
Préparer les catégories, groupes dynamiques de produits et Shopping Experiences
Les catégories peuvent structurer navigation, affectation produit, points d’entrée et mises en page. Les Dynamic Product Groups définissent des ensembles fondés sur des règles. Shopping Experiences peut porter pages de destination, pages boutique, mises en page de catégories, sections, blocs, éléments, liens et médias.
| Structure de vitrine | Élément de validation | Condition de préparation |
|---|---|---|
| Hiérarchie de catégories | ID, parents, état actif, affectations produit, canaux, traductions et usage de catégorie principale | Hiérarchie et périmètre de canal sont complets. |
| Dynamic Product Group | Conditions, exemples produit, canal et objectif métier | Un assortiment dynamique n’est pas traité comme un simple export statique de catégorie. |
| Shopping Experience | ID de layout, type, catégorie/page associée, sections, blocs, médias et liens produits/catégories | Le responsable du contenu et les références catalogue sont documentés. |
| Parcours de navigation | Canal, arbre de catégories, objectif du menu, contexte d’accès et URL prioritaires | La navigation n’est pas déduite uniquement des catégories. |
| Liens internes | Page source, ID lié, langue et intention de destination | Les liens pourront être réécrits sans perdre l’objet métier référencé. |
Identifiez les mises en page ou éléments créés par des extensions. Séparez contenu réutilisable, présentation du thème et données produit. Lorsqu’une Shopping Experience contient un produit, une catégorie, un formulaire ou un bloc d’extension, enregistrez à la fois la mise en page et son propriétaire fonctionnel.
Préparer les règles, prix, promotions et conditions commerciales
Les affectations Rule Builder peuvent influer sur les prix avancés, promotions, coûts de livraison, disponibilité des paiements/livraisons, flows, visibilité produit/catégorie et accès au contenu. Documentez la condition métier et chaque endroit où la règle est affectée.
| Domaine commercial | Éléments à préparer | Condition de préparation |
|---|---|---|
| Règle | ID, nom, conditions, priorité, statut, clients/groupes/canaux référencés et affectations | L’objectif métier et toutes les zones affectées sont connus. |
| Prix avancé | Produit/variante, devise, règle, plage de quantité, valeurs brut/net, prix de référence et contexte de date | Chaque prix est relié à la bonne condition commerciale. |
| Promotion | Code, règles, périmètre, exclusions, limites d’utilisation, dates et commandes historiques pertinentes | Les preuves historiques sont séparées de la future configuration promotionnelle. |
| Condition livraison/paiement | Règle, canal, contexte client, région, seuil panier et exception | La condition est documentée sans être confondue avec les données de commandes migrées. |
| Stock et livraison | Quantité produit/variante, propriétaire externe, entrepôt, délai et état de commande en rupture | Le système de référence et la clé de l’unité vendable sont connus. |
Les totaux historiques des commandes restent des instantanés. Ne prévoyez pas de recalculer les anciens prix, remises, taxes ou frais de livraison à partir des règles actuelles.
Préparer les clients, adresses, commandes et états historiques
La préparation des clients doit inclure identité du compte, canal, groupes, adresses, langue, informations société/fiscales, consentements, identifiants externes et dépendances d’authentification. Pour les commandes, préservez lignes produit historiques, variantes, adresses, totaux, historique des états, transactions, livraisons, documents, remboursements et références d’intégration.
| Domaine | Responsable | Élément de validation | Condition de préparation |
|---|---|---|---|
| Identité client | Responsable données clients | ID, e-mail, canal, groupe, langue, statut, adresses et ID externe | Les doublons et identités liées à un canal sont résolus intentionnellement. |
| Authentification | Responsable sécurité | Schéma de mot de passe, SSO/social login, réinitialisation, MFA et communications de compte | L’accès au compte est planifié sans supposer la portabilité des identifiants. |
| Lignes de commande | Responsable données commandes | ID produit/variante, libellés instantanés, quantités, prix, promotions, taxes et données spécifiques | Les articles achetés restent compréhensibles même si le catalogue évolue. |
| État de commande | Responsable opérations | États commande, transaction et livraison, horodatages et sens métier | L’historique peut être interprété sans recréer le processus source. |
| Documents et références | Finance/intégrations | Facture, avoir, transaction, expédition, marketplace, ERP et traitement | Les clés historiques de rapprochement restent traçables. |
Sélectionnez des commandes invité, client enregistré, liées à un canal, remisées, remboursées, partiellement livrées et affectées par des extensions.
Inventorier les extensions, entités personnalisées et intégrations
Créez un registre de responsabilité pour chaque plugin, application, entité spécifique, ensemble de champs, action Flow Builder, extension de recherche, intégration de paiement/livraison, connecteur ERP/PIM/WMS, flux marketplace, extension de thème et tâche planifiée qui lit ou écrit des données métier.
| Dépendance | Éléments à préparer | Condition de préparation |
|---|---|---|
| Extension | Nom, version, statut, fonction, responsable de configuration, entités, tables, champs et enregistrements affectés | Les données appartenant à l’extension ont une destination ou un propriétaire conservé. |
| Entité/champ personnalisé | Schéma, affectation, relations, traductions et code consommateur | Les données peuvent être comprises indépendamment de l’implémentation source. |
| Système externe | Endpoint, autorité par entité, sens de synchronisation, ID et responsable de bascule | La migration ne crée pas de systèmes de référence concurrents. |
| Flow ou webhook | Déclencheur, condition, action, données transmises, destination et responsable des erreurs | L’automatisation est séparée des enregistrements statiques migrés. |
| Données générées | Index, caches, logs, sessions, files d’attente et tables d’extensions abandonnées | Les données techniques non autoritatives sont exclues explicitement. |
Même les extensions inactives doivent rester dans le registre lorsque leurs données historiques apparaissent encore dans des produits, clients, commandes, documents ou rapprochements externes.
Préparer les URL prioritaires, éléments SEO et décisions de redirection
Enregistrez les URL prioritaires de produits, catégories, pages de destination, pages boutique et contenus par canal et par langue. Incluez le comportement canonique des variantes, la catégorie principale, les métadonnées, liens internes, backlinks, campagnes et éventuels modèles d’URL SEO ou extensions de redirection.
| Élément URL | Responsable | Condition de préparation |
|---|---|---|
| Chemins produits et variantes | SEO/catalogue | Chaque produit prioritaire a un chemin source lié au canal et une destination prévue. |
| Chemins catégories/pages de destination | Contenu | Hiérarchie, Shopping Experience et intention de route sont reliées. |
| Chemins multilingues | Localisation | Contexte de langue et de canal préservé. |
| Inventaire des redirections | SEO | Chaque ancienne URL importante possède une décision conserver, modifier, fusionner, retirer ou rediriger. |
| Liens internes | Contenu | Les références sources peuvent être réécrites vers les bons objets cibles. |
Ne vous limitez pas au sitemap. Utilisez aussi données d’analyse, données de recherche, backlinks, campagnes, communications clients et navigation interne à forte valeur.
Sélectionner des échantillons représentatifs pour les tests de migration
Choisissez des cas qui représentent réellement l’architecture de la boutique. Enregistrez ID source, numéros produit, URL, canaux, propriétés, règles, relations clients, références de commandes et raison du choix.
| Échantillon | Éléments à préparer | Objectif |
|---|---|---|
| Famille de variantes | Parent, variantes, options, héritage, stock, prix, images et canaux | Représenter le modèle produit-variante. |
| Produit riche en propriétés | Groupes, valeurs de filtres, champs personnalisés, catégorie et usage recherche | Représenter découverte et responsabilité des champs. |
| Cas dépendant d’une règle | Règle, prix/promotion/livraison/paiement affecté et enregistrements concernés | Représenter le fonctionnement commercial conditionnel. |
| Client multi-canal | Client, canal d’inscription, groupes, adresses et doublons d’e-mail | Représenter l’identité liée au canal. |
| Commande complexe | Variantes, promotions, états, transaction, livraison, document et ID externes | Représenter l’historique commercial. |
| Shopping Experience | Layout, affectation, médias, liens et blocs d’extensions | Représenter les relations contenu-commerce. |
| Enregistrement appartenant à une extension | Entité centrale, schéma d’extension, champs et clés d’intégration | Exposer le périmètre hors cœur avant exécution. |
Le dossier d’échantillons est prêt lorsque chaque cas possède des éléments sources, son contexte canal/règle, les fichiers associés et un réviseur identifié.
Finaliser le contrôle de préparation Shopware
| Domaine de préparation | Condition prête |
|---|---|
| Accès et restauration | Administration, hébergement, base/fichiers si disponibles, médias, identifiants, sauvegardes et responsabilité de restauration confirmés. |
| Canaux de vente | Domaines, langues, devises, périmètre client, visibilité produit et responsables documentés. |
| Catalogue | Produits, variantes, propriétés, catégories, médias, prix, stock, champs personnalisés et identifiants traçables. |
| Historique commercial | Clients, adresses, commandes, états, livraisons, transactions, documents et références externes documentés. |
| Contenu et URL | Shopping Experiences, navigation, routes prioritaires, métadonnées, liens et décisions de redirection documentés. |
| Dépendances | Règles, extensions, entités spécifiques, flows, webhooks et systèmes externes ont des responsables nommés. |
| Échantillons | Les cas représentatifs couvrent chaque structure importante de produit, canal, client, commande, contenu, règle et extension. |
Le périmètre est prêt lorsque chaque enregistrement important peut être relié à son propriétaire source, ses relations, ses éléments de validation et sa destination prévue ou au système qui continuera à le gérer.
Conclusion
Préparer une migration vers Shopware exige des éléments coordonnés sur les canaux de vente, produits et variantes, propriétés, champs personnalisés, catégories, Shopping Experiences, règles, clients, commandes, extensions, URL et intégrations. La checklist doit rendre ces relations explicites avant l’exécution au lieu de s’appuyer sur des totaux d’enregistrements ou des exports génériques.
Un dossier de préparation complet conserve des preuves sources restaurables, définit les enregistrements faisant autorité, sépare les transactions historiques de la configuration active et attribue chaque dépendance importante à un responsable identifié.
Questions fréquentes
Que faut-il préparer en premier pour une migration vers Shopware ?
Confirmez les accès d’administration et d’infrastructure, créez des sauvegardes restaurables, documentez l’environnement Shopware et ses extensions, puis identifiez tous les canaux de vente actifs. L’analyse détaillée du catalogue ne doit pas commencer avant de pouvoir inspecter et restaurer la source de façon fiable.
Pourquoi faut-il documenter séparément le périmètre des canaux de vente ?
Parce que produits, clients, domaines, langues, devises, visibilité, contenu et configuration commerciale peuvent dépendre du canal. La présence globale d’un enregistrement ne prouve pas que le bon contexte client a été préservé.
Comment préparer les propriétés et variantes Shopware ?
Documentez groupes de propriétés, valeurs, affectations produit, usage comme filtre et combinaisons générant les variantes. Identifiez les valeurs héritées et remplacées pour chaque unité vendable afin de ne pas confondre propriété descriptive et identité de variante.
Quelles règles nécessitent des éléments de préparation ?
Incluez les règles affectées aux prix, promotions, livraisons, paiements, flows, visibilité de produits/catégories et accès au contenu. Documentez conditions, priorité, entités référencées et chaque affectation dépendante.
Quelles commandes Shopware choisir comme échantillons représentatifs ?
Incluez clients invités et enregistrés, comptes liés à des canaux, variantes, promotions, remboursements, livraisons partielles, plusieurs changements d’état, documents, transactions et références d’intégrations externes.
Que doit contenir le registre des extensions Shopware ?
Chaque extension, entité spécifique, ensemble de champs, flow, webhook, dépendance de thème et connecteur externe qui crée ou consomme des données métier, avec son responsable, ses enregistrements affectés, ses éléments sources et sa décision de destination ou de maintien dans un autre système.