Si OpenCart est retenu comme plateforme cible, la préparation doit rendre la boutique source compréhensible avant de finaliser toute configuration de migration. Une vitrine peut sembler simple alors que les relations importantes sont réparties entre Products, options réutilisables, attributs, filtres, Categories, Manufacturers, groupes de Customers, remises, promotions spéciales, plusieurs boutiques, mots-clés SEO, extensions, thèmes et champs de base de données personnalisés.
L’objectif de la préparation est de transformer cette structure distribuée en éléments sources contrôlés. Pour chaque domaine important, il faut définir l’action à accomplir, le responsable capable d’en confirmer le sens métier, les éléments à fournir et la condition qui permettra de considérer le domaine comme prêt. Cela évite de traiter un simple export Products comme une description complète de la boutique alors que des choix d’achat, des règles de découverte, l’historique d’Orders ou des valeurs détenues par des extensions résident ailleurs.
Établir les accès et consigner l’environnement OpenCart
Commencez par documenter l’installation OpenCart réellement utilisée. Relevez la version, la boutique active ou la structure multi-boutique, l’emplacement de la base de données, la racine documentaire, le chemin d’administration, les langues et devises actives, le thème actuel ainsi que le système d’extensions ou de modifications utilisé. Une boutique ancienne peut contenir des extensions OpenCart Marketplace, des changements OCMOD ou VQMod, des fichiers de thème modifiés, des tables personnalisées ou même des modifications directes du cœur.
Les accès doivent être préparés selon la méthode de connexion appropriée au parcours de migration sélectionné. Le marchand ne doit pas considérer l’accès à la base de données, les identifiants d’administration, l’accès à l’hébergement, des identifiants API ou un paquet de fichiers comme interchangeables. Il faut préparer les accès et éléments disponibles pour la boutique réelle, puis garder le responsable des accès disponible pour résoudre les restrictions ou permissions manquantes.
| Action | Responsable | Éléments à fournir | Condition de préparation |
|---|---|---|---|
| Consigner la version exacte d’OpenCart et les identifiants des boutiques actives | Administrateur de la boutique | Capture de version, liste des boutiques, note d’environnement | Chaque boutique active et la version source sont identifiées. |
| Confirmer l’accès à la source | Responsable hébergement ou technique | Identifiants disponibles, informations d’allowlist, note de test d’accès | La connexion source requise atteint l’installation prévue. |
| Identifier les couches de thème et de modifications | Développeur ou agence | Nom du thème, listes OCMOD/VQMod, inventaire des fichiers modifiés | Les enregistrements natifs et le fonctionnement dépendant du code peuvent être distingués. |
| Consigner langues, devises, paramètres fiscaux et unités | Responsable commerce | Export des paramètres ou captures | Les valeurs globales influençant le sens des Products et Orders sont documentées. |
| Identifier les imports ou synchronisations planifiés | Responsable des intégrations | Calendrier des flux, liste des systèmes externes, trace de dernière exécution | L’équipe sait quelles valeurs peuvent changer pendant la préparation. |
Fixez une date de référence à partir de laquelle les changements structurels non contrôlés doivent être consignés. Les ventes courantes peuvent continuer, mais toute nouvelle extension, modification de schéma, restructuration massive du catalogue ou réécriture d’URL doit être enregistrée après constitution des éléments sources.
Préparer Products, options, attributs et filtres comme ensembles distincts
OpenCart distingue les enregistrements Products des options, attributs et filtres. Les options recueillent des valeurs sélectionnées ou saisies par le client et peuvent modifier le prix, le poids, les points de récompense, la quantité ou le caractère obligatoire. Les attributs décrivent les Products. Les filtres soutiennent la découverte via les relations avec Products et Categories. Regrouper ces structures dans une seule feuille peut masquer la différence entre choix d’achat, spécification et outil de navigation.
Créez un inventaire Products comprenant modèle, SKU ou autres identifiants, statut, quantité, état de stock, prix, classe fiscale, poids, dimensions, Manufacturer, Categories, images, Downloads, Products associés, promotions spéciales, remises, récompenses, options, attributs et filtres lorsqu’ils sont utilisés. L’inventaire n’a pas besoin de reproduire chaque colonne de base de données, mais il doit révéler les relations qui distinguent Products simples et complexes.
| Structure source | Action de préparation | Éléments requis | Condition de préparation |
|---|---|---|---|
| Option obligatoire ou modifiant le prix | Consigner type d’option, valeurs, caractère obligatoire et ajustements | Identifiants Products et affectations d’options représentatives | L’effet commercial de l’option est explicite. |
| Saisie texte, textarea, fichier, date ou heure | Séparer les données saisies par le client des valeurs d’options réutilisables | Liste Products et exemples de lignes d’Orders utilisant la saisie | La saisie propre à l’achat n’est pas confondue avec une variante. |
| Spécification technique | Consigner groupe d’attributs, attribut, valeur linguistique et affectation Product | Export des attributs ou échantillon structuré | Les données descriptives sont séparées des choix sélectionnables. |
| Filtre de vitrine | Consigner groupe, valeur, affectation Product et affectation Category | Carte des filtres actifs | Seuls les filtres réellement utilisés dans les parcours de découverte sont conservés. |
| Product avec plusieurs images ou Downloads | Consigner séquence des médias et disponibilité des fichiers | Liste des médias, chemins et identifiants Products représentatifs | Les fichiers et leurs relations Products sont disponibles. |
| Promotions spéciales ou remises selon groupe de Customers | Consigner Product, groupe, montant ou pourcentage, seuil de quantité et dates | Inventaire des règles tarifaires | Les conditions tarifaires sont complètes et ne sont pas réduites au prix de base. |
Normalisez uniquement les défauts sources évidents. Les doublons de libellés d’options, incohérences de casse, filtres inutilisés ou identifiants vides peuvent être signalés, mais ne fusionnez pas des valeurs simplement parce qu’elles se ressemblent. Toute normalisation modifiant le sens visible pour le client doit être approuvée par le responsable commerce.
Documenter Categories, Manufacturers, boutiques et relations de découverte
Les Categories OpenCart peuvent former des hiérarchies, porter des contenus multilingues, se relier aux filtres et être affectées à des boutiques précises. Les Products peuvent appartenir à plusieurs Categories et boutiques. Les Manufacturers peuvent servir de simples propriétés Product ou de pages publiques de marque. Ces relations doivent être documentées séparément de la présentation du menu.
Préparez l’arborescence active des Categories avec identifiants parents, affectations par boutique, statut, ordre, images, descriptions, métadonnées, filtres et URL actuelles. Signalez les Categories obsolètes, masquées, dupliquées pour la navigation ou conservées uniquement pour d’anciens liens. Pour les Manufacturers, indiquez lesquels ont des routes publiques, des descriptions utiles, des images ou une valeur pour la recherche.
Pour les installations multi-boutique, créez une matrice de périmètre. Un Product ou une Category disponible dans la boutique par défaut n’appartient pas forcément à toutes les autres. Langues, thèmes, domaines, pages de contenu et paramètres peuvent également varier. Les éléments finaux doivent montrer si les enregistrements sont partagés, dupliqués ou propres à une boutique.
| Domaine de découverte | Responsable | Éléments à fournir | Condition de préparation |
|---|---|---|---|
| Hiérarchie de Categories | Responsable catalogue | Export parent-enfant et liste des Categories actives | Chaque Category conservée a un parent et une finalité métier connus. |
| Affectations Product-to-Category | Responsable merchandising | Products représentatifs appartenant à plusieurs Categories et export des affectations | Le placement partagé est visible sans créer de Products dupliqués. |
| Pages Manufacturer | Responsable marque ou SEO | Liste des Manufacturers, inventaire des routes, notes de visibilité | Les marques publiques sont distinguées des valeurs internes. |
| Affectations par boutique | Responsable multi-boutique | Matrice Products, Categories, pages Information et domaines | Chaque enregistrement possède un périmètre de boutique prévu. |
| Filtres et navigation | Responsable merchandising | Carte filtre-to-Category et captures de menus | La classification du catalogue est séparée de la présentation du menu. |
Préparer Customers, groupes de Customers, adresses et historique d’Orders
La préparation des Customers doit distinguer identité du compte, carnet d’adresses, appartenance à un groupe, état d’approbation, préférences marketing, points de récompense, champs personnalisés et identifiants externes. Un groupe de Customers peut contrôler remises, prix Products, traitement fiscal, accès aux paiements ou workflows d’approbation ; son effet métier doit être documenté au-delà du nom du groupe.
Pour les Orders, l’objectif est de préserver les éléments historiques. Constituez un inventaire des statuts et sélectionnez des Orders couvrant achat guest et compte enregistré, plusieurs groupes de Customers, sélections d’options, remises, Coupons, récompenses, taxes, expédition, libellés de paiement, remboursements ou retours lorsqu’ils existent et totaux créés par des extensions. Identifiez les champs historiques nécessaires au personnel, à l’historique du compte Customer, au rapprochement comptable ou aux intégrations externes.
| Zone d’enregistrement | Action de préparation | Éléments à fournir | Condition de préparation |
|---|---|---|---|
| Comptes Customers | Identifier e-mails dupliqués, états d’approbation, champs personnalisés et clés externes | Synthèse Customers et liste des exceptions | Chaque exception d’identité a un responsable et une décision. |
| Groupes de Customers | Documenter chaque effet commercial ou d’accès actif | Matrice groupe-to-rule | Le sens du groupe est documenté au-delà de son libellé. |
| Adresses | Séparer les adresses réutilisables du Customer des instantanés au moment de l’Order | Échantillons d’adresses Customers et Orders | Données de compte actuelles et historique ne sont pas confondus. |
| Statuts d’Orders | Relier les statuts à leur sens opérationnel | Liste des statuts avec exemples d’Orders | Les états historiques sont interprétables sans dépendre uniquement d’une couleur ou d’un libellé. |
| Totaux d’Orders | Inventorier sous-total, taxes, expédition, Coupon, récompense, frais, crédit et lignes d’extensions | Totaux d’Orders représentatifs | Chaque ajustement important a un propriétaire source connu. |
| Références externes | Consigner identifiants ERP, marketplace, paiement, expédition ou comptabilité | Carte des identifiants | Les systèmes qui continueront à fonctionner peuvent retrouver le même Customer ou la même Order. |
Ne modifiez pas des Orders historiques uniquement pour les rendre plus cohérentes. Un libellé ou montant inhabituel peut être un élément important de la transaction d’origine. Consignez les anomalies connues séparément.
Inventorier extensions, modifications, thèmes et données personnalisées
Les extensions OpenCart peuvent ajouter champs, tables, fonctionnement d’options, lignes de total d’Orders, flux, listings de marketplace, étapes du processus de commande, données de paiement, références d’expédition, rapports, logique SEO ou workflows administratifs. Les thèmes peuvent aussi lire des champs personnalisés ou modifier l’affichage des options, filtres et contenus. Une simple liste de noms d’extensions ne suffit pas : la préparation doit préciser les enregistrements métier détenus par chacune.
Créez un registre des extensions avec statut, fournisseur, version, finalité, emplacement de stockage lorsqu’il est connu, types de données concernés, champs ou tables personnalisés, dépendances externes et responsable capable de confirmer si le fonctionnement reste nécessaire. Séparez les données métier actives de la configuration et des résidus techniques obsolètes.
| Effet de l’extension | Éléments à préparer | Décision de préparation |
|---|---|---|
| Champs Products ou options | Noms des champs, échantillons Products, table ou emplacement d’export | Chaque valeur active possède un propriétaire cible ou une exclusion volontaire. |
| Logique de total d’Order ou de processus de commande | Exemples d’Orders, libellés de totaux, synthèse de configuration du module | Les valeurs historiques sont séparables de la future configuration du processus de commande. |
| Intégration marketplace ou flux | Identifiants de listings, Categories du canal, clés de synchronisation | L’identité canonique du Product et les enregistrements du canal sont distingués. |
| Modification SEO ou URL | Exemples de routes actuelles, tables de redirection, configuration de réécriture | Les chemins sources importants peuvent être reconstruits. |
| Contenu dépendant du thème | Captures, chemins de templates, affectations de blocs/modules | Le contenu est séparé du code de présentation. |
| Extension abandonnée | Trace de dernière utilisation et confirmation du propriétaire des données | Les enregistrements obsolètes sont identifiés pour archivage ou exclusion. |
Préparer contenus, mots-clés SEO, médias et éléments de routage
OpenCart peut affecter des mots-clés SEO aux Products, Categories, Manufacturers et pages Information. Constituez un inventaire des routes indiquant l’objet source, le périmètre de boutique et de langue, le chemin actuel, le mot-clé SEO, l’importance en trafic ou en valeur métier et la décision prévue. Signalez les mots-clés dupliqués, les valeurs manquantes sur les enregistrements importants, les routes générées par des extensions et les chemins dépendant de la configuration de réécriture serveur.
La préparation du contenu doit inclure pages Information, descriptions Products et Categories, contenus Manufacturer, bannières, mises en page, modules et fichiers médias qui restent utiles. Indiquez si chaque élément est un enregistrement de contenu à migrer, une tâche de configuration de la boutique cible, un actif de thème, une ressource externe ou un contenu obsolète.
Sauvegardez les images et Downloads originaux avec leurs chemins. Un export de base de données peut contenir les noms de fichiers sans contenir les fichiers eux-mêmes. Identifiez les fichiers manquants, URL externes, différences de casse dans les chemins et miniatures générées qui ne doivent pas devenir des originaux sources.
Constituer le paquet de sauvegarde et de préparation des entrées
Créez un paquet source restaurable avant tout nettoyage structurel ou exécution de migration. Pour une boutique OpenCart auto-hébergée, cela comprend normalement une sauvegarde de base de données, l’arborescence de fichiers pertinente, des informations d’environnement, des références de configuration et des éléments prouvant que la sauvegarde correspond au même état de boutique.
| Composant | Responsable | Éléments à fournir | Condition de préparation |
|---|---|---|---|
| Sauvegarde de base de données | Responsable hébergement ou base de données | Dump horodaté et note de possibilité de restauration | Le dump est complet et rattaché à la bonne base. |
| Fichiers et médias | Responsable hébergement ou technique | Archive ou arborescence accessible | Images originales, Downloads, extensions et fichiers de thème sont disponibles. |
| Relevé d’environnement | Responsable technique | Notes PHP, base de données, serveur web et extensions | Le fonctionnement sensible aux versions peut être interprété. |
| Registre des accès | Responsable projet | Responsable de chaque accès et état de disponibilité | Les accès requis sont disponibles sans placer les identifiants dans les documents de planification. |
| Journal des changements | Administrateur de boutique | Changements intervenus après la date de référence | Les changements structurels tardifs peuvent être incorporés volontairement. |
Sélectionner des échantillons représentatifs pour les tests de migration
L’échantillon doit révéler les relations qui définissent réellement la boutique OpenCart. Préparez un manifeste compact avec identifiants sources, raison métier, fichiers associés et structure source attendue pour chaque cas. Il est prêt lorsque chaque enregistrement sélectionné dispose d’éléments sources complets et d’un responsable de validation désigné.
Incluez au minimum :
- un Product simple et un Product inactif ou archivé ;
- des Products avec options obligatoires, modifiant le prix, texte, fichier, date ou sensibles au stock lorsque ces structures sont utilisées ;
- des Products avec attributs, filtres, plusieurs Categories, Manufacturers, plusieurs images, Downloads, promotions spéciales et remises par groupe de Customers ;
- des Customers appartenant à des groupes significatifs, une Order guest et une Order d’un Customer enregistré ;
- des Orders avec valeurs d’options, Coupons, récompenses, taxes, expédition, références de paiement, totaux inhabituels et identifiants externes ;
- une route importante pour chaque type d’objet public ;
- un enregistrement actif détenu par une extension et un exemple de contenu dépendant du thème.
Appliquer le contrôle final de préparation OpenCart
OpenCart est prêt pour l’étape suivante lorsque la source peut être décrite sans dépendre d’hypothèses non documentées.
| Question de préparation | Résultat requis |
|---|---|
| L’installation exacte et le périmètre de boutique sont-ils connus ? | Version, boutiques, langues, devises, thème et couches de modification sont consignés. |
| Les relations Products sont-elles complètes ? | Options, attributs, filtres, Categories, médias, règles de prix et identifiants sont représentés. |
| Customers et Orders sont-ils interprétables ? | Logique des groupes, adresses, statuts, totaux et références externes ont des propriétaires. |
| Extensions et données personnalisées sont-elles classées ? | Chaque dépendance active a une finalité métier et une décision de destination. |
| Contenus et URL sont-ils inventoriés ? | Routes importantes, pages Information, médias et dépendances de réécriture sont documentés. |
| Sauvegardes et accès sont-ils prêts ? | Le paquet source est restaurable et la connexion requise est disponible. |
| L’échantillon est-il représentatif ? | Cas simples et complexes sont listés avec leurs identifiants sources et relations attendues. |
Les points non résolus doivent être consignés dans un journal de décisions avec responsable et échéance. La préparation n’est pas terminée lorsqu’un champ critique, une table d’extension, une affectation de boutique ou un identifiant externe reste décrit uniquement comme « inconnu ».
Conclusion
La préparation d’une migration vers OpenCart est plus solide lorsqu’elle considère la boutique comme un catalogue et un système opérationnel reliés, et non comme un export plat de Products. Options, attributs, filtres, Categories, boutiques, groupes de Customers, totaux d’Orders, extensions, thèmes, médias et mots-clés SEO ont chacun besoin d’un responsable et d’un ensemble d’éléments explicites.
Un paquet source contrôlé, un manifeste d’échantillons représentatifs et un contrôle de préparation explicite fournissent une base fiable pour la configuration de la migration.
Questions fréquentes
Pourquoi faut-il préparer séparément les options, attributs et filtres OpenCart ?
Parce qu’ils servent des fonctions différentes. Les options recueillent des choix d’achat ou des saisies du client, les attributs décrivent les Products et les filtres facilitent la découverte du catalogue. Les fusionner peut créer des structures de variantes incorrectes ou supprimer des spécifications et relations de navigation utiles.
Que faut-il consigner pour une installation OpenCart multi-boutique ?
Consignez chaque identifiant de boutique, domaine, langue, devise, thème, paramètres, affectations Products/Categories, pages Information et URL importantes. Les enregistrements partagés doivent pouvoir être distingués des enregistrements propres à chaque boutique.
Une sauvegarde de base de données contient-elle les images et Downloads OpenCart ?
Non. La base stocke généralement des références de fichiers, tandis que les images originales, Downloads, actifs de thème et fichiers d’extensions restent dans le système de fichiers. Préparez à la fois les éléments de base de données et les fichiers.
Comment préparer les données détenues par des extensions OpenCart ?
Consignez l’extension, les types de données concernés, les champs ou tables personnalisés, des enregistrements sources représentatifs, les dépendances externes et la finalité métier qui doit continuer. Chaque valeur active a besoin d’un propriétaire explicite ; les enregistrements obsolètes peuvent être destinés à l’archivage ou à l’exclusion.
Quels enregistrements OpenCart inclure dans l’échantillon représentatif ?
Utilisez des Products ordinaires et complexes, plusieurs types d’options, attributs et filtres, relations multi-Categories, groupes de Customers, Orders significatives, routes importantes et enregistrements actifs détenus par des extensions. Le manifeste doit inclure les identifiants sources et les relations attendues.
Faut-il modifier les mots-clés SEO dupliqués pendant la préparation ?
Commencez par les signaler et désigner un responsable. Ne les modifiez qu’après une décision URL approuvée qui consigne la destination prévue et la relation de redirection, car un mot-clé apparemment dupliqué peut encore avoir une valeur de trafic ou d’intégration.