Si AmeriCommerce est retenu comme plateforme cible, la préparation doit rendre la boutique source compréhensible avant de figer la configuration de migration. Une installation peut combiner plusieurs storefronts, des restrictions de catalogue actif, des Customer Types, des variantes, Product Groups, kits, règles de prix avancées, champs personnalisés, contenus et systèmes externes. Un export montre ce qui existe, mais il n’explique pas quel storefront possède un enregistrement, quelle règle d’acheteur modifie son fonctionnement ni quel identifiant doit rester disponible pour un autre système.
L’objectif est de transformer ces relations en éléments source maîtrisés. Pour chaque domaine important, l’équipe doit préciser l’action à réaliser, le responsable de la réponse, les éléments à fournir et la condition qui permet de considérer le domaine comme prêt. L’état source reste ainsi explicite avant le début de la configuration de migration.
Établir les accès et définir le périmètre opérationnel AmeriCommerce
Commencez par documenter le compte AmeriCommerce exact et chaque Store inclus dans le périmètre. Enregistrez les accès administratifs, identifiants Store, domaines actifs, devises, langues, contexte fiscal, propriétaire actuel du thème et responsables du catalogue, des Customers, Orders, du marketing et des intégrations. Lorsque plusieurs Stores partagent des données ou utilisent des catalogues actifs différents, la préparation doit indiquer quels paramètres et enregistrements sont globaux et lesquels sont propres à un Store.
Les exports AmeriCommerce peuvent être filtrés par Store et configurés avec des colonnes sélectionnées. Conservez les critères utilisés pour chaque export afin qu’un fichier puisse être rattaché ultérieurement à un Store, une date et un ensemble de champs précis. Ne supposez pas qu’un export combiné préserve automatiquement la propriété par Store.
| Action | Responsable | Éléments à fournir | Condition de préparation |
|---|---|---|---|
| Lister chaque Store et domaine dans le périmètre | Administrateur commerce | Liste des Stores, identifiants, domaines, statut et objectif métier | Chaque Store inclus possède un rôle et un responsable identifiés. |
| Confirmer l’accès source pris en charge | Responsable des accès | Trace des accès administratifs, droits d’export, contact technique | Les enregistrements nécessaires peuvent être collectés depuis le bon compte. |
| Documenter le fonctionnement partagé et propre à chaque Store | Responsable plateforme | Note comparative sur catalogues, prix, contenus et paramètres | Les données partagées sont distinguables des données propres aux Stores. |
| Figer les critères d’export | Responsable des données | Nom de l’export, filtre Store, date, colonnes sélectionnées, hash du fichier | Chaque fichier source peut être reproduit et expliqué. |
| Ouvrir un journal des changements source | Responsable projet | Journal daté des modifications du catalogue, Customers, Orders, URL et intégrations | Les changements survenus après la capture des éléments ne seront pas perdus. |
Préparer Products, variantes, groupes, kits et relations de prix
Les Products AmeriCommerce peuvent utiliser variantes, inventaire par variante, Product Groups, kits, tarification avancée, règles de quantité, prix par Customer Type et champs personnalisés. Ces structures ne doivent pas être aplaties en une seule ligne Product pendant la préparation. L’équipe doit déterminer quels enregistrements représentent des choix réellement vendables, lesquels servent à la présentation groupée et lesquels dépendent d’une relation de prix ou d’inventaire.
Créez un inventaire Product comprenant Product ID, item number ou SKU, statut, visibilité par Store, placement dans le catalogue actif, Categories, fabricant, prix de base, classe fiscale, quantité, poids, images, contenu, variantes, relations Product Group, composants de kits, règles de prix et identifiants externes. Sélectionnez des exemples couvrant chaque modèle Product réellement différent.
| Modèle source | Action de préparation | Éléments à fournir | Condition de préparation |
|---|---|---|---|
| Variantes Product | Documenter Variant Groups, valeurs, ordre d’affichage, caractère obligatoire, effets sur prix et affectation Product | Export des variantes et pages Product représentatives | Le vocabulaire des choix et la propriété Product sont complets. |
| Inventaire par variante | Relever SKU, quantité, prix, image, poids et statut au niveau des combinaisons utilisées | Matrice des combinaisons et échantillon de stock | Les combinaisons vendables gérées indépendamment sont visibles. |
| Product Groups | Documenter Products parent/enfants, type de groupe, vendabilité, prix, inventaire et fonctionnement de l’expédition | Export des relations de groupe et captures | Le regroupement n’est pas confondu avec une simple variante. |
| Kits ou offres assemblées | Relever Products composants, quantités, fonctionnement des prix, hypothèses de stock et notes de traitement des commandes | Liste des kits et exemples de composants | La signification des composants et leur propriété opérationnelle sont documentées. |
| Tarification avancée ou par Customer Type | Enregistrer public concerné, seuil de quantité, dates, formule ou montant et Products concernés | Matrice des règles de prix | Les prix conditionnels sont explicites et non déduits de simples libellés. |
| Champs personnalisés Product | Classer chaque champ comme descriptif, opérationnel, appartenant à une intégration ou obsolète | Dictionnaire des champs avec exemples | Les champs critiques possèdent une décision et un responsable. |
Ne fusionnez pas des noms d’options ou règles de prix similaires uniquement pour simplifier la source. Deux libellés apparemment équivalents peuvent différer selon le Store, le Customer Type, la propriété du stock ou l’utilisation dans un système externe.
Documenter storefronts, catalogues actifs, Categories et parcours de découverte
AmeriCommerce peut restreindre le catalogue visible par Store via les paramètres de catalogue actif. Les Customer Types peuvent également influencer visibilité des Products, contenu, redirections, remises et méthodes d’expédition. La préparation nécessite donc plus qu’un arbre de Categories : elle doit produire une carte de visibilité montrant quels acheteurs peuvent découvrir quels Products dans quel Store.
Préparez la hiérarchie des Categories avec ID, parent, statut, Store associé, état dans le catalogue actif, affectations Product, contenu, images, ordre de tri et URL importantes. Documentez séparément les menus, landing pages, chemins fabricants, mécanismes de découverte par attributs et liens internes qui s’appuient sur ces Categories.
| Domaine de découverte | Responsable | Éléments à fournir | Condition de préparation |
|---|---|---|---|
| Catalogue actif par Store | Administrateur plateforme | Captures ou export du catalogue actif propre à chaque Store | La limite de Categories visible pour chaque Store est documentée. |
| Hiérarchie des Categories | Responsable catalogue | Export parent-enfant et liste des Categories conservées | Chaque Category conservée possède un parent et une finalité connus. |
| Placement des Products | Responsable merchandising | Éléments Product-to-Category et affectations aux Stores | Les placements partagés et restrictions de Store sont visibles. |
| Visibilité par Customer Type | Responsable B2B ou comptes | Exemples de Products et Categories restreints | Les règles d’accès acheteur sont reliées à des enregistrements réels. |
| Menus et landing pages | Responsable storefront | Carte de navigation, captures et routes liées | Les chemins de présentation sont séparés de la structure du catalogue. |
| URL prioritaires | Responsable SEO | Liste des routes Product, Category, contenus et campagnes | Chaque route importante possède une décision documentée. |
Préparer Customers, Customer Types, comptes et adresses
Les Customer Types AmeriCommerce peuvent modifier tarification, remises, redirections après connexion, récompenses, contenu personnalisé, méthodes d’expédition et Products masqués. Un Customer Type doit donc être préparé comme relation de règles métier, et non comme simple nom de groupe. Documentez quels Customers actifs appartiennent à chaque type et ce que le type modifie.
Préparez les Customers avec leurs ID, noms, e-mails, état de connexion, adresses de facturation et d’expédition, informations d’entreprise, Customer Type, statut fiscal, état d’inscription aux communications, champs personnalisés, attribution commerciale ou de compte et identifiants externes. Identifiez les e-mails dupliqués, adresses d’entreprise partagées, comptes inactifs et enregistrements dont le Customer Type ne correspond plus à l’usage actuel.
| Domaine Customer | Action de préparation | Éléments à fournir | Condition de préparation |
|---|---|---|---|
| Identité | Résoudre ou documenter les schémas d’e-mails dupliqués et partagés | Registre des exceptions Customer | Les exceptions d’identité ont un responsable et un traitement. |
| Customer Types | Relever les adhésions et chaque règle de prix, visibilité, redirection, expédition ou contenu influencée | Matrice des règles Customer Type | Chaque type possède une signification métier documentée. |
| Adresses | Distinguer les adresses réutilisables du Customer des instantanés enregistrés au moment des Orders | Exemples d’adresses Customer et Order | Les données de compte actuelles ne sont pas confondues avec l’historique transactionnel. |
| Fiscalité et exonérations | Documenter statut, responsable des justificatifs et Customers concernés | Liste échantillon des statuts fiscaux | Un traitement fiscal particulier n’est pas réduit à un simple libellé. |
| Champs personnalisés et ID externes | Identifier système propriétaire et usage en aval | Dictionnaire de champs et références d’intégration | Les identifiants opérationnels restent traçables. |
Préparer Orders, statuts, totaux et contexte historique
La préparation des Orders doit préserver les éléments dont ont besoin le service Customer, la finance, le traitement des commandes et les équipes de compte. Sélectionnez des Orders dans chaque Store et incluez des exemples avec variantes, Product Groups ou kits, prix par Customer Type, remises, différences fiscales, expéditions inhabituelles ou réparties, remboursements, annulations, ajustements manuels, notes et références externes.
Conservez les critères d’export des Orders et incluez les champs nécessaires à l’interprétation des lignes, adresses, statuts, libellés de paiement et d’expédition, taxes, remises, frais et totaux. Les libellés historiques doivent être documentés comme contexte source ; ils ne doivent pas être traités comme instructions de configuration pour les paiements ou expéditions actifs dans la cible.
| Domaine Order | Action | Éléments à fournir | Condition de préparation |
|---|---|---|---|
| Propriété par Store | Inclure l’identifiant Store dans les éléments d’Order | Liste d’échantillons couvrant plusieurs Stores | Chaque échantillon peut être relié au bon Store. |
| Historique des statuts | Relever libellés, séquence, signification pour les équipes et visibilité Customer | Dictionnaire des statuts et Orders représentatifs | Les états historiques peuvent être interprétés de manière cohérente. |
| Détails des lignes | Inclure variantes sélectionnées, contexte kit/groupe, quantité, SKU et prix | Échantillons de lignes d’Order | La configuration achetée reste compréhensible. |
| Totaux et ajustements | Identifier taxes, expédition, remises, frais, crédits, remboursements et lignes manuelles | Inventaire des composants du total | Chaque ajustement significatif possède une signification source connue. |
| Références externes | Relever identifiants ERP, comptabilité, CRM, traitement des commandes ou marketplaces | Orders sensibles aux intégrations | Les besoins de recherche dans les systèmes en aval sont documentés. |
Ne modifiez pas les Orders historiques uniquement pour les uniformiser. Enregistrez séparément les anomalies lorsqu’elles expliquent la transaction d’origine.
Inventorier contenus, intégrations, automatisations et données personnalisées
Préparez les contenus et les dépendances sous forme d’inventaires distincts. Les éléments de contenu doivent inclure pages, blog ou contenus pédagogiques, formulaires, images, téléchargements, métadonnées, attentes de canonical, liens internes et redirections. Les dépendances doivent couvrir ERP, comptabilité, CRM, fiscalité, expédition, inventaire, traitement des commandes, marketplaces, analytics, e-mail et systèmes d’information Product.
Pour chaque intégration ou processus automatisé, documentez le système propriétaire, le sens du flux de données, le calendrier ou déclencheur, les identifiants utilisés, les champs lus ou écrits et le comportement prévu pendant la période de migration. Les champs ou scripts personnalisés doivent être classés par finalité métier au lieu d’être collectés sans interprétation.
| Dépendance | Responsable | Éléments à fournir | Condition de préparation |
|---|---|---|---|
| ERP ou comptabilité | Finance ou responsable systèmes | Identifiants d’articles, Customers, Orders, factures et taxes | Les clés de recherche nécessaires sont connues. |
| Inventaire ou traitement des commandes | Responsable opérations | Codes d’entrepôt, ID fournisseur, autorité de stock, références d’expédition | La propriété du stock et du traitement est explicite. |
| CRM ou processus commercial | Responsable systèmes commerciaux | Champs entreprise, contact, responsable de compte et contrat | Les relations de compte sont documentées. |
| Marketing et analytics | Responsable marketing | Segments, routes de campagne, références de suivi, champs de consentement | Les données marketing ont une décision d’inclusion claire. |
| Logique source personnalisée | Développeur ou agence | Scripts, champs personnalisés, tables cachées, tâches planifiées, procédures manuelles | Le fonctionnement non standard possède un responsable et une décision. |
Préparer exports, médias, sauvegardes et contrôle des changements
Créez une archive datée d’éléments source plutôt qu’une collection de fichiers isolés. Rangez les exports Product, Customer, Order, Category, contenu, tarification, champs personnalisés et intégrations avec les médias, captures, critères d’export et notes explicatives. Conservez les fichiers originaux sans modification et effectuez tout nettoyage ou analyse dans des copies de travail.
| Ensemble d’éléments | Contenu requis | Condition de préparation |
|---|---|---|
| Exports de données | Fichiers source, critères d’export, filtres Store, date, champs, checksum | Les fichiers sont complets et attribuables. |
| Archive média | Ressources Product, Category, contenu, documents et téléchargements | Les fichiers originaux peuvent être rattachés aux enregistrements source. |
| Éléments de configuration | Captures ou rapports Store, catalogue actif, Customer Type, tarification, statuts et fiscalité | Les règles absentes des exports ordinaires sont documentées. |
| Note de sauvegarde et récupération | Sauvegardes disponibles, exports téléchargés, archive média, contacts de compte | Les éléments source peuvent être récupérés en cas de question. |
| Journal des changements | Nouveaux ou modifiés Products, Customers, Orders, URL, règles et intégrations après la capture | Les changements ultérieurs peuvent être rapprochés. |
Sélectionner des enregistrements représentatifs pour les tests de migration
Choisissez volontairement les enregistrements représentatifs. L’échantillon doit inclure des cas ordinaires et les structures les plus susceptibles de révéler un problème de périmètre ou de mise en correspondance. Pour AmeriCommerce, cela signifie généralement des enregistrements provenant de différents Stores, catalogues actifs, Customer Types, modèles Product et contextes d’intégration.
| Groupe d’échantillons | À inclure | Objectif de préparation |
|---|---|---|
| Products | Product simple, à variantes, avec inventaire de variantes, Product Group, kit, Product restreint, Product à tarification avancée | Faire apparaître des relations distinctes de catalogue et de prix. |
| Customers | Acheteur par défaut, Customer Type spécial, compte exonéré de taxe, compte entreprise/géré, exception d’e-mail dupliqué | Représenter les différences d’identité et de règles acheteur. |
| Orders | Différents Stores, statuts, remises, cas fiscaux, remboursements, lignes groupées ou kit, références externes | Préserver le contexte opérationnel historique. |
| Contenus et URL | Routes prioritaires de Product, Category, page, campagne et redirection | Préparer les décisions de routes et de contenu. |
| Intégrations | Enregistrements Product, Customer et Order contenant des ID externes | Vérifier que les éléments source requis sont présents. |
Pour chaque échantillon, rédigez une brève attente source décrivant les relations, champs, fichiers liés et identifiants qui le rendent représentatif.
Valider la préparation AmeriCommerce
La préparation est terminée lorsque les éléments source permettent de répondre aux questions qui déterminent le périmètre de migration. L’équipe doit pouvoir identifier chaque Store, expliquer les règles de catalogue actif et de Customer Type, distinguer les structures Product, interpréter les Orders historiques, retrouver médias et contenus et nommer le propriétaire de chaque intégration importante.
| Vérification finale | Condition de préparation |
|---|---|
| Périmètre Store | Chaque Store inclus et chaque limite de données partagées sont documentés. |
| Catalogue | Structures Product, règles de prix, visibilité et Categories sont représentées par des éléments vérifiables. |
| Customers | Customer Types, exceptions d’identité, adresses, contexte fiscal et ID externes sont compris. |
| Orders | Propriété par Store, statuts, lignes, totaux et références externes sont interprétables. |
| Contenus et URL | Pages prioritaires, médias, métadonnées et décisions de routes sont enregistrés. |
| Dépendances | Intégrations, automatisations et données personnalisées possèdent responsables et décisions. |
| Entrées | Exports, médias, critères, checksums, sauvegardes et journal des changements sont disponibles. |
| Échantillons | Les enregistrements représentatifs couvrent les modèles source ordinaires et complexes. |
Conclusion
La préparation d’AmeriCommerce doit révéler comment Stores, catalogues actifs, Customer Types, structures Product, tarification, Orders, contenus et systèmes externes fonctionnent ensemble. Le meilleur dossier de préparation n’est pas le plus gros export : c’est celui qui préserve propriété et signification à travers ces relations.
Lorsque les accès, exports, règles métier, échantillons représentatifs et contrôle des changements sont complets, la configuration de migration peut s’appuyer sur une source documentée plutôt que sur des suppositions.
Questions fréquentes
Les exports AmeriCommerce doivent-ils être combinés pour tous les Stores ?
Uniquement si la propriété par Store reste explicite. Conservez le filtre Store, les critères d’export et l’identifiant Store avec chaque fichier afin de pouvoir distinguer les enregistrements partagés des enregistrements propres à chaque Store.
Pourquoi documenter les Customer Types séparément des Customers ?
Parce qu’ils peuvent modifier prix, remises, contenus, redirections, expédition et visibilité des Products. L’appartenance à un type ne suffit pas à expliquer la règle contrôlée.
Quels Products faut-il prioriser pendant la préparation ?
Incluez Products simples, variantes, Products avec inventaire par variante, Product Groups, kits, Products restreints, cas de tarification avancée et enregistrements comportant des identifiants externes.
Faut-il supprimer les Products anciens ou inactifs avant la migration ?
Pas automatiquement. Classez-les comme inclus, exclus, archivés ou à examiner par l’entreprise. Les supprimer trop tôt peut enlever des éléments nécessaires pour comprendre les Orders historiques ou les intégrations.
Que faut-il préserver avec les Orders historiques ?
Conservez la propriété par Store, la configuration des lignes, les statuts, adresses, totaux, remises, taxes, libellés de paiement et d’expédition, notes et références externes nécessaires aux équipes opérationnelles.
Comment gérer les changements source après la création des exports ?
Maintenez un journal daté et identifiez le responsable de chaque domaine modifié. Le journal doit couvrir catalogue, Customers, Orders, URL, prix et intégrations susceptibles de modifier les éléments préparés.