Migrer vers PrestaShop ou déplacer une boutique vers un nouveau serveur

Ce que nous ferions

Nous choisirions le parcours en fonction de votre boutique actuelle : configuration, qualité des données, modules ou applications sources, thème, intégrations, marchés et équipe responsable des opérations quotidiennes. Un changement de plateforme remplace des processus métier ; un changement de serveur sans changement de version doit les préserver. Convenez de la prestation achetée avant de choisir un outil ou d'accepter un devis.

Pour une migration de plateforme, nous construirions une boutique PrestaShop de préproduction propre et protégée, puis validerions les correspondances avec des données représentatives avant l'import complet. Pour un changement de serveur, nous répéterions une copie cohérente de l'installation existante sur l'hôte cible, en conservant si possible la version de l'application. Dans les deux cas, planifiez la bascule finale, identifiez le système autorisé à accepter les écritures et convenez d'une procédure de reprise qui préserve les commandes reçues après le lancement.

Si le choix d'hébergement nécessite un avis spécialisé, le PrestaShop Hosting & Infrastructure Audit évalue s'il faut migrer ou améliorer l'hébergement actuel ; l'exécution de la migration et les changements de configuration sont hors de son périmètre.

Définir ce que le changement doit apporter

Listez la contrainte réelle à résoudre : structure du catalogue, personnalisation de la commande, contenu multilingue, maîtrise de l'hébergement ou intégrations. Comparez le coût total de maintien au coût de migration sur deux à trois ans à partir de vos contrats et de votre charge de travail réels. Incluez hébergement, maintenance, sauvegardes, sécurité, assistance au développement, extensions, abonnements, frais de paiement, migration et formation du personnel.

PrestaShop auto-hébergé vous donne le contrôle de son code et de son infrastructure, ainsi que la responsabilité de leur exploitation. Il ne garantit pas une facture inférieure ni des coûts constants lorsque l'usage augmente. Les licences des modules peuvent inclure des frais récurrents de support ou de mise à jour. Vérifiez chaque contrat.

Les forfaits Shopify standard proposent déjà une personnalisation de marque et certaines adaptations de la commande et du compte. Son tableau des fonctionnalités de commande distingue ces capacités des extensions d'applications réservées à Plus sur les pages d'informations, de livraison et de paiement. Définissez précisément la capacité manquante avant de considérer la migration comme la solution.

Rester peut être judicieux lorsque votre catalogue actuel, votre point de vente, votre tunnel de commande et votre assistance répondent à vos besoins et que vous n'avez pas les ressources pour exploiter une autre plateforme. Évitez de remplacer par habitude chaque ancienne application par un nouveau module. Définissez d'abord le besoin métier.

Inventorier données, fonctions et contrôles d’acceptation

• Catalogue : catégories/collections, produits parents, variantes, SKU, références fournisseurs, GTIN, caractéristiques, descriptions, images, prix, règles de taxes, stock, poids et dimensions.
• Personnes : clients, invités, adresses, groupes, champs professionnels, justificatifs de consentement et exigences d’activation des comptes.
• Transactions : lignes de commande, adresses historiques, totaux des taxes et remises, devises, références de paiement, factures, avoirs, expéditions et remboursements.
• Contenu : pages CMS et blog, menus, traductions, métadonnées, URL canoniques, liens linguistiques et anciennes URL.
• Comportement : moyens de paiement, transporteurs, affichage des taxes, remises, abonnements, lots, fidélité, B2B, marketplace, intégrations ERP et comptables.

Décidez ce qui migre, ce qui est reconstruit et ce qui reste accessible dans une archive historique protégée. Conservez les identifiants source et une correspondance vers les identifiants cible pour chaque entité liée, même si vous préservez volontairement certains identifiants. Documentez les exclusions pour que l’équipe de support sache où retrouver les anciennes informations.

Fixez des contrôles d’acceptation mesurables : nombres d’entités, déclinaisons représentatives, totaux par devise, stock par emplacement/périmètre et opérations de service client fonctionnelles. Vérifiez les relations et workflows opérationnels ainsi que le nombre de produits.

