Si Magento est retenu comme plateforme cible, la préparation doit traduire la boutique source en un modèle documenté de catalogue, Customers, Orders, contenu et extensions avant le premier lancement de migration. La plateforme est flexible, mais cette flexibilité renforce la nécessité de distinguer les types de Products, SKU enfants configurables, options personnalisées, attributs, jeux d’attributs, store views, sources d’inventaire, Orders historiques, données appartenant aux extensions et identifiants externes.
Pour chaque domaine de préparation, définissez l’action attendue, le responsable, les éléments de validation et la condition permettant de considérer le domaine comme prêt. Le test de migration représentatif devient ainsi un échantillon contrôlé de la structure Magento voulue, et non la première tentative de comprendre la boutique source.
Définir la structure cible Magento
Préparez une carte synthétique de la structure cible couvrant websites, stores, store views, langues, devises, responsabilité du catalogue, groupes de Customers, inventaire, contenu et intégrations.
| Domaine de préparation | Décision à enregistrer | Responsable | Élément indiquant que le domaine est prêt |
|---|---|---|---|
| Portée website et store view | Quelles marques, régions, langues, devises, domaines et valeurs localisées nécessitent une portée séparée | Responsable e-commerce | Matrice website/store/store view |
| Architecture Product | Quels enregistrements source deviennent des Products simple, configurable, grouped, bundle, virtual ou downloadable | Responsable catalogue | Classification des familles Product |
| Gouvernance des attributs | Quels champs deviennent attributs, jeux d’attributs, options personnalisées, contenu ou données externes | Responsables catalogue et technique | Dictionnaire d’attributs et exemples de valeurs |
| Propriété de l’inventaire | Magento, ERP, WMS, fournisseur ou marketplace : quel système possède le stock ? | Responsable inventaire | Carte sources/stocks/système de référence |
| Historique Customers et Orders | Quels groupes, adresses, statuts, ajustements et références externes doivent rester interprétables | Opérations et support | Dossier représentatif Customer/Order |
| Limites des extensions | Quels modules et tables personnalisées créent des enregistrements importants | Responsable technique | Registre de dépendances |
Cette carte doit définir la responsabilité de destination sans devenir une spécification complète d’implémentation Magento.
Préparer les accès, sauvegardes et éléments source
Rassemblez :
- les accès administrateur source et Magento avec les droits nécessaires ;
- les sauvegardes de base de données et de médias lorsqu’elles sont disponibles ;
- des exports ou rapports récents pour Products, Categories, Customers, Orders, Coupons, avis, CMS Pages, Blog Posts et médias ;
- les listes de websites, stores, store views, langues, devises et domaines ;
- les références de types de Products, attributs, jeux d’attributs, options personnalisées et Categories ;
- les rapports sur sources d’inventaire, stocks, entrepôts et systèmes externes ;
- des exemples de groupes de Customers, taxes et statuts de compte ;
- l’inventaire des extensions, modules personnalisés, tâches cron, API et intégrations ;
- les listes d’URL rewrites, redirections, sitemaps et routes à forte valeur ;
- des captures ou rapports expliquant les comportements source atypiques.
| Élément | Pourquoi il est nécessaire | Condition de préparation |
|---|---|---|
| Sauvegarde base/médias | Conserver les enregistrements non exposés dans les exports standards | Date, emplacement de stockage et responsable de restauration documentés |
| Dictionnaire d’attributs | Expliquer les champs personnalisés et les différences entre familles de Products | Chaque attribut important possède un objectif, un type, une portée et des exemples de valeurs |
| Inventaire des extensions | Identifier les enregistrements hors cœur Magento | Chaque module critique a un responsable métier et technique |
| Inventaire des URL | Préserver la continuité des routes | Les chemins prioritaires Product, Category et contenu ont une destination prévue |
| Registre des identifiants externes | Préserver les intégrations | Les clés sont affectées au bon niveau Product, Customer, Order ou inventaire |
Un export d’extension manquant, un dossier médias inaccessible ou une table personnalisée non documentée doit rester visible comme élément de préparation non résolu.
Préparer les types de Products et les relations vendables
Sélectionnez des exemples pour chaque structure Product qui influence réellement la gestion du catalogue ou l’historique des Orders :
- Products simples ;
- Products configurables avec Products simples associés ;
- Products grouped ;
- Products bundle ;
- Products virtual et downloadable ;
- Products avec options personnalisées ;
- Products présents sur plusieurs websites ou comportant des valeurs par store view ;
- Products avec champs appartenant à des extensions, tables personnalisées ou identifiants externes.
| Fonctionnement source | Décision de préparation Magento | Éléments nécessaires |
|---|---|---|
| Le choix crée un SKU ou stock indépendant | Définir le parent configurable et les Products simples associés | IDs parent/enfant, SKU, attributs, stock, prix et images |
| Des Products sont présentés ensemble mais vendus indépendamment | Définir une relation grouped | Membres du groupe et quantités |
| Le Customer compose un ensemble | Définir les composants du bundle et les règles de sélection | Products composants, quantités, prix et propriétaire de l’inventaire |
| Une valeur modifie un seul Product sans stock indépendant | Définir une option personnalisée ou un autre propriétaire | Type d’option, valeurs, impact sur le prix et exemple d’Order historique |
| Product numérique ou non expédié | Définir un Product downloadable ou virtual | Fichier, accès, règles d’expédition et contexte d’Order |
| La source duplique les Products par région | Définir la portée website/store view ou conserver volontairement des Products séparés | Exemples de contenu, prix, URL et identifiants régionaux |
Normalisez les SKU dupliqués, Products enfants orphelins, libellés d’options incohérents, liens parent manquants, Products obsolètes et combinaisons non prises en charge avant de finaliser la correspondance des données.
Nettoyer les attributs et jeux d’attributs
Les attributs Magento peuvent influencer l’édition, le filtrage, la recherche, la comparaison, la création des Products et le contenu par store view. Préparez un inventaire gouverné plutôt que de copier chaque champ source dans un jeu d’attributs surdimensionné.
Pour chaque champ, documentez :
- son objectif métier ;
- son type de données et les valeurs autorisées ;
- les familles de Products qui l’utilisent ;
- sa portée globale, website ou store view ;
- s’il est sélectionné par le Customer ;
- si la recherche, le filtrage, la comparaison ou une intégration en dépend ;
- s’il contient l’identifiant d’un autre enregistrement ;
- s’il doit être conservé, normalisé, fusionné ou exclu.
| Structure de champ | Propriétaire Magento prévu | Élément de préparation |
|---|---|---|
| Valeur définissant une variante | Attribut configurable et Products simples associés | Valeurs contrôlées et exemples de familles Product |
| Spécification technique | Attribut Product attribué via un jeu d’attributs | Type, portée, valeurs autorisées et usage d’affichage/recherche |
| Valeur saisie par le Customer | Option personnalisée, extension ou ligne d’Order | Exemple en vitrine et dans un Order historique |
| Valeur utilisée seulement par une intégration | Attribut Product ou SKU enfant utilisé par un système externe | Responsable du système et règle d’unicité |
| Ancien contournement source | Attribut cible normalisé, contenu, extension ou exclusion | Décision expliquant la finalité future |
La condition de préparation est atteinte lorsque chaque grande famille Product possède un jeu d’attributs approuvé et qu’aucun champ important ne reste sans propriétaire ou partagé entre plusieurs propriétaires incompatibles.
Préparer Categories, contenu, URL et valeurs par store view
Préparez un inventaire des routes et du contenu couvrant :
- hiérarchie des Categories et appartenance des Products ;
- Categories utilisées seulement pour l’organisation interne ou des campagnes ;
- URL keys Product et Category ;
- CMS Pages, CMS blocks et contenu piloté par des extensions ou thèmes ;
- Blog Posts et contenu appartenant à des extensions ;
- valeurs localisées pour Products, Categories et CMS ;
- backlinks importants, routes de campagnes payantes, pages de politiques et landing pages ;
- URL rewrites, redirections et liens internes.
| Enregistrement source | Question de préparation | Élément requis |
|---|---|---|
| Category | Est-ce une structure durable du catalogue, une navigation, un regroupement de campagne ou une classification interne ? | Décision Category et exemple d’appartenance Product |
| Product ou page localisée | Quelle store view possède chaque valeur ? | Matrice des valeurs par store view |
| CMS Page/block | S’agit-il de contenu réutilisable, de contenu de page ou de présentation de thème ? | Inventaire du contenu et propriétaire cible |
| Blog Post | Quelle extension ou quel système de contenu le possédera ? | Liste des articles, médias, URL et propriétaire cible |
| URL historique | Quel Product, Category ou contenu cible reçoit la redirection ? | Registre route source/destination |
Le domaine est prêt lorsque chaque route publique prioritaire possède une destination ou une décision de retrait, et chaque valeur localisée un responsable de store view.
Préparer les groupes de Customers, Customers et Orders historiques
La préparation Customers doit couvrir les Customers enregistrés, invités, adresses multiples, groupes de Customers, traitement fiscal, statut de compte, identités dupliquées, champs personnalisés et clés CRM/ERP externes.
Pour les Orders, sélectionnez des exemples comprenant :
- Products configurables et options personnalisées ;
- Products grouped ou bundle ;
- remises, Coupons, taxes, livraison et libellés de paiement ;
- factures, expéditions, avoirs, annulations et commentaires ;
- références marketplace, ERP, traitement des commandes, comptabilité ou CRM ;
- chaque website, devise ou groupe de Customers important.
| Élément | Responsable | Éléments requis | Condition de préparation |
|---|---|---|---|
| Identité Customer | Opérations Customers | Exemples de doublons, invités, adresses et IDs externes | Règles de fusion et de séparation documentées |
| Groupes de Customers | Responsable commercial | Liste des groupes et finalité prix/taxe/accès | Chaque groupe conserve un sens métier futur |
| Orders historiques | Support et finance | Dossier représentatif d’Orders | Lignes, totaux, statuts, traitement des commandes, remboursements et références sont expliqués |
| Données sensibles | Responsable juridique/données | Liste de champs approuvée | Les données personnelles inutiles ou non prises en charge sont exclues |
N’utilisez pas les groupes de Customers ou prix Product actuels pour réinterpréter les Orders historiques. Chaque Order doit conserver ses propres éléments de contexte au moment de la transaction.
Préparer la responsabilité de l’inventaire et du traitement des commandes
L’inventaire Magento peut comprendre sources, stocks, affectations aux websites, quantités par source, quantité vendable, réservations, backorders, points de retrait, drop shippers et systèmes d’inventaire externes.
Préparez des exemples pour :
- SKU simples et enfants de Products configurables ;
- Products mono-source et multi-source ;
- enregistrements en backorder, stock faible, rupture ou précommande ;
- entrepôts, magasins, fournisseurs et emplacements de drop-shipping ;
- Products synchronisés avec ERP, WMS, marketplaces ou systèmes de traitement des commandes ;
- stock à rafraîchir à proximité de la fenêtre de migration.
| Question d’inventaire | Élément | Condition de préparation |
|---|---|---|
| Quel système possède la quantité ? | Carte du système de référence | Chaque SKU prioritaire possède une autorité déclarée |
| Quel emplacement source correspond à quelle source Magento ? | Matrice des emplacements | Les codes source et cible sont documentés |
| Quels websites utilisent chaque stock ? | Relation website/stock | La propriété des canaux de vente est définie |
| Quel niveau Product possède l’inventaire ? | Exemples parent/enfant | Les responsabilités du parent configurable et des enfants sont claires |
| Quelles valeurs sont des instantanés d’ouverture ? | Rapport de stock daté | Date de l’instantané et responsable du rafraîchissement enregistrés |
L’inventaire est prêt lorsque quantité, emplacement, niveau Product, relation website et propriété du système externe sont explicites.
Inventorier extensions, modules personnalisés et systèmes externes
Créez un registre de dépendances pour chaque extension, module personnalisé, table modifiée, API, traitement planifié et système externe qui influence Products, Customers, Orders, inventaire, contenu ou URL.
Enregistrez :
- le nom du module ou système ;
- son objectif métier ;
- les enregistrements du cœur qu’il étend ;
- les champs, tables, statuts ou IDs personnalisés qu’il crée ;
- la disponibilité d’un export ou d’une API ;
- les responsables métier et technique ;
- le propriétaire ou remplacement prévu côté cible ;
- les données à archiver ou exclure.
Les dépendances prioritaires incluent recherche, avis, fidélité, abonnements, paiement, fiscalité, expédition, marketplaces, ERP, PIM, WMS, CRM, comptabilité, consentement, outils d’analyse et règles personnalisées du processus de commande ou du traitement des commandes.
Le registre est prêt lorsque chaque dépendance importante possède un responsable cible et une clé stable. Ne décrivez pas les enregistrements d’une extension comme de simples champs Magento si le cœur de la plateforme ne les possède pas réellement.
Sélectionner des échantillons de test représentatifs
| Échantillon | Objectif de préparation |
|---|---|
| Famille simple + configurable | Vérifier type Product, attributs, SKU enfants, médias et inventaire |
| Product grouped ou bundle | Exposer les relations de composants et la propriété des prix |
| Product avec options personnalisées | Exposer les saisies ponctuelles du Customer et leur représentation dans les Orders historiques |
| Product ou Category localisé | Exposer la portée website/store view, le contenu et les URL |
| Customer avec groupe et ID externe | Exposer identité, segmentation et relations d’intégration |
| Order historique complexe | Exposer options, totaux, expéditions, avoirs et références |
| SKU d’inventaire multi-source | Exposer sources, stocks, websites et propriété de l’inventaire externe |
| Enregistrement appartenant à une extension | Exposer les décisions de table personnalisée et de responsabilité cible |
Pour chaque échantillon, enregistrez l’ID source, l’URL source le cas échéant, la raison métier, le propriétaire Magento prévu, les identifiants externes associés, les exclusions connues et le réviseur responsable. Le registre est prêt lorsque chaque enregistrement sélectionné possède une attente source traçable et une personne chargée de le vérifier.
Passer la porte de préparation Magento
| Question de préparation | Éléments requis | Condition de réussite |
|---|---|---|
| Les accès et archives source sont-ils récupérables ? | Accès, sauvegarde base, sauvegarde médias et exports | Les enregistrements requis peuvent être contrôlés indépendamment de la boutique source active |
| Les familles Product et jeux d’attributs sont-ils définis ? | Matrice Products/attributs | Chaque grande structure de catalogue possède une structure Magento prévue |
| Categories, contenu et URL ont-ils été affectés ? | Registre contenu/routes | Les enregistrements prioritaires ont une destination ou une décision de retrait |
| Le sens des Customers et Orders est-il documenté ? | Dossier de validation Customer/Order | Identité, statuts et relations historiques sont expliqués |
| La propriété de l’inventaire est-elle explicite ? | Carte sources/stocks/système de référence | Chaque SKU prioritaire a un propriétaire de quantité déclaré |
| Extensions et systèmes externes sont-ils inventoriés ? | Registre de dépendances | Chaque dépendance critique a un propriétaire futur |
| Les échantillons représentatifs sont-ils sélectionnés ? | Registre d’échantillons | Structures ordinaires et exceptionnelles sont couvertes |
| Les éléments non résolus sont-ils contrôlés ? | Journal de décisions | Chaque point ouvert a un responsable et une échéance |
La préparation est suffisante lorsque plus aucune décision critique concernant Products, attributs, Customers, Orders, inventaire, URL ou extensions ne repose sur une hypothèse non documentée.
Conclusion
La préparation d’une migration vers Magento doit produire un ensemble d’éléments récupérables et spécifiques à la plateforme. Types de Products, jeux d’attributs, Categories, store views, sources d’inventaire, groupes de Customers, Orders historiques, extensions, contenu, URL et identifiants externes doivent tous avoir des responsables explicites.
Lorsque ces décisions sont documentées avant le test représentatif, les échantillons peuvent véritablement vérifier l’architecture Magento prévue au lieu de forcer l’équipe à l’inférer après import.
Questions fréquentes
Quel document de préparation faut-il créer en premier ?
Commencez par la carte de structure cible couvrant websites, store views, types de Products, attributs, inventaire, Customers, Orders, contenu et intégrations. Elle détermine les éléments nécessaires pour le reste de la préparation.
Pourquoi les échantillons de Products sont-ils plus importants que les volumes ?
Les volumes ne montrent pas les relations configurables, composants de bundles, options personnalisées, valeurs localisées ou champs appartenant à des extensions. Des familles représentatives révèlent les structures que la cible doit réellement prendre en charge.
Chaque champ source doit-il devenir un attribut Magento ?
Non. Une valeur peut appartenir à une variante, une option personnalisée, du contenu, une extension, un système externe ou une exclusion volontaire. Affectez-la selon sa finalité métier et le système qui continuera à la consommer.
Comment préparer les jeux d’attributs ?
Regroupez les Products selon de vrais besoins de gestion, définissez les attributs nécessaires à chaque groupe, normalisez les valeurs contrôlées, documentez leur portée et supprimez les champs obsolètes ou dupliqués.
Quand faut-il préparer l’inventaire séparément des données de catalogue ?
Dès que le stock dépend de sources, stocks, websites, SKU enfants configurables, backorders, réservations ou d’un ERP, WMS, marketplace ou flux fournisseur externe.
Que faire des données d’extensions ou de modules personnalisés ?
Identifiez le module, l’enregistrement du cœur concerné, l’objectif métier, les tables ou champs, les identifiants externes et le propriétaire cible. Les données importantes ont besoin d’une destination explicite ; les données obsolètes peuvent être archivées ou exclues.