Si J2Store est retenu comme plateforme cible, la préparation doit tenir compte du fait que les Products reposent sur des Articles Joomla et peuvent être étendus par plusieurs types de Product et applications. Un Product peut dépendre du contenu Joomla, des Categories, menus, Modules, groupes d’utilisateurs, options, variantes, téléchargements, Products groupés, applications de réservation ou d’abonnement, plugins de paiement et de livraison, surcharges de template et tables personnalisées.
Un dossier de préparation fiable rend chaque dépendance visible avant le début de la migration. Il doit préciser l’action, le responsable, les éléments de validation et la condition de préparation pour chaque domaine majeur, tout en séparant les enregistrements commerciaux historiques de la configuration active de la cible. Comme de nombreuses installations J2Store sont anciennes ou fortement étendues, le dossier doit également indiquer qui prend en charge les décisions de maintenance, de récupération et de compatibilité de la plateforme source.
Confirmer les accès à la source, la récupération et la responsabilité du cycle de vie
Commencez par vérifier les accès opérationnels à Joomla Administrator et J2Store, à l’hébergement et à la base de données, au système de fichiers et aux médias ainsi qu’aux tâches planifiées ou services externes. Relevez les versions de Joomla, J2Store, PHP, de la base de données, du template et des extensions.
| Action de préparation | Responsable | Éléments de validation | Condition de préparation |
|---|---|---|---|
| Confirmer les accès d’administration | Administrateur Joomla/J2Store | Comptes fonctionnels et synthèse des rôles | Les Products, Customers, Orders, applications et structures Joomla peuvent être inspectés. |
| Créer des sauvegardes restaurables | Responsable infrastructure | Export de base de données, archive du système de fichiers, notes sur les médias et procédure de restauration | La source peut être restaurée indépendamment de la boutique active. |
| Documenter l’environnement installé | Responsable technique | Inventaire des versions de Joomla, J2Store, PHP, base de données, template, plugins, Modules et applications | La pile source réelle est documentée, y compris les composants obsolètes ou personnalisés. |
| Attribuer la responsabilité du cycle de vie | Responsables métier et techniques | Responsables nommés pour l’hébergement, la sécurité, la compatibilité, le remplacement des extensions et la récupération | Le périmètre de migration ne sert pas de substitut à la maintenance de l’environnement source ou cible. |
| Préserver les identifiants | Coordinateur de migration | ID Article, Product, Category, option, variante, Customer, utilisateur, Order, application et identifiants externes | Les liens entre enregistrements peuvent être retracés après extraction. |
Si la boutique n’est plus activement maintenue, consignez-le explicitement. Évitez les nettoyages, mises à niveau ou suppressions d’extensions avant d’avoir obtenu une sauvegarde immuable et les éléments de schéma nécessaires : une table ou un plugin apparemment inutilisé peut encore détenir l’historique d’un Order ou d’un Product.
Préparer les Products fondés sur des Articles et leurs types
J2Store utilise des Articles Joomla comme Products. La préparation doit préserver à la fois l’identité de l’Article Joomla et l’enregistrement commercial J2Store. Selon l’installation, les types de Product peuvent inclure des modèles simple, variable, configurable, téléchargeable, flexivariable, advanced variable, booking, subscription, grouped, bundled ou définis par une application.
| Modèle de Product | Éléments de validation | Condition de préparation |
|---|---|---|
| Product simple | ID Article/Product, SKU, prix, stock, profil fiscal, poids, images, liens Category et exemple d’Order | Le contenu et l’identité commerciale désignent le même article vendable. |
| Product variable | Options, combinaisons générées, SKU, prix, stock, poids, image et statut par combinaison | Chaque combinaison vendable est traçable et complète. |
| Product flexivariable ou advanced variable | Enregistrements de combinaisons, état de publication, saisies hors variante et champs personnalisés | Les combinaisons de variantes et les valeurs saisies par le Customer sont distinguées. |
| Product téléchargeable | Enregistrements de fichiers, limites de téléchargement, expiration, route de l’espace Customer et exemple d’Order terminé | Les relations Product-fichier et Order-accès sont documentées. |
| Product groupé ou bundled | Parent, composants, quantités, logique de prix/remise, responsable du stock et exemple d’Order | La composition et la relation de stock sont explicites. |
| Product de réservation ou d’abonnement | Ressource/plan, planning, statut, dépendance de paiement, fonctionnement des groupes Joomla et historique | La propriété par l’application spécialisée est documentée. |
Classez chaque famille de Product selon ce qui change lorsque l’acheteur sélectionne une option : SKU, stock, prix, poids, livraison, taxe, accès au fichier, disponibilité de réservation, calendrier d’abonnement ou saisie du Customer. Cette distinction permet de déterminer si la valeur appartient à une vraie variante, à une option Product, à une saisie sur ligne d’Order ou à un enregistrement d’application.
Préparer les options, variantes, images et saisies du Customer
Les structures d’options J2Store peuvent produire des résultats différents selon le type de Product et les applications installées. Un Product variable peut générer une matrice de combinaisons dotées chacune d’un SKU, d’un prix et d’un stock indépendants. Un Product advanced variable peut combiner des dimensions de variante et de la saisie libre. Un Product groupé peut refuser les Products qui possèdent déjà des options.
| Domaine de préparation | Éléments de validation | Condition de préparation |
|---|---|---|
| Définitions d’options | Noms, types, valeurs, ordre, affectations aux Products et effets sur le prix | Les vocabulaires d’options équivalents et distincts sont compris. |
| Combinaisons de variantes | Product parent, combinaison de valeurs, SKU, prix, stock, image, statut et clé externe | Chaque enfant vendable possède une identité stable. |
| Texte ou fichiers saisis par le Customer | Définition de la saisie et exemples de valeurs sur ligne d’Order | Une saisie ponctuelle n’est pas confondue avec des métadonnées Product réutilisables. |
| Images Product et variante | Fichiers principal, miniature, supplémentaires et propres aux combinaisons | Les médias sont rattachés au bon Product ou à la bonne variante. |
| Combinaisons obsolètes ou inutilisées | Statut, utilisation dans l’historique des Orders et décision de retrait | Les références historiques sont préservées même si la combinaison active est exclue. |
Ne régénérez pas les matrices de variantes avant d’avoir enregistré les combinaisons d’origine et leurs ID. Une régénération peut modifier l’identité ou supprimer des données rattachées à des combinaisons existantes. Si un nettoyage est nécessaire, conservez un registre de correspondance entre la source et la version nettoyée.
Préparer les Categories, menus, Modules et URL Joomla
Puisque les Products J2Store sont des Articles Joomla, leur découverte dépend des Categories Joomla, de l’ordre des Articles, des éléments de menu, Modules, niveaux d’accès, langues, vues de template et routes d’application. Préparez ces relations pour les Products et pages de vitrine à forte valeur.
| Relation de découverte | Éléments de validation | Condition de préparation |
|---|---|---|
| Article Product vers Category | ID Article/Product et hiérarchie Category | Le placement du Product est intentionnel et traçable. |
| Ordre des Categories et Articles | Valeurs d’ordre source et règles d’affichage du menu | L’ordre de merchandising important est documenté lorsqu’il compte. |
| Élément de menu vers vue de boutique | Type de menu, alias, parent, langue, niveau d’accès et destination | Les routes Product, Category, panier, commande, profil, téléchargement et compte sont connues. |
| Affectation des Modules | Position, affectation au menu, langue et responsable | Les Modules de vitrine sont classés comme contenu, présentation ou sortie d’application. |
| URL et redirection | Chemin actuel, propriétaire de l’objet, intention cible et extension de routage | Les chemins prioritaires ont une destination prévue unique. |
| Relation multilingue | Affectations de langue et associations Joomla | Les familles traduites de Products et de navigation sont traçables. |
Un export Product ne recrée ni les menus ni les Modules Joomla. Préparez les éléments de contenu et de routage nécessaires pour distinguer la migration des données de la mise en œuvre du template et de la navigation sur la cible.
Préparer les Customers, utilisateurs Joomla, groupes et adresses
Les Customers J2Store peuvent être reliés aux utilisateurs Joomla, Orders invités, adresses, groupes Joomla, profils propres aux applications, champs fiscaux, données d’entreprise et identifiants externes. Préparez ces relations séparément.
| Modèle de compte | Éléments de validation | Condition de préparation |
|---|---|---|
| Customer enregistré | ID utilisateur Joomla, profil Customer, e-mail, groupes, adresses, statut et Orders | Les e-mails en double et comptes multi-groupes disposent d’un traitement documenté. |
| Customer invité | Identité et adresses au niveau de l’Order | L’historique invité reste compréhensible sans créer de comptes non justifiés. |
| Commerce fondé sur les groupes | Groupe Joomla, lien Product, statut d’Order déclencheur, effet sur le prix/l’accès et application propriétaire | L’affectation au groupe est représentée comme une relation métier et non comme un simple libellé. |
| Compte entreprise ou fiscal | Champs entreprise, identifiant fiscal, statut d’exonération et ID de compte externe | L’identité métier a un responsable nommé. |
| Dépendance d’authentification | Source du mot de passe, SSO/login social, MFA, procédure de réinitialisation et responsable communication | L’accès au compte est planifié sans supposer la portabilité des identifiants de la source. |
Lorsqu’une application ajoute un utilisateur à un groupe Joomla après achat, relevez le Product, le groupe sélectionné, le statut d’Order déclencheur, l’appartenance actuelle et un historique représentatif. Ce processus peut contrôler l’accès à du contenu ou à des services protégés après la vente.
Préparer les Orders et les preuves commerciales historiques
Préparez les en-têtes d’Order, lignes d’Order, références Product et variante, options sélectionnées, saisies Customer, adresses de facturation et de livraison, prix, remises, taxes, libellés de paiement et de livraison, statuts, commentaires, suivi, factures, téléchargements, abonnements, réservations, vouchers et enregistrements d’application lorsqu’ils existent.
| Enregistrement historique | Éléments de validation | Condition de préparation |
|---|---|---|
| Historique des statuts d’Order | Définitions de statut, horodatages, commentaires et signification opérationnelle | Chaque statut peut être interprété sans dépendre de l’ancienne interface. |
| Lignes Product | ID Article/Product/variante, SKU, valeurs sélectionnées, quantité, prix et taxe | L’article acheté reste identifiable même si le catalogue actif évolue. |
| Contexte de paiement | Libellé du moyen et référence de transaction | Les preuves historiques de paiement sont disponibles sans transférer les identifiants. |
| Contexte de livraison | Libellé de la méthode, frais, suivi et notes de traitement | Les preuves historiques de livraison sont distinctes de la configuration actuelle du transporteur. |
| Accès au téléchargement | Fichier Product, statut d’Order, limite, expiration et lien Customer | L’historique des droits numériques est traçable. |
| Historique détenu par une app | Enregistrements d’abonnement, réservation, bundle, affectation de groupe, voucher ou fidélité | Les enregistrements associés sont reliés au bon Order et au bon Customer. |
Construisez un glossaire des statuts d’Order, de paiement, de livraison, de téléchargement, d’abonnement et de réservation. Des termes proches comme New, Confirmed, Pending, Failed ou Completed peuvent avoir une signification opérationnelle différente selon l’extension.
Inventorier les applications, plugins, champs et tables personnalisés
Les applications J2Store peuvent posséder les données de Products groupés, bundles, frais supplémentaires, remises de volume, actions liées aux groupes Customer, réservations, abonnements, téléchargements, livraison, paiement, analyse et autres fonctions. Les plugins Joomla, surcharges de template et tables personnalisées peuvent étendre les mêmes entités.
Pour chaque dépendance importante, documentez :
- le nom et la version ;
- la finalité métier ;
- les tables et champs ;
- les clés Product, Customer, utilisateur et Order ;
- les tâches planifiées ou déclencheurs d’événements ;
- les services et identifiants externes ;
- le propriétaire cible ou la décision de retrait ;
- des enregistrements source représentatifs.
Ne décrivez pas l’exigence uniquement comme des « données d’app ». Nommez l’entité : abonnement, réservation, composant de bundle, frais, affectation de groupe, droit de téléchargement, champ personnalisé de commande, listing ou état d’intégration. Une définition claire de l’entité est nécessaire avant de choisir sa destination.
Séparer les enregistrements historiques de la configuration active de la cible
Les libellés et montants historiques peuvent être migrés comme preuves, mais les règles actives de taxe, paiement, livraison, e-mail, cron, template, sécurité et extensions doivent être mises en œuvre séparément.
| Preuve source | Responsabilité distincte sur la cible |
|---|---|
| Libellé du moyen de paiement et ID de transaction | Compte de passerelle, identifiants, callbacks, contrôles antifraude et tests actifs |
| Méthode de livraison, frais et suivi | Compte transporteur, zones, tarifs, retrait, emballage et configuration de traitement des commandes |
| Montant fiscal historique et libellé du profil | Immatriculations fiscales actuelles, taux, exonérations et règles de calcul |
| Relation Product et groupe Customer | Automatisation actuelle de l’accès, de la tarification ou de l’adhésion |
| Historique de téléchargement | Protection actuelle des fichiers, espace Customer, envoi d’e-mail et politique d’accès |
| Historique d’abonnement ou de réservation | Compatibilité de la passerelle actuelle, tâches planifiées, règles de capacité, notifications et logique de renouvellement |
| URL existantes de la boutique | Menus, alias, rendu de template, redirections et implémentation de recherche sur la cible |
Le dossier de préparation est prêt lorsque les preuves source et les responsabilités d’implémentation sur la cible sont toutes deux explicites. Il ne doit jamais laisser entendre que les enregistrements historiques configurent les opérations futures.
Sélectionner des échantillons représentatifs pour le test de migration
Choisissez des cas difficiles et riches en relations plutôt que seulement des Products simples et propres. Incluez :
- un Product simple rattaché à un Article Joomla et une Category ;
- un Product variable ou flexivariable avec des données de combinaison indépendantes ;
- un Product advanced variable avec saisie Customer lorsqu’il est utilisé ;
- un Product téléchargeable avec historique d’accès ;
- un Product groupé, bundled, de réservation ou d’abonnement lorsqu’il est utilisé ;
- une route Product multilingue ou soumise à restriction ;
- un Customer avec plusieurs adresses ou groupes ;
- un Order invité et un Order d’un Customer enregistré ;
- un Order contenant remise, taxe, paiement, livraison et éléments de suivi ;
- un enregistrement détenu par une application ou un identifiant externe.
Pour chaque échantillon, consignez les ID source, les enregistrements Joomla et J2Store reliés, la raison du choix, les éléments de validation requis et tout fonctionnement actif volontairement confié à l’implémentation de la cible.
Établir le contrôle final de préparation
| Question de préparation | Condition de préparation |
|---|---|
| La boutique peut-elle être restaurée ? | Des sauvegardes immuables de la base de données et du système de fichiers existent avec un responsable de restauration. |
| La responsabilité du cycle de vie est-elle claire ? | Hébergement, sécurité, compatibilité, remplacement des extensions et récupération ont des responsables nommés. |
| Les types de Product et variantes sont-ils classés ? | Chaque modèle de Product important dispose de preuves source et d’un échantillon représentatif. |
| Les relations Joomla sont-elles cartographiées ? | Articles Product, Categories, menus, Modules, langues, niveaux d’accès et URL sont traçables. |
| Les Customers et Orders sont-ils compréhensibles ? | Liens utilisateur, groupes, adresses, statuts, totaux et historique détenu par des apps sont documentés. |
| Les applications et données personnalisées ont-elles un propriétaire ? | Chaque jeu de données actif dispose d’un schéma, d’un responsable, d’une clé source et d’une décision de destination. |
| La configuration cible est-elle séparée ? | Les responsabilités liées à la commande, au paiement, à la livraison, à la taxe, à cron, au template et à la sécurité sont attribuées. |
| Les éléments non résolus sont-ils maîtrisés ? | Chaque dépendance non résolue possède un responsable, une échéance et un effet identifié sur le périmètre. |
Des sauvegardes manquantes, une responsabilité de cycle de vie floue, des variantes régénérées sans registre source, des tables d’apps inconnues ou un historique de Product spécialisé impossible à retracer doivent bloquer le périmètre concerné.
Conclusion
La préparation d’une migration vers J2Store doit préserver la connexion entre les Articles Joomla et les enregistrements commerciaux tout en tenant compte des types de Product, variantes, fichiers, Customers, Orders, applications, URL et personnalisations anciennes. Le dossier doit montrer qui prend en charge chaque action, quelles preuves établissent la relation source et quelle condition rend le périmètre prêt.
Cette approche maintient les enregistrements historiques séparés de la configuration active de la cible et empêche que le fonctionnement d’extensions historiques soit dissimulé à l’intérieur d’un export générique de Product ou d’Order.
Questions fréquentes
Que faut-il préparer en premier avant une migration J2Store ?
Confirmez les accès à Joomla, J2Store, l’hébergement, la base de données, le système de fichiers, les médias et les tâches planifiées. Créez des sauvegardes immuables et documentez les versions exactes de la source ainsi que les applications installées avant tout nettoyage ou mise à niveau.
Pourquoi les Products J2Store nécessitent-ils à la fois des preuves Joomla et commerciales ?
J2Store utilise les Articles Joomla comme Products. Le contenu, les Categories, la langue, l’accès, les menus et les routes peuvent relever de Joomla, tandis que le SKU, le prix, le stock, les options, les variantes et les relations d’Order relèvent de J2Store.
Comment préparer les Products variables J2Store ?
Enregistrez les définitions d’options et chaque combinaison générée avec le Product parent, les valeurs sélectionnées, le SKU, le prix, le stock, les images, le statut et les identifiants externes. Ne régénérez pas les combinaisons avant d’avoir préservé la correspondance d’identité d’origine.
Quelles preuves faut-il préparer pour les Products téléchargeables ?
Préparez les liens Product-fichier, emplacements de fichiers, limites de téléchargement, paramètres d’expiration, routes de l’espace Customer, statuts d’Order pertinents et exemples d’Orders terminés montrant l’historique d’accès.
Comment documenter les applications et tables personnalisées J2Store ?
Nommez l’application et l’entité, relevez les tables, clés, relations Product/Customer/Order, déclencheurs, tâches planifiées, dépendances externes et enregistrements représentatifs. Évitez de regrouper toutes les informations détenues par des extensions sous l’étiquette générique de données personnalisées.
Quels enregistrements choisir pour un test représentatif de migration J2Store ?
Choisissez des Products simples fondés sur des Articles, des Products à variantes, des types de Product avancés ou spécialisés, des routes restreintes ou multilingues, des Customers complexes, des Orders invités et enregistrés, des droits numériques, des données détenues par des applications et des identifiants externes.