Choisir la version cible et tester la migration en toute sécurité

Construisez une installation de préproduction protégée. Choisissez une version PrestaShop 9 maintenue prise en charge par votre thème, vos modules et intégrations. Utilisez les versions PHP et de base de données requises par cette version exacte. Le tableau officiel de compatibilité actuel distingue 9.0, qui recommande PHP 8.4, de 9.1, qui recommande PHP 8.5. Ne reprenez pas une recette générique d’installation de paquets PHP 8.1 pour un nouveau déploiement.

Installez les extensions requises et inspectez paramètres PHP, stockage, permissions et limites serveur. Ne choisissez pas de valeurs universelles arbitraires de mémoire ou de délai d’expiration. Vérifiez les environnements web et CLI réels.

Bloquez l’indexation de la préproduction et restreignez l’accès. Isolez emails sortants, paiements, tâches cron, exports marketplace et écritures ERP pour qu’un essai n’avertisse pas les clients et ne change pas les systèmes en production. Gardez des sauvegardes et testez la restauration avant l’exécution finale.

Estimez les délais à partir d'un essai représentatif et d'une liste des éléments à reconstruire. Incluez le nettoyage des données, la reconstruction des intégrations et les tests de recette. Consignez séparément les durées d'export, transformation, import et validation : le projet complet et la fenêtre finale de gel des écritures sont deux estimations différentes. Choisissez une fenêtre de lancement où vos interlocuteurs d'assistance, de paiement et d'intégration peuvent répondre.

Exporter les données Shopify et définir leurs correspondances

Exportez les produits, profils clients et données de commandes disponibles avec les outils ou API Shopify appropriés. Inventoriez séparément les métachamps, enregistrements propres aux applications, médias, collections et contenus. Un CSV produit n'est pas un export complet de boutique. Planifiez séparément les articles de blog Shopify et leurs fonctionnalités : les pages CMS natives de PrestaShop ne reproduisent pas un blog complet.

Faites correspondre les variantes Shopify aux déclinaisons PrestaShop et décidez comment les collections deviennent votre hiérarchie de catégories. Préservez les références produit et consignez les identifiants source et cible. Reconstruisez explicitement les comportements des applications. Un produit peut appartenir à plusieurs collections ; décidez donc séparément de ses appartenances aux catégories et de sa catégorie par défaut. Documentez toute règle de collection automatique devant continuer à maintenir ces appartenances après le lancement.

Les exports clients ordinaires ne fournissent pas d’identifiants de connexion fonctionnels et transférables. Importez profils et adresses, puis proposez un parcours d’activation ou de réinitialisation du mot de passe testé. Ne présentez pas cela comme si vous aviez exporté des hachages Shopify dont il suffirait de convertir le format.

PrestaShop prend en charge les entités multilingues du cœur, mais les champs d’un module ne sont multilingues que si son implémentation le prévoit. Testez traductions, choix de devise, taxes et chaque boutique plutôt que de supposer que le multilingue natif couvre chaque remplacement d’application.

Les commandes historiques nécessitent un importeur ou un processus d’archivage choisi. L’importeur CSV natif de PrestaShop ne possède pas d’entité Commandes. Confirmez si la solution de migration crée des commandes opérationnelles modifiables, des enregistrements de référence ou les deux.

Exporter les produits, clients et commandes HPOS WooCommerce

Pour les produits, utilisez Produits > Tous les produits > Exporter. Activez l’export des métadonnées personnalisées si nécessaire et inspectez les colonnes meta: obtenues. Cette capacité est documentée dans le guide CSV des produits WooCommerce.

Inventoriez les comportements propres aux plugins, comme les abonnements, lots, options produit supplémentaires et règles de prix. Les métadonnées exportées ne reconstruisent pas elles-mêmes le comportement. Préservez les métadonnées SEO du plugin SEO installé, y compris les champs comme _yoast_wpseo_title et _yoast_wpseo_metadesc lorsqu'ils existent.

L’exporteur de produits n’est pas un exporteur général de clients/commandes. Utilisez un exporteur explicitement choisi ou les API WooCommerce pour ces entités. Avec HPOS, les données de commande peuvent résider dans des tables dédiées ; ne vous fiez pas à une requête de base limitée aux posts.

