Si osCMax est retenu comme plateforme source dans un projet destiné à une plateforme cible, la préparation doit considérer la boutique comme une installation historique composée de plusieurs couches, et non comme un schéma produit figé. La base de données contient souvent un cœur dérivé d’osCommerce, des ajouts propres au package osCMax, des tables et colonnes détenues par des contributions, des modifications spécifiques au marchand, des ressources de template, des fichiers de langue et des identifiants de systèmes externes. Deux boutiques visuellement similaires peuvent donc exiger des preuves source très différentes.
L’objectif de préparation consiste à identifier la couche qui possède chaque donnée Product, Customer, Order, contenu et information opérationnelle importante. Chaque domaine de préparation doit définir une action, un responsable, un élément de preuve et une condition de préparation. Lorsque la documentation source faisant autorité n’est pas disponible, il ne faut pas inventer d’hypothèses sur le cycle de vie actuel, la compatibilité ou les fonctions intégrées précises ; l’installation réelle constitue la preuve.
Établir la lignée de version, l’historique de la boutique et l’accès à la source
Recensez tous les éléments disponibles permettant d’établir la lignée de l’installation osCMax : version affichée, package de version ou historique du dépôt, notes de mise à niveau, modifications du schéma de base de données, fichiers modifiés, contributions installées, package de template, environnement d’hébergement et intégrations externes. Lorsque plusieurs éléments se contredisent, consignez l’incertitude au lieu de retenir automatiquement l’étiquette qui paraît la plus récente.
| Action | Responsable | Preuve | Condition de préparation |
|---|---|---|---|
| Consigner la version et les éléments du package | Responsable technique | Pied de page de l’administration, fichiers du package, changelog, valeurs de version en base | Les indicateurs connus et contradictoires sont documentés. |
| Consigner l’historique des mises à niveau et de maintenance | Développeur, agence ou marchand | Notes de déploiement, dates de sauvegarde, historique des correctifs | Les principales transitions de schéma ou de code peuvent être identifiées. |
| Confirmer l’accès à la base de données et aux fichiers | Responsable de l’hébergement | État des accès, nom de la base, racine documentaire, disponibilité des archives | L’installation de production visée peut être examinée et sauvegardée. |
| Identifier les couches de templates et de langues | Responsable du storefront | Nom du template, répertoires de langue, surcharges, captures | Les fichiers de contenu et de présentation peuvent être séparés des données en base. |
| Identifier les tâches planifiées et systèmes externes | Responsable des intégrations | Liste cron, exports, imports, références ERP/comptabilité/livraison | Les données modifiées en dehors de l’administration sont connues. |
Évitez les modifications non documentées du code et du schéma pendant la constitution de ces preuves. L’activité peut continuer, mais les imports Product tardifs, installations de contributions, changements de champs ou remplacements de templates doivent être enregistrés dans un journal de changements.
Séparer les données e-commerce du cœur des données du package et des contributions
Commencez par le cœur dérivé d’osCommerce : Products, descriptions Product, Categories, fabricants, attributs, Customers, carnets d’adresses, Orders, Products dans les Orders, lignes de total Order, statuts, Reviews, promotions spéciales et autres relations standard présentes dans l’installation. Identifiez ensuite les champs et tables supplémentaires introduits par le package osCMax, les contributions ou les développements personnalisés.
Un nom de table familier ne prouve pas que toutes ses colonnes appartiennent au cœur. Construisez un inventaire du schéma et de la propriété indiquant la table, le champ ou la donnée, l’identifiant principal associé, la contribution ou modification qui l’a créé lorsqu’elle est connue, sa fonction métier, son utilisation actuelle et la décision prévue côté cible.
| Couche source | Preuves de préparation | Condition de préparation |
|---|---|---|
| Données Product et Category du cœur | Extraits Products, Categories, fabricants, attributs, prix, stock et images | Les relations principales du catalogue sont complètes. |
| Champs ajoutés par le package | Différence de schéma, captures de l’administration, données représentatives | Les valeurs propres au package sont distinguées des champs du cœur. |
| Table d’une contribution | Définition de table, relations de clés, nom du module, exemples d’IDs | La donnée métier de la table et ses données parentes sont identifiées. |
| Modification directe du cœur | Liste des fichiers modifiés et champs de base concernés | Le sens métier est documenté indépendamment de l’ancien code. |
| Champ d’un système externe | Cartographie des identifiants et système actuellement responsable | Les clés inter-systèmes stables restent traçables. |
| Table ou colonne obsolète | Preuve de dernière utilisation et décision du marchand | Le résidu technique est marqué pour archivage ou exclusion. |
Ne préparez pas une migration à partir d’une simple liste générique de tables osCommerce. Le schéma et le code réellement actifs déterminent la boutique source.
Préparer Products, attributs, stock par combinaison, images et tarification
Les anciennes options et attributs Product peuvent être étendus par des contributions ajoutant du stock par combinaison, des SKU indépendants, des images supplémentaires, des champs personnalisés, des remises par quantité, des prix par Customer Group, des téléchargements, bundles ou configurateurs Product. Documentez le fonctionnement métier de chaque structure au lieu de supposer que chaque option correspond à un attribut Product simple.
| Structure source | Action | Preuve | Condition de préparation |
|---|---|---|---|
| Attribut standard | Consigner option, valeur, affectation Product et effet sur prix ou poids | Export des attributs et IDs Product représentatifs | Le sens du choix d’achat est explicite. |
| SKU ou stock au niveau d’une combinaison | Identifier la table de contribution et la clé de combinaison | Matrice de combinaisons avec quantité et SKU | Les combinaisons vendables sont distinguées du Product parent. |
| Images multiples ou liées à un attribut | Consigner les fichiers, leur ordre et la relation Product/option | Manifeste média et chemins de fichiers | Les ressources originales et leur sens d’association sont disponibles. |
| Champ Product supplémentaire | Consigner propriétaire, type, utilisation d’affichage et consommateur externe | Ligne de schéma et Products d’exemple | Chaque valeur active possède un propriétaire côté cible. |
| Prix par quantité ou par Customer | Consigner Product, groupe ou seuil, devise, dates et montant | Inventaire tarifaire | La tarification conditionnelle n’est pas réduite au prix de base. |
| Product téléchargeable | Consigner fichier, relation d’accès, expiration ou limite si utilisée | Product et Orders historiques représentatifs | Les preuves liées à la livraison numérique sont complètes. |
Le responsable du catalogue doit approuver tout nettoyage des attributs, noms d’images, SKU ou prix en double. Ce qui ressemble à un doublon peut refléter le fonctionnement d’une contribution ou une clé de système externe.
Préparer Customers, carnets d’adresses, groupes et extensions de compte
La préparation Customer doit couvrir l’identité du compte, les entrées du carnet d’adresses, les relations avec l’adresse par défaut, les groupes ou classifications de vente en gros, les identifiants fiscaux, états d’approbation, données de fidélité ou de crédit, valeurs de parrainage, champs personnalisés et identifiants CRM ou comptables externes lorsqu’ils existent.
Créez un registre des extensions Customer. Pour chaque champ ou table ajoutée, consignez la clé Customer associée, la finalité métier, le caractère actuel ou historique de la valeur, le responsable des données personnelles et le système qui reste éventuellement la source faisant autorité.
| Domaine Customer | Preuve | Condition de préparation |
|---|---|---|
| Compte Customer | Identité, statut, exceptions e-mail, dates et identifiants externes | Les identités en double ou contradictoires ont une décision associée. |
| Carnet d’adresses | Lignes d’adresses et liens avec l’adresse par défaut | Les adresses réutilisables restent distinctes des instantanés Order. |
| Groupe grossiste ou revendeur | Affectation au groupe et effets sur prix, taxes, accès ou paiement | Le sens commercial est documenté au-delà du simple libellé. |
| Contribution de fidélité, crédit ou récompense | Solde, historique des mouvements et ID Customer parent | Le solde courant et la preuve historique peuvent être séparés. |
| Champs de profil personnalisés | Schéma, type de champ, finalité liée aux données personnelles, exemples | Chaque champ actif possède un propriétaire. |
Préparer Orders, totaux, historique des statuts et données d’extensions
Les Orders portent souvent les preuves historiques les plus importantes d’une boutique osCMax. Préparez les en-têtes Order, informations Customer ou invité, instantanés d’adresses de facturation et livraison, lignes Product, valeurs modèle ou SKU, attributs sélectionnés, quantités, prix, taxes, remises, livraison, libellés de paiement, statuts, commentaires et références externes.
Les modules de total Order exigent une attention particulière. Séparez sous-total, taxes, livraison, Coupon, bon cadeau, supplément, frais de petite commande, crédit, remise et autres lignes créées par des contributions. Préservez les libellés, montants, ordre d’affichage et relation avec le total final.
| Preuve Order | Responsable | Condition de préparation |
|---|---|---|
| Lignes Product et attributs | Responsable e-commerce | L’article acheté et les valeurs sélectionnées restent compréhensibles sans le catalogue actif. |
| Instantanés d’adresses | Responsable service Customer | Les adresses historiques ne sont pas écrasées par les données Customer actuelles. |
| Totaux Order | Responsable finance ou e-commerce | Chaque montant significatif possède un module ou un sens métier identifié. |
| Statuts et commentaires | Responsable opérations | La séquence historique des états et les notes sont interprétables. |
| Références de paiement et livraison | Responsable finance ou traitement des commandes | Transaction, transporteur, suivi et libellés de méthode sont consignés. |
| Retours, vouchers, crédits ou extensions après-vente | Responsable service Customer | Les données liées et les soldes restants sont reliés à l’Order. |
| Identifiants d’export ou rapprochement | Responsable intégration | Les systèmes comptables, ERP, marketplace ou entrepôt peuvent retrouver la transaction. |
N’utilisez pas la configuration actuelle du paiement ou de la livraison comme substitut aux libellés et références historiques.
Construire l’inventaire des contributions et personnalisations
Le registre des contributions est l’artefact central de la préparation osCMax. Regroupez les contributions par effet métier plutôt que seulement par nom d’installation.
| Domaine de contribution | Preuves à préparer | Condition de préparation |
|---|---|---|
| Catalogue et tarification | Tables/champs ajoutés, Products représentatifs, écrans d’administration | Les données Product et tarifaires actives ont des propriétaires. |
| Customer et accès | Groupes, approbations, champs fiscaux, fidélité, crédit, contenus restreints | Le fonctionnement des comptes peut être décomposé en relations distinctes. |
| Processus de commande et totaux Order | Résumé de configuration et Orders représentatifs | Les montants historiques sont distingués du futur fonctionnement. |
| Paiement et livraison | Références de transaction ou d’expédition, champs de statut | Les preuves historiques sont conservées sans l’ancien code ni les identifiants d’accès. |
| Reporting et exports | Indicateurs d’export, IDs de lots, clés de systèmes externes | Les références opérationnelles encore utiles sont connues. |
| SEO et contenu | Tables de routes, métadonnées, pages, redirections | Les chemins publics et propriétaires de contenu sont explicites. |
| Template et interface | Fichiers de template, blocs, entrées de langue, captures | Le contenu métier est séparé de la présentation. |
| Code personnalisé | Liste de fichiers modifiés, changements de schéma, responsable du processus | La règle métier est documentée indépendamment de son implémentation. |
Classez chaque élément comme actif-obligatoire, actif-remplaçable, historique uniquement, inactif avec données à conserver, obsolète ou inconnu. Tout élément inconnu mais critique pour l’activité reste un blocage à la préparation.
Préparer contenus, templates, fichiers de langue, médias et URLs
Le contenu du storefront osCMax peut résider dans des descriptions Product ou Category, des contributions de pages d’information, des fichiers statiques, des blocs de template, des fichiers de langue, bannières, boutons, images ou modules personnalisés. Inventoriez les contenus par propriétaire et par route.
Préparez :
- les pages actives de politique, information, contact et service ;
- les descriptions et images Product et Category ;
- les blocs de template contenant du contenu métier ;
- les textes de fichiers de langue qui doivent rester visibles pour les clients ;
- les menus et destinations de navigation ;
- les URLs importantes de Products, Categories, fabricants et contenus ;
- les redirections ou règles de réécriture créées par des contributions ou par la configuration serveur ;
- les images originales, fichiers téléchargeables et médias non générés.
Une capture d’écran prouve la présentation, mais pas la donnée qui en est propriétaire. Associez autant que possible les captures à des chemins de fichiers, clés de base de données ou sources de contenu.
Préparer les preuves liées à l’hébergement, au runtime, à la sécurité et aux sauvegardes
Les conditions d’un ancien hébergement peuvent déterminer si les données et fichiers source restent accessibles. Consignez les versions PHP et de base de données, le jeu de caractères ou la collation, la configuration du serveur web, les tâches planifiées, chemins de stockage, permissions et contraintes connues de sécurité ou maintenance. Ces informations servent à interpréter la source ; elles ne signifient pas que l’environnement cible doit reproduire l’ancien runtime.
Créez un ensemble de sauvegardes restaurable contenant la base de données et l’arborescence de fichiers correspondant au même état de la boutique. Incluez templates, fichiers de langue, images, téléchargements, code de contributions, références de configuration et scripts personnalisés. Consignez chiffrement, compression, taille, horodatage et responsable de l’accès.
| Domaine de sauvegarde | Preuve | Condition de préparation |
|---|---|---|
| Base de données | Dump complet et note de restaurabilité | Les tables du cœur et des contributions sont présentes. |
| Fichiers | Archive source ou arborescence accessible | Templates, contributions, images, téléchargements et code personnalisé sont disponibles. |
| Environnement | Notes runtime et serveur | Les problèmes d’interprétation liés aux versions peuvent être anticipés. |
| Sécurité | Responsable des identifiants, limites d’accès, traitement des données sensibles | L’accès peut être fourni de manière sûre via le processus prévu. |
| Journal des changements | Modifications tardives après la sauvegarde | Nouveaux Orders ou changements structurels restent visibles. |
Sélectionner des exemples représentatifs pour tester la migration
Préparez un manifeste d’échantillons avec IDs source, tables liées, fichiers, propriétaire de la contribution et sens attendu dans la source. Incluez des données ordinaires et les cas les plus susceptibles de révéler des écarts de schéma.
Incluez :
- un Product simple et un Product avec des attributs standard ;
- un Product avec stock ou SKU au niveau d’une combinaison lorsque ce modèle est utilisé ;
- un Product avec plusieurs images ou images détenues par une contribution, téléchargements, prix spéciaux ou champs personnalisés ;
- des Customers avec plusieurs adresses, classification grossiste ou revendeur, champs personnalisés, fidélité, crédit ou IDs externes ;
- des Orders invités et enregistrés avec attributs, plusieurs lignes de total, statuts inhabituels, références de paiement/livraison, remboursements, vouchers ou IDs d’export ;
- des exemples importants de contenu et de routes ;
- une donnée active détenue par une contribution, une donnée de table personnalisée et une relation avec un système externe ;
- une donnée proposée pour retrait, accompagnée de la raison de son exclusion du périmètre cible actif.
Appliquer le contrôle final de préparation osCMax
| Question de préparation | Résultat requis |
|---|---|
| La lignée de l’installation est-elle documentée ? | Les indicateurs de version, l’historique, les éléments du package et les contradictions sont consignés. |
| Les schémas du cœur et étendus sont-ils séparés ? | Tables du cœur, ajouts du package, contributions et champs personnalisés ont des propriétaires. |
| La complexité du catalogue est-elle représentée ? | Attributs, stock par combinaison, images, prix, téléchargements et identifiants sont documentés. |
| Customers et Orders sont-ils interprétables ? | Groupes, adresses, totaux, statuts, données après-vente et IDs externes sont complets. |
| Les contributions sont-elles classées ? | Les éléments actifs, historiques, obsolètes et inconnus disposent d’une décision explicite. |
| Les contenus et ressources du storefront sont-ils inventoriés ? | Pages, textes de langue, templates, médias, URLs et redirections restent traçables. |
| La sauvegarde est-elle restaurable ? | Base de données, fichiers et notes d’environnement correspondent au même état de la boutique. |
| L’échantillon est-il représentatif ? | Cas du cœur, contributions, tables personnalisées, historique et retrait sont inclus. |
La préparation reste ouverte tant qu’une contribution critique pour l’activité, une table personnalisée, une ligne de total Order ou un identifiant externe n’a pas de propriétaire.
Conclusion
La préparation d’une migration osCMax repose sur des éléments provenant de l’installation réelle. Les données e-commerce du cœur, ajouts du package, contributions, tables personnalisées, templates, fichiers de langue, totaux Order et clés de systèmes externes doivent être séparés avant que la configuration de migration puisse représenter correctement la boutique.
Un package source restaurable, un registre de propriété des contributions et un manifeste d’échantillons représentatifs constituent une base de préparation maîtrisée pour la configuration de la migration.
Questions fréquentes
Pourquoi un schéma osCommerce générique ne suffit-il pas pour préparer une migration osCMax ?
Les installations osCMax intègrent souvent des ajouts du package, contributions, champs personnalisés, fichiers du cœur modifiés et tables personnalisées. Le schéma et le code actifs déterminent quelles données existent et leur signification.
Que faut-il consigner pour chaque contribution osCMax ?
Consignez sa finalité métier, son statut, les types de données du cœur concernés, les tables ou champs, des IDs source représentatifs, les dépendances externes et si ses données sont actives, historiques, remplaçables, obsolètes ou inconnues.
Pourquoi les totaux Order d’osCMax nécessitent-ils un inventaire séparé ?
Les modules de totalisation peuvent créer des lignes de livraison, taxe, Coupon, voucher, supplément, remise, frais, crédit ou autres. Le libellé, le montant, la séquence et le module responsable expliquent le total historique.
Faut-il inclure les anciens modules et tables osCMax obsolètes ?
Ils doivent être documentés puis marqués pour archivage ou exclusion lorsqu’aucun processus actif ou historique n’en dépend. Il ne faut pas forcer des résidus techniques obsolètes dans un champ cible générique.
Que doit contenir la sauvegarde source osCMax ?
Préparez la base de données et les fichiers pertinents correspondant au même état de la boutique, notamment templates, contributions, fichiers de langue, images, téléchargements, références de configuration et scripts personnalisés, ainsi que les informations d’environnement.
Comment sélectionner les échantillons représentatifs pour osCMax ?
Utilisez des Products standards et influencés par des contributions, des Customers avec extensions de compte, des Orders avec plusieurs lignes de total, des exemples de contenus et routes, des données de tables personnalisées, des identifiants externes et au moins un cas volontairement destiné au retrait.