Si osCommerce est retenu comme plateforme cible, la préparation doit commencer par la filiation technique de la boutique source, car osCommerce v4 et les installations historiques exploitées pendant de nombreuses années peuvent utiliser des structures de catalogue, d’extensions, de contenus et de base de données sensiblement différentes. Une boutique décrite comme « osCommerce » peut être une v4 actuelle, une ancienne version 2.x, un fork ou une base de code fortement modifiée par des extensions communautaires et des changements directs de schéma.
L’objectif est d’identifier le véritable modèle source avant de choisir les mappings de champs. Chaque domaine doit préciser l’action à mener, son responsable, les éléments à fournir et la condition permettant de considérer le travail comme prêt. Les relations de la v4 actuelle, telles que les canaux de vente, groupes de clients, attributs, propriétés et enregistrements CMS, ne doivent pas être supposées présentes sous la même forme dans une source historique. À l’inverse, une table d’ancienne extension ne doit pas être assimilée à des données v4 natives simplement parce qu’une fonction moderne porte un nom similaire.
Établir la filiation de la source, les accès et les responsabilités techniques
Consignez le nom de la plateforme source, sa version, sa branche ou son fork, le préfixe de base de données, l’environnement d’hébergement, les front ends ou vitrines actifs, les langues, devises, extensions, fichiers modifiés, tables personnalisées et synchronisations externes. Lorsqu’une ancienne boutique a traversé plusieurs mises à niveau, conservez les notes des développeurs ou les éléments de schéma permettant d’identifier les tables qui pilotent encore réellement le fonctionnement actuel.
Préparez les accès à la source nécessaires pour le parcours de migration retenu. Le responsable technique doit confirmer que la connexion atteint la bonne base de données et la bonne arborescence de fichiers, et que les sauvegardes disponibles correspondent au même état de la boutique.
| Action | Responsable | Éléments à fournir | Condition de préparation |
|---|---|---|---|
| Identifier la génération de la source et la filiation du code | Responsable technique | Version, dépôt ou note de package, historique du fork | La source est classée comme v4 actuelle, ancien osCommerce, fork ou dérivé personnalisé. |
| Confirmer l’accès à la base et aux fichiers | Responsable hébergement ou base de données | Nom/préfixe de base, état de connexion, indication du document root | La connexion source requise atteint l’installation prévue. |
| Inventorier les extensions et modifications du noyau | Développeur ou agence | Liste des extensions, fichiers modifiés, tables personnalisées | Les enregistrements natifs, ceux des extensions et ceux du sur-mesure peuvent être séparés. |
| Documenter les front ends, langues, devises et contexte fiscal | Responsable e-commerce | Paramètres et matrice de périmètre | Les contextes qui modifient le sens des Products ou Orders sont documentés. |
| Identifier les systèmes externes et imports | Responsable des intégrations | Liste ERP/PIM/WMS/CRM, fréquence des flux, champs clés | Les valeurs maintenues hors d’osCommerce ont une source faisant autorité identifiée. |
Une fois ces éléments rassemblés, évitez les changements structurels non documentés. L’activité commerciale courante peut continuer, mais toute nouvelle extension, modification du schéma, évolution du modèle Product ou réécriture de route doit entrer dans le journal de changements du projet.
Préparer Products, Categories, marques, fournisseurs et périmètre des front ends
osCommerce v4 peut associer Products à des Categories, marques, fournisseurs, canaux de vente ou front ends, groupes de clients, descriptions multilingues, modes de stock, images, identifiants, prix, champs SEO et relations de merchandising. Les anciennes boutiques peuvent utiliser des tables principales plus simples et confier beaucoup de ces fonctions à des extensions.
Créez un inventaire Product indiquant l’ID source, le SKU ou modèle, les autres identifiants, le statut, le prix de base, la classe fiscale, le fonctionnement du stock, le poids, le statut virtuel/téléchargeable, les affectations aux Categories, la marque ou le fabricant, le fournisseur, les images, valeurs par langue, périmètre des canaux de vente, périmètre des groupes de clients et relations actives de promotion ou de prix par quantité.
| Motif dans la source | Action de préparation | Éléments à fournir | Condition de préparation |
|---|---|---|---|
| Product affecté à plusieurs Categories | Enregistrer toutes les relations Category et le contexte principal de merchandising | Export Product-vers-Category | Les placements partagés sont visibles sans dupliquer les Products. |
| Product disponible sur certains front ends | Documenter les affectations et restrictions par canal/front end | Matrice de périmètre par Product et Category | La disponibilité par canal est explicite. |
| Relation de marque ou fournisseur | Séparer l’identité publique de la marque de la propriété liée à l’approvisionnement | Liens marque, fournisseur et Product | Des libellés proches ne sont pas fusionnés dans un champ sans rapport. |
| Stock réel, illimité, masqué ou en précommande | Documenter quantité, mode de stock et traitement de la rupture | Paramètres de Products représentatifs | Le sens de la disponibilité n’est pas réduit à une seule quantité numérique. |
| Product virtuel ou téléchargeable | Documenter fichier, expiration, limites de téléchargement, logique de livraison et chemin source | Manifeste Product/fichiers | Les relations de livraison numérique et les fichiers d’origine sont disponibles. |
| Prix par groupe ou quantité | Documenter Product, groupe de clients, seuil, devise et montant | Inventaire des relations tarifaires | La tarification conditionnelle n’est pas remplacée par le seul prix de base. |
Pour les anciennes boutiques, indiquez quelles valeurs viennent des tables Products principales et lesquelles proviennent de colonnes d’extensions ou de tables séparées. Le responsable métier doit approuver tout nettoyage qui modifie l’identité Product ou le périmètre des canaux.
Séparer attributs, propriétés et relations de Products configurables
La v4 actuelle distingue les attributs des propriétés. Les attributs peuvent représenter des valeurs sélectionnables, des modèles réutilisables, des effets sur le prix ou le poids, des fichiers virtuels ainsi que des relations de stock. Les propriétés décrivent des caractéristiques structurées utilisées pour l’affichage, les filtres, la recherche, la comparaison, les plages de valeurs, les icônes ou les groupes de Products. Dans les anciennes versions, un seul mécanisme d’attribut peut mélanger plusieurs de ces rôles.
Préparez des éléments qui classent chaque valeur source selon sa fonction plutôt que son nom.
| Sens métier | Action de préparation | Éléments à fournir | Condition de préparation |
|---|---|---|---|
| Choix sélectionnable par l’acheteur | Documenter attribut, valeurs, modèle, affectation au Product et effets sur prix/poids | Export des attributs et affectations | Le choix d’achat et son effet commercial sont explicites. |
| Combinaison avec SKU ou stock indépendant | Identifier les enregistrements de combinaison configurables ou appartenant à une extension | Table de combinaisons et clés Product | L’identité vendable indépendante est préservée dans le modèle source. |
| Spécification technique | Documenter catégorie de propriété, propriété, type, unité, valeurs et liens Product | Inventaire des propriétés | Les données descriptives sont séparées des choix de l’acheteur. |
| Valeur de filtre ou de comparaison | Documenter le fonctionnement d’affichage, de filtrage et de recherche ainsi que la taxonomie | Carte des champs actifs de découverte | Les valeurs nécessaires à la découverte des Products sont identifiées. |
| Saisie texte ou personnalisation | Identifier le propriétaire du champ et des lignes Orders représentatives | Exemples Products et Orders | Les saisies propres à un achat ne sont pas traitées comme des métadonnées réutilisables. |
| Attribut téléchargeable | Documenter fichier, limites, Product et relation avec l’attribut | Manifeste fichiers/attributs | Le fichier et les éléments prouvant le droit au téléchargement sont complets. |
Ne transposez pas automatiquement chaque attribut historique vers un attribut v4. Certains correspondent à des propriétés, des relations de Products configurables, des champs personnalisés ou des structures appartenant à une extension.
Documenter les groupes de clients, comptes, adresses et contexte commercial
Les groupes de clients de la v4 actuelle peuvent contrôler la visibilité des Products et Categories, l’application de la fiscalité, les remises cumulées et les valeurs par défaut pour les visiteurs ou nouveaux utilisateurs. Des extensions peuvent ajouter des données de gros, B2B, crédit, fidélité ou approbation. Les anciennes boutiques peuvent représenter ces relations autrement.
Préparez des éléments Customers qui séparent l’identité, les enregistrements du carnet d’adresses, le statut invité, l’appartenance à un groupe, les statuts fiscaux ou professionnels, les avis, identifiants externes ainsi que les soldes ou autorisations appartenant à des extensions.
| Domaine d’enregistrement | Responsable | Éléments à fournir | Condition de préparation |
|---|---|---|---|
| Identité Customer | Service client ou responsable CRM | Liste des doublons et exceptions | Chaque compte conservé possède une décision d’identité claire. |
| Groupes de clients | Responsable e-commerce | Matrice groupe-vers-visibilité, fiscalité et remises | Le sens du groupe est documenté au-delà de son libellé. |
| Adresses | Responsable des données Customers | Adresses réutilisables et exemples au moment des Orders | Les données du compte et les instantanés historiques restent distincts. |
| Extensions de gros ou B2B | Responsable métier et développeur | Enregistrements société, rôles, approbations, prix ou crédit | Les relations commerciales appartenant à l’extension ont une destination décidée. |
| Avis et activité | Responsable contenu ou e-commerce | Relations Customers-vers-Products représentatives | Les données générées par les Customers conservent leur bon propriétaire. |
| Clés Customer externes | Responsable des intégrations | Correspondance des identifiants CRM/ERP | Les systèmes qui continuent à fonctionner peuvent retrouver le même compte. |
La portabilité des mots de passe doit être documentée comme une caractéristique de la source, et non déduite de la simple présence d’une adresse e-mail. Consignez le mécanisme d’authentification source et les dépendances liées à l’accès au compte sans transformer cette checklist en plan de communication client.
Préparer les Orders et leurs éléments commerciaux historiques
La préparation des Orders doit permettre de comprendre les transactions passées. Dans la v4 actuelle, un Order peut contenir le contexte du canal de vente, les instantanés Products et attributs, les adresses, totaux, statuts, commentaires, libellés de paiement et de livraison, suivi, remboursements, retours, factures et références externes. D’anciens modules peuvent ajouter des lignes de total ou des tables de transactions séparées.
Sélectionnez des Orders représentatifs de la complexité réelle de la boutique et identifiez quel enregistrement ou quelle extension possède chaque valeur historique.
| Élément historique d’Order | Action de préparation | Condition de préparation |
|---|---|---|
| Lignes Products et attributs | Documenter noms, SKU, valeurs choisies, quantités et prix tels qu’enregistrés au moment de la transaction | L’article acheté reste compréhensible indépendamment du catalogue actuel. |
| Adresses de facturation et livraison | Conserver les instantanés au niveau de l’Order séparément des adresses Customer | Les adresses historiques de transaction sont complètes. |
| Taxes, livraison, remises, frais et crédits | Inventorier toutes les lignes de total significatives et leur module propriétaire | Le total final peut être expliqué sans recréer un code abandonné. |
| Références de paiement et livraison | Documenter libellés, ID de transaction, suivi et module propriétaire | Les références historiques restent disponibles sans être confondues avec la configuration active. |
| Statuts et commentaires | Documenter le sens des statuts, leur séquence, leurs dates et leur visibilité | Le personnel peut interpréter le déroulement historique. |
| Remboursements, retours et ID externes | Documenter entités associées et clés de rapprochement | Les relations après-vente et avec les systèmes externes restent traçables. |
Ne recalculez pas d’anciens Orders à partir des paramètres actuels de Products, groupes de clients, fiscalité ou livraison. Le dossier de préparation doit préserver la transaction telle qu’elle a été enregistrée.
Inventorier Apps, anciennes extensions, tables personnalisées et intégrations
Les Apps v4 actuelles et anciennes extensions peuvent posséder des champs de catalogue, groupes de clients, totaux Orders, données SEO, références de paiement, offres de marketplace, rapports ou mappings vers des systèmes externes. Une simple liste d’extensions ne suffit pas ; la préparation doit identifier les enregistrements créés ou modifiés par chaque composant.
| Type de dépendance | Éléments à préparer | Condition de préparation |
|---|---|---|
| App v4 actuelle | Nom, version, entités concernées, champs/tables, ID représentatifs | Les données actives de l’App ont un propriétaire explicite. |
| Ancienne extension | Nom du package, fichiers principaux modifiés, changements SQL et enregistrements associés | Les données de l’extension peuvent être séparées du noyau osCommerce. |
| Table ou champ personnalisé | Schéma, sens métier, clés parentes et consommateur | Chaque valeur personnalisée encore active a une décision de destination. |
| Connecteur de marketplace ou canal de vente | Listing, offre, canal et ID externes | L’identité Product de référence reste distincte de sa représentation par canal. |
| Intégration ERP/PIM/WMS/CRM | Source faisant autorité, sens de synchronisation et clés stables | Les systèmes conservés peuvent se reconnecter aux entités cibles. |
| Composant abandonné | Éléments de dernière utilisation et confirmation du responsable | Les traces techniques obsolètes sont marquées pour archivage ou exclusion. |
Préparer les contenus CMS, médias, SEO et routes
osCommerce v4 peut gérer les contenus CMS, thèmes, front ends, descriptions Products et Categories, médias et paramètres SEO. Les anciennes boutiques peuvent utiliser des extensions de pages d’information, des fichiers statiques, des blocs de modèles, des fichiers de langue ou des modules SEO. Préparez les contenus selon leur propriétaire au lieu de considérer chaque page visible comme une seule entité CMS.
Construisez un inventaire des routes pour les Products, Categories, marques, CMS Pages, pages d’information, contenus propres à certains front ends et endpoints d’extensions prioritaires. Pour chaque route, indiquez le chemin source, l’objet propriétaire, la langue, le front end, les métadonnées, le réglage canonique lorsqu’il existe, l’importance métier et la destination prévue.
Sauvegardez les images originales, téléchargements, documents, fichiers de thème et fichiers de contenu. Documentez les relations avec les pièces jointes et les URL externes. Un dump de base de données peut conserver des noms de fichiers sans contenir les fichiers d’origine.
Construire le dossier de sauvegarde et de préparation des entrées
Créez un package restaurable associé à un état précis de la source.
| Composant | Responsable | Éléments à fournir | Condition de préparation |
|---|---|---|---|
| Sauvegarde de base de données | Administrateur de base de données | Dump horodaté, préfixe et indication de la génération source | Le schéma complet prévu est inclus. |
| Fichiers et médias | Hébergement ou responsable technique | Archive de fichiers ou arborescence source accessible | Les médias, téléchargements, extensions et code personnalisé d’origine sont disponibles. |
| Historique de filiation | Responsable technique | Historique version/fork et notes de mise à niveau | Les structures historiques et actuelles peuvent être correctement interprétées. |
| Registre d’accès | Responsable projet | Responsable de chaque accès et état de connexion | Les accès nécessaires sont disponibles sans publier les identifiants. |
| Journal de changements | Administrateur de la boutique | Changements structurels intervenus après la date de collecte des éléments | Les modifications tardives peuvent être intégrées volontairement. |
Sélectionner des échantillons représentatifs pour les tests de migration
Préparez un manifeste d’échantillons avec les ID source, le propriétaire, la raison métier, les fichiers associés et les relations source attendues. L’ensemble doit exposer aussi bien les structures propres à la v4 actuelle que celles liées à un héritage ancien lorsqu’elles existent. Le manifeste d’échantillons osCommerce est prêt lorsque chaque attente source, dépendance de filiation, fichier lié et identifiant est complet et attribué à un relecteur.
Incluez au minimum :
- un Product simple et un Product affecté à plusieurs Categories ou front ends ;
- des Products avec attributs, propriétés, combinaisons configurables, téléchargements, fournisseurs et tarification par groupe ;
- des Customers issus de groupes significatifs, des transactions invitées et des comptes de gros ou appartenant à une extension ;
- des Orders avec attributs, plusieurs totaux, remboursements, suivi, commentaires et références externes ;
- des routes prioritaires CMS, Product, Category, marque et appartenant à des extensions ;
- un enregistrement d’App actuelle ou d’ancienne extension qui porte une donnée métier ;
- un enregistrement dont le sens diffère entre la génération source et la v4 actuelle.
Appliquer le contrôle final de préparation osCommerce
| Question de préparation | Résultat requis |
|---|---|
| La filiation de la source est-elle confirmée ? | Version, branche ou fork, base de données, front ends, extensions et personnalisations sont enregistrés. |
| Le périmètre du catalogue est-il complet ? | Products, Categories, marques, fournisseurs, canaux, stock, prix et médias ont un propriétaire. |
| Les attributs et propriétés sont-ils classés ? | Les relations sélectionnables, descriptives, configurables et personnalisées sont séparées. |
| Customers et Orders sont-ils interprétables ? | Groupes, adresses, totaux, statuts et références externes sont documentés. |
| Les Apps et données personnalisées sont-elles classées ? | Les enregistrements actifs appartenant aux extensions ont une décision de destination explicite. |
| Les contenus et routes sont-ils inventoriés ? | CMS, contenus hérités, médias et URL importantes sont reliés aux objets qui les possèdent. |
| Les sauvegardes, accès et échantillons sont-ils prêts ? | Le package source peut être restauré et les ID représentatifs sont listés. |
La préparation reste ouverte tant qu’une table historique critique, une affectation de canal, une règle de groupe de clients, un module de total Order ou un identifiant externe n’a pas encore de propriétaire ni de décision de traitement.
Conclusion
Préparer une migration osCommerce consiste autant à reconstituer la filiation du système qu’à inventorier ses données. Les Products, front ends, groupes de clients, attributs, propriétés, contenus CMS et Apps de la v4 actuelle doivent être distingués des anciennes tables, extensions communautaires et modifications du code.
Un dossier source maîtrisé rend ces frontières explicites et fournit les enregistrements représentatifs nécessaires à la configuration et à la validation de la migration.
Questions fréquentes
Pourquoi faut-il confirmer d’abord la version ou le fork de la boutique osCommerce source ?
Parce que la v4 actuelle et les anciennes installations osCommerce peuvent stocker et interpréter différemment les données de catalogue, Customers, Orders, contenus et extensions. La filiation détermine quelles relations et tables possèdent réellement les enregistrements source.
Quelle différence de préparation existe entre les attributs et les propriétés ?
Les attributs représentent généralement des valeurs Products sélectionnables ou configurables et peuvent modifier le prix, le poids, le stock ou les téléchargements. Les propriétés décrivent des caractéristiques structurées utilisées pour l’affichage, les filtres, la recherche ou la comparaison.
Comment documenter les affectations aux canaux de vente ou front ends ?
Documentez quels Products, Categories, contenus, langues et URL appartiennent à chaque front end. Les enregistrements partagés et ceux propres à un canal doivent apparaître clairement dans une matrice de périmètre.
Les tables d’anciennes extensions doivent-elles être copiées dans des champs osCommerce v4 actuels ?
Pas automatiquement. Il faut d’abord identifier l’extension, le sens métier, l’enregistrement parent et le système ou composant qui utilisera encore la donnée. Une fonction moderne portant un nom proche peut utiliser un schéma ou un fonctionnement différent.
Quels Orders inclure dans un échantillon osCommerce ?
Incluez des Orders invités et enregistrés, plusieurs statuts, sélections d’attributs, remises, taxes, livraison, références de paiement, remboursements, commentaires, suivi ainsi que des totaux créés par des extensions ou des ID externes.
La sauvegarde de la base de données contient-elle les images, téléchargements et fichiers d’extensions osCommerce ?
Non. Préparez aussi l’arborescence de fichiers concernée afin que les médias, fichiers téléchargeables, thèmes, Apps, anciennes extensions et code personnalisé restent disponibles.