Convertissez les variations en déclinaisons. Supprimez ou remplacez les shortcodes WordPress et le balisage des constructeurs dans les descriptions. Reconstruisez menus, blog et mises en page du thème. Un thème WordPress n’est pas un thème PrestaShop.

Les colonnes d'images d'un export produit WooCommerce contiennent des URL plutôt que les fichiers images. Gardez les images sources accessibles pendant l'import ou téléchargez les originaux et prévoyez un transfert contrôlé. Confirmez que la cible possède ses propres copies utilisables, y compris les associations aux déclinaisons, avant de retirer l'hébergement des médias sources.

Tester un produit variable avant l'import complet

Prenez une chemise vendue en plusieurs tailles et couleurs. La variation source Taille M et Couleur Bleu possède sa référence, son stock et son image propres. Importez d'abord la chemise parente, puis rattachez cette variation comme déclinaison au parent correspondant. Pour l'import natif des déclinaisons, calculez l'impact de prix HT comme le prix normal net de la variation moins le prix de base net du produit parent ; n'importez pas le prix complet de la variation comme impact. Vérifiez que la sélection M et Bleu affiche la bonne référence, l'image, la disponibilité et le prix final corrects, et que la déclinaison souhaitée est sélectionnée par défaut.

Le nombre de produits peut être correct alors que ce test échoue : importer chaque variation comme produit autonome fait perdre le sélecteur, tandis que la rattacher au mauvais parent produit un catalogue plausible mais incorrect. Conservez les identifiants source du parent et de la variation dans vos correspondances pour pouvoir relier chaque échec à la ligne concernée.

Distinguer prix normaux, promotions et taxes

Vérifiez si les prix sources incluent les taxes. Faites correspondre délibérément les champs HT et TTC. Par exemple, 120 EUR incluant une seule taxe de 20 % correspondent à 100 EUR HT ; importer 120 EUR comme prix HT donne 144 EUR TTC à ce taux. Les règles fiscales réelles peuvent être plus complexes, donc testez les paniers de destination. Consignez Tarifs saisis avec la TVA sous WooCommerce > Réglages > TVA avant de transformer l'export. Faites correspondre un prix promotionnel à la réduction de prix spécifique prévue, avec ses dates et conditions de client ou de devise, plutôt que de remplacer accidentellement le prix normal. Vérifiez l'offre affichée et le total du panier.

Établir explicitement les correspondances des concepts Magento ou Adobe Commerce

Identifiez l’édition source et les extensions. Les comptes d’entreprises B2B, devis et listes de demandes d’Adobe Commerce ne doivent pas être attribués en bloc au cœur Magento Open Source. Inventoriez les prix propres aux clients, la recherche et la planification des contenus et décidez comment chacun sera implémenté dans la cible.

Le mode B2B de PrestaShop expose des champs de compte professionnel. Les prix de groupe, prix propres aux clients et affichages HT nécessitent leur propre configuration. Activer ce mode ne les configure pas tous.

Reconstruisez les intégrations selon les ressources et opérations réellement disponibles. Le Webservice historique, l’Admin API de PrestaShop 9 et les points d’entrée de modules ont des couvertures et authentifications différentes. Ne supposez pas qu’une intégration REST ou GraphQL source se transfère sans modification.

Les modifications courantes de prix produits dans Magento sont des opérations d’administration. La complexité du déploiement de code ne justifie pas factuellement d’affirmer que chaque changement de prix nécessite Composer ou une chaîne de déploiement.

Par exemple, la Taille sélectionnable d'un vêtement relève du modèle de déclinaisons, tandis qu'une description fixe du Tissu peut devenir une caractéristique. Comparez un produit configurable importé à ses SKU enfants sources, puis passez une commande de test comme client professionnel. Un stock de variantes correct ne prouve pas que le prix négocié du client ou les autorisations de son compte professionnel ont été conservés.

Choisir comment transférer les données

