Si Shopify est retenu comme plateforme cible, la préparation doit transformer la boutique source en un ensemble de décisions claires et étayées avant le début de toute exécution de migration. L’objectif n’est pas de concevoir à l’avance toute la future boutique, mais de déterminer comment les Products, variantes, collections, Customers, Orders, contenus, URL, applications, metafields, metaobjects, Markets et identifiants externes importants doivent être représentés dans Shopify.
Un bon dossier de préparation répond à quatre questions pour chaque domaine important : quelles informations doivent être fournies, qui est responsable de la décision, quelles preuves la justifient et quelle condition permet de considérer ce domaine comme prêt. Cela évite que le test de migration représentatif soit la première occasion de découvrir qu’une option source est en réalité une saisie personnalisée de Product, qu’une Category correspond plutôt à une page de campagne ou qu’un groupe Customer dépend d’un système wholesale externe.
Définir les décisions relatives à la plateforme cible Shopify
Avant de collecter des fichiers, définissez les structures Shopify qui recevront les relations importantes de la source. Le registre de décisions doit identifier le propriétaire Shopify prévu pour chaque relation source importante.
| Domaine de préparation | Décision à consigner | Responsable | Preuve de préparation |
|---|---|---|---|
| Structure Product | Déterminer quels enregistrements source deviennent des Products, variantes, metafields, metaobjects, tags ou enregistrements gérés par une application | Responsable catalogue | Exemples de correspondance approuvés pour chaque grande famille de Products |
| Organisation du catalogue | Déterminer quelles Categories source deviennent des collections manuelles ou automatisées, liens de navigation, filtres, pages d’atterrissage ou redirections | Responsables merchandising et contenu | Schéma des collections et de la navigation avec exemples de parcours source représentatifs |
| Continuité Customer | Déterminer quelles relations de compte, tags, fiscalité, wholesale, fidélité, abonnements ou CRM externe doivent rester utilisables | Opérations Customer | Inventaire des relations Customer et plan de communication pour l’accès au compte |
| Historique des Orders | Déterminer quels statuts, détails de ligne, remboursements, notes et références externes le personnel doit conserver | Opérations et support | Liste d’échantillons d’Orders historiques et notes expliquant le sens des champs |
| Structure internationale | Déterminer quels pays, langues, devises, domaines, sous-dossiers, contenus localisés et enregistrements propres à un marché sont importants | Responsable international | Matrice Markets et domaines |
| Données personnalisées | Déterminer quels champs personnalisés source deviennent des metafields Shopify, metaobjects, enregistrements d’application, contenus ou exclusions | Responsables catalogue et technique | Inventaire des champs avec propriétaire cible et consommateur qui continuera de les utiliser |
N’utilisez pas les volumes d’enregistrements comme principal indicateur de préparation. Les volumes décrivent la taille ; ils ne déterminent pas si une option source doit devenir une variante Shopify, si un bundle doit rester une relation gérée par une application ou si un Catalog régional nécessite des décisions distinctes concernant Shopify Markets et le contenu.
Préparer les accès et les preuves de la boutique source
Préparez les accès à la source et à Shopify nécessaires pour récupérer, interpréter et préserver les enregistrements inclus dans le périmètre. Le dossier doit pouvoir être utilisé par une personne qui n’a pas configuré la boutique source et ne doit pas dépendre de connaissances non documentées détenues par certains membres de l’équipe.
Collectez :
- les accès administrateur à la boutique source et à la boutique Shopify avec le niveau d’autorisation requis ;
- des exports ou rapports récents concernant Products, Customers, Orders, Categories, contenus, avis, remises et autres enregistrements inclus dans le périmètre ;
- les fichiers médias Product lorsque les URL source sont temporaires, protégées ou peu fiables ;
- les listes actuelles des domaines, sous-domaines, dossiers de langue et URL régionales ;
- les inventaires d’applications et d’intégrations, avec le responsable métier et le responsable du système externe ;
- les définitions des champs source pour les attributs personnalisés, jeux d’options, règles de groupe et identifiants externes ;
- des exemples d’enregistrements que le personnel considère comme commercialement critiques ou exceptionnellement complexes ;
- un instantané daté de la source et une note identifiant les données susceptibles de continuer à évoluer avant la fenêtre de migration.
| Élément de preuve | Pourquoi il est nécessaire | Condition de préparation |
|---|---|---|
| Accès à la source | Permet de vérifier la signification des données par rapport au contexte réel d’administration | L’accès fonctionne et les domaines de données requis sont visibles |
| Accès à Shopify | Permet de confirmer la configuration cible et la propriété des enregistrements | Les autorisations requises sont disponibles sans partage informel d’identifiants personnels |
| Archive d’exports | Conserve une copie de référence de l’état de la source | Les fichiers s’ouvrent correctement, contiennent les enregistrements attendus et portent une date d’export |
| Dictionnaire des champs personnalisés | Explique les libellés qui seraient autrement ambigus | Chaque champ important possède un objectif, un responsable et une valeur d’exemple |
| Liste des identifiants externes | Protège la continuité avec ERP, PIM, CRM, WMS, marketplaces ou comptabilité | Chaque identifiant est rattaché au bon niveau Product, variante, Customer ou Order |
Si un export omet des enregistrements importants gérés par une application, documentez cette lacune au lieu d’en déduire que les enregistrements n’existent pas. L’absence d’un export d’application, une source média protégée ou une table personnalisée non documentée constitue un problème de préparation qui doit avoir un responsable.
Préparer les Products, variantes et données personnalisées du catalogue
La préparation des Products Shopify doit distinguer les véritables combinaisons vendables des informations descriptives, des valeurs saisies par l’acheteur, des relations de merchandising et des données appartenant à des systèmes externes.
Créez un inventaire des familles de Products couvrant :
- les Products simples avec une seule configuration vendable ;
- les Products comportant plusieurs options et des différences de SKU, code-barres, prix, stock, poids, image, fiscalité ou traitement des commandes au niveau des variantes ;
- les Products dont certaines combinaisons d’options source doivent être consolidées, séparées ou retirées ;
- les bundles, kits, abonnements, précommandes, garanties et autres comportements associés aux choix d’achat ;
- les Products personnalisés qui recueillent du texte, des fichiers, des dates, des mesures ou des choix conditionnels ;
- les Products comportant des spécifications techniques, tableaux de compatibilité, guides de tailles, documents ou données de référence structurées ;
- les Products dont le contenu ou la disponibilité varie selon la région, le canal ou le type de Customer ;
- les Products synchronisés avec un ERP, un PIM, un entrepôt, une marketplace ou un flux fournisseur.
Pour chaque famille, préparez un exemple de feuille de correspondance :
| Comportement source | Décision de préparation pour Shopify | Preuve à joindre |
|---|---|---|
| Le choix crée un SKU ou une unité de stock distincte | Définir la relation prévue entre Product et variante | Identifiants parent/enfant source, valeurs d’option, SKU, stock, prix et exemples d’images |
| La valeur décrit le Product | Définir un metafield, metaobject, contenu Product ou autre destination structurée | Objectif du champ, type de données, valeurs autorisées et responsable de l’affichage |
| Le Customer saisit une valeur ponctuelle | Identifier l’entrée Product, l’application ou la relation de ligne d’Order qui la prendra en charge | Exemple dans la boutique et exemple de ligne d’Order historique |
| Le Product est un bundle, un abonnement ou un ensemble configurable | Identifier l’application ou la structure cible responsable du comportement | Liste des composants, logique de prix, responsable du stock et exemples d’Orders |
| La valeur est utilisée uniquement par un système externe | La conserver au bon niveau Product ou variante | Nom du système externe, règle d’unicité et exemple de recherche |
Normalisez les noms d’options et d’attributs avant qu’ils ne deviennent des structures Shopify. Décidez si « Colour », « Color » et « Finish » représentent un même concept contrôlé ou des concepts volontairement distincts. Supprimez les valeurs obsolètes, incohérentes ou créées uniquement pour contourner les limites de la plateforme source.
Préparer collections, navigation, Markets, contenus et URL
Les Categories source correspondent rarement de manière directe aux collections Shopify. Préparez une classification de chaque regroupement et route importants.
| Structure source | Question de préparation | Preuve de préparation |
|---|---|---|
| Category permanente | Doit-elle devenir une collection manuelle, une collection automatisée ou une autre destination ? | Règle de collection ou exemple d’appartenance de Products |
| Regroupement utilisé uniquement dans le menu | Relève-t-il de la navigation plutôt que de la classification du catalogue ? | Hiérarchie de menu prévue et liens de destination |
| Groupe de campagne ou saisonnier | S’agit-il d’une collection temporaire, d’une page d’atterrissage, d’une promotion ou d’une route à retirer ? | Responsable de campagne et décision de conservation/retrait |
| Valeur de filtre | Doit-elle utiliser la catégorie Product, des valeurs d’option, des metafields ou des données de recherche gérées par une application ? | Liste contrôlée de valeurs et responsable du filtrage |
| Route régionale | Quel Market, domaine, langue, devise et relation de contenu localisé s’appliquent ? | Matrice Market et URL |
Préparez un inventaire des Products, collections, CMS Pages, Blog Posts, pages de politique, guides et pages de campagne actives. Pour chaque route prioritaire, consignez l’URL source, la destination Shopify prévue, le responsable du contenu, les besoins de localisation et les besoins de redirection.
Incluez :
- les URL Product à fort trafic ou fort chiffre d’affaires ;
- les pages d’atterrissage de Category et de marque disposant de backlinks ou de valeur pour les campagnes payantes ;
- les CMS Pages et Blog Posts importants pour la confiance, le SEO ou le service client ;
- les chemins localisés ou régionaux ;
- les routes de Products abandonnés nécessitant une destination de remplacement pertinente ;
- les liens internes intégrés dans les descriptions, Blog Posts, pages et menus ;
- les fichiers, documents et images référencés dans le contenu source.
La condition de préparation n’est pas « toutes les URL ont été exportées ». Chaque chemin source prioritaire doit disposer d’une destination Shopify définie ou d’une décision explicite de retrait.
Préparer les Customers, les comptes et les Orders historiques
La préparation des Customers doit distinguer l’identité des applications et règles qui lui sont associées. Préparez des exemples de Customers enregistrés, acheteurs invités, adresses multiples, traitement fiscal, tags ou groupes, relations B2B, fidélité, abonnements, adhésions et références CRM externes.
Ne supposez pas que les identifiants d’authentification de la source pourront être réutilisés dans Shopify. Préparez la communication destinée aux Customers et l’approche d’accès au compte que l’entreprise utilisera lorsque les Customers migrés devront accéder à la nouvelle boutique.
Pour les Orders, préparez des exemples qui révèlent la complexité historique :
- Orders payés, en attente, annulés, remboursés et partiellement remboursés ;
- Orders partiellement traités ou répartis en plusieurs expéditions ;
- Orders contenant remises, cartes cadeaux, crédit boutique, taxes, droits, ajustements d’expédition ou modifications manuelles ;
- Orders contenant des saisies Product personnalisées, bundles, abonnements ou données de ligne gérées par des applications ;
- Orders liés à des marketplaces, ERP, systèmes comptables, outils de traitement des commandes, support ou CRM ;
- Orders provenant de chaque Market, devise ou boutique prioritaire.
| Élément de préparation | Responsable | Preuve requise | Condition de préparation |
|---|---|---|---|
| Règles d’identité Customer | Opérations Customer | Exemples de comptes dupliqués et identifiants externes | Les règles de fusion, de maintien séparé et de gestion des invités sont documentées |
| Accès au compte | Expérience Customer | Projet de communication et équipe responsable | Le personnel sait comment les Customers récurrents récupéreront l’accès |
| Classifications Customer | Responsable B2B, fiscalité, fidélité ou CRM | Exemples de groupes/tags et règle métier associée | Le propriétaire cible de chaque classification est défini |
| Sens des Orders historiques | Support et finance | Dossier d’Orders représentatifs | Les lignes, ajustements, statuts, remboursements et références sont expliqués |
| Périmètre des données sensibles | Responsable juridique ou des données | Liste de champs approuvée | Les données personnelles inutiles ou non prises en charge sont exclues |
Inventorier applications, intégrations et dépendances externes
Créez un registre unique des dépendances pour chaque application, extension source, script, groupe de champs personnalisés, automatisation, webhook et système externe qui modifie le comportement des Products, Customers, Orders, prix, contenus ou processus de traitement des commandes.
Pour chaque dépendance, consignez :
- l’objectif métier ;
- les types d’enregistrements créés ou modifiés ;
- les enregistrements Shopify ou source parents concernés ;
- le responsable des données et le responsable technique ;
- la disponibilité d’un export ou d’une API ;
- les identifiants externes utilisés pour le rapprochement ;
- si la dépendance continuera, sera remplacée ou sera retirée ;
- les données qui doivent exister avant de pouvoir configurer le remplacement.
Les dépendances prioritaires comprennent souvent les avis, la recherche et le filtrage, les abonnements, les bundles, la fidélité, le B2B, la personnalisation Product, la fiscalité, l’expédition, les paiements, les listings marketplace, ERP, PIM, WMS, CRM, comptabilité, analyse des données et systèmes de consentement.
Le registre est prêt lorsque chaque dépendance commercialement importante possède un responsable cible identifié. « L’application s’en occupait » ne constitue pas une preuve suffisante.
Sélectionner des échantillons pour un test de migration représentatif
L’ensemble d’échantillons doit révéler les décisions de préparation importantes pour Shopify sans chercher à représenter tout le catalogue. Sélectionnez délibérément les enregistrements et joignez les notes de propriété attendues.
| Échantillon | Objectif de préparation |
|---|---|
| Product simple | Établir le modèle ordinaire de Product, collection, image et stock |
| Product avec de nombreuses variantes | Mettre en évidence les noms d’options, l’identité des variantes, les images, le stock et les identifiants externes |
| Product avec contenu structuré | Mettre en évidence les besoins en metafields ou metaobjects |
| Product personnalisé ou dépendant d’une application | Mettre en évidence les saisies Customer ou la propriété applicative |
| Collection et URL prioritaires | Mettre en évidence les décisions de regroupement, navigation, contenu et redirection |
| Customer complexe | Mettre en évidence les adresses, classifications, identifiants externes et la préparation de l’accès au compte |
| Order historique complexe | Mettre en évidence les détails de ligne, remises, traitement des commandes, remboursements et références externes |
| Enregistrement localisé ou propre à un Market | Mettre en évidence la langue, le domaine, la devise et le périmètre du contenu régional |
Pour chaque échantillon, indiquez l’identifiant de l’enregistrement source, l’URL source le cas échéant, la raison métier de la sélection, le propriétaire Shopify attendu, les identifiants externes liés et les exclusions connues. Le registre est prêt lorsque chaque enregistrement sélectionné possède une attente source, les identifiants associés, des exclusions connues et un relecteur désigné.
Valider la préparation à la migration vers Shopify
Utilisez une validation finale de préparation avant de planifier l’exécution de la migration.
| Question de préparation | Preuve requise | Condition de préparation |
|---|---|---|
| Les accès requis sont-ils disponibles ? | Journal des accès et contacts responsables | Les zones nécessaires de la source et de Shopify sont accessibles |
| Les familles de Products sont-elles classées ? | Matrice des familles Product | Chaque modèle Product important possède un propriétaire cible |
| Les décisions concernant collections et URL sont-elles terminées ? | Inventaire des routes et schéma des collections | Les routes prioritaires ont une destination ou une décision de retrait |
| Les exemples de Customers et Orders sont-ils expliqués ? | Dossier de preuves Customer et Order | Les relations historiques et de compte sont documentées |
| Les applications et systèmes externes sont-ils inventoriés ? | Registre des dépendances | Chaque dépendance importante possède un responsable qui continuera de la gérer |
| Les sauvegardes et exports source sont-ils à jour ? | Archive datée et checksum ou liste de fichiers | Les preuves source peuvent être récupérées indépendamment de la boutique active |
| Les échantillons de migration représentatifs sont-ils sélectionnés ? | Registre des échantillons | L’ensemble couvre les enregistrements ordinaires et exceptionnels |
| Les éléments non résolus ont-ils un responsable ? | Journal des décisions | Chaque élément ouvert possède un responsable et une échéance |
La migration est prête sur le plan de la préparation lorsqu’aucune décision critique concernant Products, Customers, Orders, URL ou intégrations ne dépend d’hypothèses non documentées. La revue finale doit également confirmer que le dossier de preuves peut être compris par des personnes extérieures à l’équipe qui a construit la boutique source. Si une décision dépend de la mémoire d’une seule personne concernant le fonctionnement d’une ancienne application ou d’un ancien champ, cette connaissance doit être consignée avant de planifier la migration.
Conclusion
La préparation à une migration vers Shopify doit produire un dossier de preuves pratique, et non une checklist générique. Les Products et variantes ont besoin d’une propriété définie, les collections doivent être distinguées de la navigation et des URL, l’identité Customer doit être séparée du comportement du compte et des applications, les Orders historiques ont besoin de preuves représentatives, et chaque application ou identifiant externe doit avoir un responsable qui perdure.
Lorsque ces décisions sont documentées avant le test de migration représentatif, l’équipe peut évaluer la représentation Shopify prévue au lieu de découvrir le modèle cible à partir d’enregistrements migrés isolés.
Questions fréquentes
Quel document de préparation Shopify faut-il créer en premier ?
Commencez par la carte des décisions cibles pour Products, collections, Customers, Orders, contenus, Markets, applications et systèmes externes. Elle détermine les exports, échantillons et responsables nécessaires pour le reste du dossier de préparation.
Combien de Products faut-il sélectionner pour préparer un test de migration représentatif ?
Utilisez le plus petit ensemble couvrant chaque modèle Product important : simple, comportant de nombreuses variantes, avec contenu structuré, personnalisé, en bundle ou abonnement, localisé et synchronisé avec des systèmes externes. La couverture des comportements compte davantage qu’un nombre fixe.
Tous les champs personnalisés source doivent-ils devenir des metafields Shopify ?
Non. Certaines valeurs relèvent de metafields ou metaobjects ; d’autres du contenu Product, des variantes, des applications, des systèmes externes ou d’une exclusion volontaire. Classez chaque champ selon son objectif et son consommateur futur avant de choisir sa destination.
Quelles informations de compte Customer nécessitent une préparation particulière ?
Préparez les règles d’identité, la gestion des comptes dupliqués, des exemples d’adresses, les classifications Customer, les identifiants externes et l’approche de communication destinée aux Customers récurrents. Ne supposez pas que les identifiants de connexion source peuvent simplement être réutilisés.
Que doit contenir l’inventaire des URL Shopify ?
Incluez les routes prioritaires des Products, équivalents de collections, CMS Pages, Blog Posts, pages de politique, campagnes, routes localisées et routes disposant de liens externes. Chacune doit avoir une destination Shopify prévue ou une décision explicite de retrait.
Quand la préparation à la migration vers Shopify peut-elle être considérée comme terminée ?
Elle est terminée lorsque les accès requis fonctionnent, les preuves source peuvent être récupérées, les enregistrements importants ont des propriétaires cibles documentés, les échantillons représentatifs couvrent la complexité réelle et chaque élément non résolu possède un responsable identifié.