Choisissez une méthode à partir de correspondances écrites et d'un exemple d'export. Une démonstration de connecteur avec des produits simples ne prouve pas la prise en charge de vos abonnements, champs professionnels personnalisés ou historique des commandes. Exigez des preuves issues de vos propres enregistrements représentatifs.

Si vous avez besoin d'aide pour une fonctionnalité manquante, le PrestaShop Module Selection & Fit Assessment évalue les approches répondant à ce besoin, tandis que le PrestaShop Custom Module Development Service définit et chiffre séparément les travaux sur mesure de module ou d'intégration.

Importer dans l’ordre des dépendances et vérifier les relations

1. Créez structure de boutique, langues, devises, règles de taxes, groupes clients et hiérarchie de catégories.
2. Importez les produits parents avec des clés stables et les catégories correspondantes. Validez les prix avant d’ajouter les images.
3. Importez les déclinaisons avec le Product ID parent, ou Product Reference en activant la correspondance par référence. Définissez la déclinaison par défaut voulue pendant cette passe.
4. Transférez les images et vérifiez leurs associations et les tailles générées.
5. Importez clients et adresses en préservant relations et informations de consentement.
6. Importez les commandes historiques uniquement par le mécanisme choisi et pris en charge. Désactivez les effets de bord involontaires sur emails, stock ou intégrations.
7. Reconstruisez les index concernés, comparez nombres et totaux, et inspectez les enregistrements en front-office et en back-office.

Les identifiants d’import natif varient selon l’entité. Ne supposez pas que n’importe quelle colonne peut servir de clé universelle de correspondance. Consultez le guide d’import de produits pour les CSV et la gestion des échecs partiels.

Testez explicitement les devises, les valeurs fiscales historiques et les remboursements. Recalculer d'anciennes commandes avec le catalogue ou la configuration fiscale actuels peut modifier l'enregistrement que vous souhaitiez préserver.

Conservez un journal d'import reliant les lignes en échec aux identifiants sources et au motif d'échec. Répétez une nouvelle tentative corrigée plutôt que de supposer qu'un lot interrompu par un délai d'attente n'a rien importé. Pour les images, distinguez une URL source inaccessible ou un redimensionnement échoué d'une ligne produit en échec avant de modifier max_execution_time ou de relancer toute la tâche.

Préserver l’accès aux comptes et un historique de commandes utilisable

Pour les migrations Shopify, WooCommerce et Magento, prévoyez un parcours de réinitialisation ou d’activation sauf si vous avez testé un pont de connexion compatible. Dans PrestaShop 1.7.8 et 9.1, le format CSV client natif exige un champ Password et en hache la valeur. Fournir un hachage source existant comme valeur ne préserve pas le mot de passe de connexion original. Utilisez un outil de migration avec une politique explicite d’identifiants ; pour les nouveaux comptes à mot de passe, utilisez un secret initial impossible à deviner et un parcours testé de réinitialisation ou d’activation, sans envoyer ce secret par email.

Un pont conçu séparément peut vérifier un ancien hachage pris en charge et rehacher le mot de passe après une connexion réussie. Il exige l’accès aux identifiants source, un modèle de sécurité défini et des tests. Ne le promettez pas pour une plateforme dont les exports ne fournissent pas ces éléments.

Testez le lien de réinitialisation, la langue, la livraison et la correspondance des comptes avant d’inviter les clients. Évitez d’envoyer des mots de passe temporaires par email. Expliquez clairement le changement et gardez un parcours de récupération de compte disponible.

Pour les commandes historiques, vérifiez les capacités réelles de l’importeur choisi : le personnel peut-il voir les lignes, émettre des documents, mettre à jour les expéditions ou traiter les retours ? Un remboursement via le prestataire nécessite les bonnes références de transaction originales, un accès au compte et une prise en charge par l’intégration. Conservez le processus de l’ancien prestataire ou un ancien back-office protégé si nécessaire.

Préserver les URL, métadonnées et possibilités de découverte

1. Combinez exploration du site source, sitemaps, exports d’URL de la plateforme, données analytiques, liens entrants et journaux serveur disponibles. Les exports de performances Search Console sont utiles, mais ne constituent pas un inventaire complet d’URL.
2. Faites correspondre les anciennes URL de produits, catégories, CMS, blog, langues et images à des destinations pertinentes. Gardez des redirections directes et permanentes, normalement HTTP 301 pour un déplacement permanent.
3. Préservez au départ les titres, descriptions et contenus utiles. Supprimez délibérément les contenus obsolètes et évitez d’envoyer chaque page supprimée vers l’accueil.
4. Vérifiez URL canoniques, liens linguistiques, liens internes, directives robots et contrôles d’accès de préproduction.
5. Générez le nouveau sitemap et soumettez-le après lancement. Utilisez le rapport d’indexation des pages de Search Console et l’inspection d’URL ; utilisez Paramètres > Statistiques sur l’exploration pour les diagnostics d’exploration/serveur.

Des chemins source typiques comme /products/blue-widget ou /product/blue-widget/ peuvent devenir une URL produit PrestaShop configurée. Générez d’abord la destination réelle ; ne supposez pas que chaque boutique utilise les mêmes identifiants, préfixes linguistiques ou le même suffixe .html.

Implémentez les correspondances en masse avec des règles serveur testées, un gestionnaire de redirections adapté ou un script de migration. Les redirections individuelles de produits de PrestaShop ne constituent pas un outil complet de migration en masse. Pour la gestion continue des adresses et redirections, Smart SEO Friendly URL Manager gère les modèles de pages et anciennes adresses ; validez les correspondances de migration requises en préproduction avant de vous appuyer sur le module. Le classement peut aussi évoluer en raison du contenu, de la disponibilité, de la vitesse, des URL canoniques et de la réindexation ; un plan de redirections ne garantit pas un trafic inchangé.

Pour un produit associé à sa cible, testez un ancien lien de campagne ou de résultat de recherche avec le nom d'hôte et la langue prévus. Consignez la réponse de redirection et suivez-la jusqu'à la page finale : une redirection vers un produit absent, une autre redirection ou la mauvaise langue reste un échec. Vérifiez l'URL canonique finale et la possibilité d'acheter le produit, puis répétez après la bascule publique. Le guide des URL et redirections couvre les contrôles d'URL associés.

Déplacer une installation PrestaShop existante vers un autre serveur

Un changement de serveur pour la même boutique transfère normalement les fichiers et une base cohérente plutôt que de reconstruire clients et produits par CSV. Séparez si possible une mise à niveau majeure du changement d’hébergeur pour tester chacun.

1. Inventoriez domaines, URL multiboutiques, origines CDN, tâches cron, workers, paramètres email, fichiers personnalisés, règles serveur web et callbacks externes.
2. Préparez l'environnement d'exécution et la base cibles. Préservez le jeu de caractères, la collation et le comportement de schéma requis. Donnez à l'application des identifiants de base de données appropriés.
3. Copiez l’installation, y compris images, téléversements, thèmes, modules et fichiers cachés/de configuration nécessaires. Gardez les archives hors de la racine publique des documents.
4. Exportez et restaurez une base cohérente. Pour des tables InnoDB transactionnelles, un dump en transaction unique peut aider ; tenez compte des tables non transactionnelles et évitez les changements de schéma pendant le dump.
5. Mettez à jour les identifiants de connexion de la cible dans app/config/parameters.php pour PrestaShop moderne. Préservez les secrets cryptographiques de l’application. L’ancienne version 1.6 utilise d’autres fichiers de configuration.
6. Appliquez une propriété et des permissions adaptées à l’hébergeur. Ne rendez pas aveuglément chaque fichier inscriptible par le processus web et ne copiez pas de commandes universelles de permissions.

# Illustrative file transfer; replace paths and remote account.
rsync -avz --progress -e ssh /srv/shop/ deploy@new-host:/srv/shop/

# Example database export for an appropriate InnoDB installation.
mysqldump -u ps_backup -p --single-transaction --routines --triggers shop > shop.sql

# Restore into the prepared target database.
mysql -u ps_restore -p shop < shop.sql

Ces exemples exigent des permissions de compte et un plan de sauvegarde propres à l’installation. Protégez le dump et supprimez les copies temporaires après un test de restauration réussi. Ne restaurez pas un dump sur la mauvaise base en production.

Si le domaine public et le chemin restent identiques, conservez ces URL de boutique. S’ils changent, mettez à jour les vrais enregistrements d’URL, notamment domaine, domaine SSL et URI physique/virtuelle, dans le bon contexte de boutique. Les URL multiboutiques modernes sont représentées par shop_url ; modifier deux noms de configuration génériques ne suffit pas à déplacer un multiboutique.

Tester un changement de serveur sans changement de domaine

Supposons que la boutique conserve son domaine public et sa version de PrestaShop, mais change d'hébergeur. Une page d'accueil fonctionnelle sur le nouveau serveur n'est qu'une première vérification. Passez une commande de test prise en charge par le prestataire via le parcours cible contrôlé et vérifiez la commande, les fichiers téléversés, les images générées, les e-mails sortants et les traitements de fond. Vérifiez les chemins de fichiers et la configuration propre à l'hôte ainsi que la base copiée.

Un prestataire de paiement peut encore appeler l'ancien hôte alors que votre navigateur utilise le nouveau. Rapprochez une référence de notification des journaux et de l'enregistrement de commande cibles. Si le callback atteint l'ancienne installation, corrigez le routage et les contrôles d'écriture avant d'activer les ventes sur la cible.

Préparer les certificats et maîtriser la bascule finale

Installez les certificats pour les véritables noms d’hôte de production avant lancement. Un certificat émis pour un nom temporaire ne couvre pas le domaine de production. Une validation DNS peut être utile avant que ce domaine pointe vers le nouvel hôte.

Testez la cible sous son vrai nom d’hôte avec une substitution locale dans le fichier hosts ou un parcours contrôlé équivalent. Cela teste votre navigateur, pas le parcours des prestataires de paiement ou autres appelants distants. Incluez les tests de callbacks et les accès prestataires dans le plan de bascule.

# Example entry on your test workstation only.
203.0.113.50 example.com www.example.com

1. Réduisez les TTL DNS concernés assez tôt pour laisser expirer le TTL précédent. Examinez les enregistrements A, AAAA, www, CDN et proxy/origine.
2. À la bascule, arrêtez les nouvelles commandes et autres écritures sur l’ancien système. Le mode maintenance seul peut ne pas arrêter callbacks, clients API, tâches cron ou écritures administratives.
3. Terminez le transfert final de base/fichiers, ou un delta final testé pour une migration de plateforme. Rapprochez clients, commandes, stock, prix et téléversements créés depuis l’essai.
4. Acheminez le trafic vers le nouveau système et confirmez que les callbacks distants atteignent la bonne installation. Évitez deux bases indépendantes accessibles en écriture.
5. Activez la nouvelle boutique après les contrôles d’acceptation. Gardez le trafic résiduel sur une voie contrôlée ou sur l’ancien système en lecture seule jusqu’à la fin de la transition.

Conservez une fiche de bascule avec la dernière commande source acceptée, la limite de l'export final, les résultats des rapprochements et la personne autorisant la réouverture. Un delta de plateforme doit tenir compte des changements de stock, commandes modifiées, annulations et remboursements ainsi que des nouveaux enregistrements. Consignez les paiements encore en attente à l'export final et définissez comment les notifications ultérieures actualisent la commande faisant autorité sans doubler les actions de paiement ou de préparation et d'expédition. Réexécuter un export complet sans correspondances testées peut écraser une correspondance corrigée ou dupliquer un import antérieur.

Une bascule en maintenance comporte un intervalle de maintenance. Le cache DNS empêche de garantir « cinq minutes » ou « zéro interruption ». La disponibilité continue exige une architecture de routage, réplication et coordination des écritures conçue à cet effet.

Utilisez les commandes de maintenance du back-office dans le bon périmètre de boutique. Dans la configuration du cœur, PS_SHOP_ENABLE = 1 active la boutique ; cela ne la met pas en maintenance.

Repérer une bascule inachevée ou incorrecte

Exécuter les contrôles de lancement et de restauration

• Testez inscription, connexion, réinitialisation du mot de passe, navigation, recherche, filtres, déclinaisons et stock.
• Vérifiez ajouts au panier, changements de quantité, remises, livraison, taxes et totaux par devise comme invité et client inscrit.
• Testez chaque mode de paiement avec les identifiants sandbox et valeurs de test pris en charge par le prestataire, y compris authentification, callbacks, annulations et remboursements. Suivez ses règles pour toute validation séparée en production.
• Confirmez les e-mails de commande et d'état, messages de contact, factures et processus d'assistance. Après tout changement d'hôte d'envoi, vérifiez le transport des e-mails cible, SPF et DKIM sur un message reçu.
• Vérifiez redirections importantes, images, liens linguistiques, URL canoniques, mises en page mobiles et analytique.
• Videz les caches appropriés de la cible et reconstruisez les index requis. Régénérez les règles de réécriture Apache si nécessaire ; la configuration Nginx nécessite son propre examen.
• Recréez les calendriers cron/workers avec le bon fuseau horaire, les bons chemins et identifiants. Activez les intégrations une seule fois et surveillez les erreurs et les rapprochements.

Gardez l'ancienne installation et les sauvegardes disponibles pendant une durée de conservation adaptée à vos besoins de reprise. Un retour en arrière après l'acceptation de commandes par la nouvelle boutique doit préserver ces nouvelles écritures. Faire simplement repointer le DNS vers une base périmée peut perdre des commandes ou doubler leur préparation et expédition.

Consignez qui peut arrêter les écritures, où rapprocher les nouvelles commandes et quelle sauvegarde ou quel delta restaure le système choisi. Surveillez références de paiement, erreurs applicatives/serveur, événements email et indexation après lancement.

Questions à poser à votre développeur ou agence

• Quelles entités sources et champs personnalisés sont inclus, reconstruits ou exclus, et où sont les correspondances source-cible ?
• Quels enregistrements représentatifs et parcours clients ont réussi avec le thème, les modules, marchés et environnement convenus, et où peut-on examiner les preuves ?
• Que détecte exactement le delta final, comment les lignes en échec sont-elles relancées et qu'est-ce qui arrête toutes les sources d'écriture pendant la bascule ?
• Qui est responsable de la décision de lancement et de la réponse à un paiement échoué, une commande absente, une redirection cassée ou une erreur d'intégration ?
• À partir de quand le retour en arrière nécessite-t-il de rapprocher les nouvelles commandes cibles, et qui a répété cette procédure de reprise ?
• Quelles licences récurrentes, quels accès aux archives, comptes prestataires et responsabilités d'assistance restent après la passation ?

Questions des responsables de boutique

Faut-il refaire le design de la boutique en même temps ?

Il vous faut un thème cible compatible lors d'un changement de plateforme, mais vous pouvez conserver une navigation, des textes et une identité visuelle familiers. Différez les essais graphiques sans rapport pour que les tests de migration aient une cible stable et que les clients reconnaissent la boutique.

Pouvons-nous garder le même prestataire de paiement ?

C'est possible, mais conserver le compte marchand ne transfère pas l'intégration. Confirmez auprès du prestataire la prise en charge du compte, du pays et de la devise par le module cible, puis testez ses identifiants, son parcours de notification et son processus de remboursement avant la bascule.

Les abonnements et moyens de paiement enregistrés continueront-ils à fonctionner ?

Traitez-les comme un chantier distinct. Un export de clients ou de commandes ne prouve pas qu'un jeton enregistré, un mandat ou un calendrier de renouvellement soit transférable. Obtenez la procédure prise en charge par le prestataire et décidez quel système gère les futurs renouvellements avant de désactiver les anciennes tâches d'abonnement.

Que deviennent les cartes cadeaux et soldes de fidélité ?

Inventoriez les soldes restants et règles d'utilisation séparément des codes de réduction. Convenez de la manière dont la cible les enregistre et les honore, testez une utilisation et rapprochez les soldes à la bascule pour que les clients ne puissent pas utiliser le même droit dans les deux systèmes.