Technique universelle de migration pour Prestashop

La grande question que vous vous posez peut-être, « c’est comment je vais faire pour migrer ma boutique » ? Bien sûr il y’a le module One Click Upgrade pour le faire, mais votre ancienne boutique doit continuer à tourner…

Migration Prestashop simple

Explication de la problématique

Vous êtes marchand, votre boutique est désuète, vous devez faire une mise à jour… Pour faire cela correctement, vous désirez travailler sur votre nouvelle boutique en développement, tout en continuant de garder votre ancienne boutique qui vous rapporte des commandes / clients. Mais du coup à un moment donné on va se trouver avec deux boutiques, la nouvelle version en mode développement qui est dépassée… et qu’il faudrait réactualiser.

Pré-requis : une règle claire à suivre

A partir du moment où vous travaillerez sur votre nouvelle boutique, sur l’ancienne en production, vous ne créerez pas de nouveaux produits, de nouvelles catégories… En finalité, l’idée est de ré-actualiser vers la boutique de développement uniquement les clients, les commandes, le stock… cette étape d’actualisation se fera tout à la fin, juste avant le passage en production.

1) Créez un clone de la boutique

La première étape est de créer un clone complet de la boutique en production, ce sera donc la boutique développement, copiez tous les fichiers présents sur le FTP et faites bien sûr une copie de la base de données, de manière à avoir une structure complètement indépendante.

2) Mettez à jour la boutique

Une fois que vous avez votre boutique développement qui fonctionne, vous pouvez faire la mise à jour de la boutique avec le module one click Upgrade. Cette étape se passe en principe assez bien et vous pouvez même migrer des vieilles versions du type 1.3 cela est pris charge.

3) Nettoyage, Thème, Modules, Produits

Une fois qu’on est à jour sous la nouvelle version de Prestashop avec la boutique développement on peut commencer par appliquer les étapes suivantes :

  • supprimer les vieux modules inutiles
  • installer un nouveau thème
  • installer les nouveaux modules
  • travailler la structure des catégories & menu
  • réviser le contenu fiches produits / images
  • ! ne pas créer de nouveaux produits

A partir de ce moment, on est donc à jour sur le plan fonctionnel… ça prend du temps, mais on a une boutique prête au niveau du contenu. Le seul problème c’est qu’on a pas la gestion des clients, commandes, stock qui sont actualisés.

4) Création d’un nouveau clone + transfert des tables

Il faudra à ce moment-là bloquer votre ancienne boutique production et la mettre en maintenance. A présent on va refaire un « nouveau » clone cette ancienne boutique de production en faisant à nouveau l’étape 1 et l’étape 2, vous aurez donc une nouvelle boutique fraichement migrée. A présent on va donc exporter les tables qui nous intéressent et les importer vers la boutique de développement.

Pour cela il suffit d’exporter toutes les tables qui commencent par :

ps_address_x
ps_birthdayvoucher
ps_cart_x
ps_customer_x
ps_loyalty_x
ps_message_x
ps_order_x
ps_rewards_x 
ps_stock_x
ps_supply_x 
ps_wharehouse_x

On fait justement cette migration pour avoir une structure de tables similaires, ce qui nous permet de faire une injection « brutale » sur la base de données de la boutique développement. Vous constatez qu’on transfert aussi le stock, c’est pour cela que je déconseille « temporairement » avant cette opération, de créer des produits sur la nouvelle boutique, dans le but qu’on puisse faire ce transfert de masse sans contraintes.

5) La boutique développement en mode production

Arrivé à ce stade on est prêt à passer en production, car les données sont actualisées. Il faut tout de même être prudent en faisant un test de commande pour voir si cela fonctionne, essayez aussi de vous connecter avec un compte client pour voir si cela correspond et si vous avez son historique.

Dans le cas présent j’ai pris des tables qui sont étroitement liées aussi au client, comme par exemple « ps_loyalty », « ps_rewards », qui sont des modules qui évoluent avec le compte du client. Il est donc important de prendre aussi ces tables liées aux clients, cela peut varier en fonction des modules que vous avez installés.

Bilan

Ces migrations / transferts de données, demandent une bonne préparation pour éviter les mauvaises surprises. Si vous devez faire cette opération pour un client, pensez à le sensibiliser au processus le plus simple et le plus sûr. Le pire c’est s’il faut migrer des différentiels de tables, des parties d’enregistrements… le risque d’incohérences est important. Avec cette méthode, celle-ci fonctionnera toujours peut importe la version et simplifie grandement le processus de migration différentiel d’une boutique.

Notez mon billet, Google va adorer :
1 étoiles - J'aime pas !2 étoiles - Bof !3 étoiles - Bien !4 étoiles - Très bien !5 étoiles - Génial ! (4 votes, moyenne : 4,50 sur 5)
Loading...

22 commentaires sur “Technique universelle de migration pour Prestashop”

  1. Hello,
    Un tuto toujours utile et peut être un dérivé (ou complément) à apporter, quand vous avez une boutique en fonctionnement depuis la 1ere version de prestashop et que l’envie vous prends de faire une clean install de la dernière version ! install vierge, réinstall de tous les modules utile, d’un nouveau thème… mais après comment importer proprement les clients, commande, cookie, produits etc…. ?

    1. Bonjour,

      Il n’y a pas une manière de procéder exacte pour cela, justement il faut idéalement éviter ce genre d’étape qui complexifie grandement la fusion (exporter les produits pour les ré-importer avec images etc… cela augmente forcément la complexité).

      Pour transférer les produits il faudrait tenter de passer par un outil via Store Commander en export… puis importer des CSV sur la boutique en production, mais cela demande de la manutention & préparations des images.

      On ne peut pas faire de transfert table à table dans votre cas, parce que les produits ne seront pas forcément associés aux bonnes catégories et le coté relationnel des tables dans votre environnement production sera trop différent.

      Merci pour votre visite !

  2. C’est exactement la même méthode que j’utilise et c’est à mon sens la plus sûre.
    L’intérêt est de pouvoir vérifier la préprod une fois migré afin de valider que tout est « OK ».

    Pour Alain,
    je penses que lorsqu’on part d’une version lointaine de prestashop il y a trois solutions à tester.
    1. on fait une maj directement vers la dernière et on vois l’ampleur des dégâts.
    2. on fait une maj en plusieurs étapes (pour remonter chaque version majeure)
    3. on repart d’une version vierge et on réimporte le catalogue.

    La solution trois est viables si l’outil d’export est de qualité.

    Dans les trois solutions une phase de validation de la préprod est primordiale.

    Dernière chose, pour ce genre d’exercice et surtout si on part de loin il faut idéalement avoir une deadline lointaine afin d’avoir le temps de corriger ce qui doit l’être, mettre en production un site dans lequel des données ont été perdue peut être très problématique car le retour en arrière est très difficile/impossible.

    @+,
    Olivier

    1. Tout dépend aussi du client pour qui on le fait… et qui va le faire…

      De mon côté j’aime limiter aussi la part des risques en faisant les étapes de manière « cohérentes ». Le client n’a pas forcément notion de la complexité technique ou des risques potentiels de conflits d’ID qui pourraient survenir par la suite en cas de décalage dans les relations.

      Une chose aussi, il faut pouvoir éviter de devoir faire 50x fois l’opération… car cela est lourd, prends du temps et il faut être méthodique… Pour que ça se passe bien, il faut que le client soit sensibilisé à la problématique et que le processus soit le plus clair possible.

      Comme le mentionne Olivier, revenir en arrière sur une base qui commence à crasher suite à une fusion de migration… est juste impossible et peut conduire une entreprise dans des situations dramatiques.

    1. Et tu fais le transfert de table à table via PHPmyAdmin ou via un autre outil (store commander) ? Et-ce que tu peux donner quelques précisions supplémentaires sur ta manière de procéder, certainement que ça intéressera aussi d’autres personnes.

      1. Avant tout, je n’utilise PhpMyAdmin que si je n’ai pas d’autres choix. Après, j’utilise Navicat et ça revient un peu au même (mais à travers un programme).

        Dans l’idée, j’exporte la DB tel quel. Via l’outil interne de sauvegarde BDD du PrestaShop.

        Je l’importe dans mon outil qui, selon la configuration que je lui donne, se charge de faire les opérations nécessaires à la migration des données et il m’exporte les tables impactées.

        De là, sur une nouvelle installation, je fais l’importe des tables impactées.

        Cette technique a d’ores et déjà été testé sur quelques boutiques, toutes versions confondues et avec un certains nombres d’éléments, et elle fait ses preuves.

        Dans l’idée, cela prends très peu de temps pour faire le tout. 😉

        1. Merci de nous avoir fait partager ta méthode, ce que je me rends compte (après discussion aussi avec d’autres experts) c’est que finalement il faut toujours faire une « jonglerie » et que ça reste très spécifique les migrations partielles / transferts de données.

  3. Bonjour,

    Merci pour cet article. C’est une méthode intéressante et très utile.

    Cependant, je préfère partir sur une base propre (nouvelle installation de Prestashop) pour plusieurs raisons :

    – On evite les problèmes de la vieille boutique dont le coeur a pû être bidouillé,
    – On évite le débug et les corrections sur des overrides moisis,
    – On assure au client la réception d’une boutique fonctionnelle comme au premier jour.

    Et donc, voici la méthode que j’utilise actuellement :

    A. Mettre le site à jour :
    ———————————–
    1. Copie intégrale du site sur serveur local,
    2. Mise à niveau du site local,
    3. Export des tables nécessaires (clients, adresses, commandes, produits, catégorie, etc…),
    4. Récupération des images, uploads, etc…

    B. Installation et configuration de l’espace de développement :
    —————————————————————————————-
    5. Nouvelle installation de Prestashop dans un espace de développement en ligne,
    6. Import des tables précédemment exportées,
    7. Mise en place des images et uploads sur la nouvelle boutique,
    8. Série de tests pour vérification du bon fonctionnement,
    9. Installation et configuration du thème et des nouveaux modules + travail sur le design si nécessaire,
    10. Sauvegarde du site en développement (dossiers/fichiers + DB),

    C. Mise en Production :
    ———————————–
    10. Mise en maintenance de la production,
    11. Sauvegarde du site en production (dossiers/fichiers + DB),
    11. Nouvelle copie locale du site,
    12. Mise à niveau de la nouvelle copie locale (afin d’avoir une DB compatible avec la version de développement du site),
    13. Export des tables nécessaires,
    14. Import des tables sur la boutique de développement,
    15. Nouvelle série de tests,
    16. Migration du site en développement vers la production.
    17. Dernières vérifications du bon fonctionnement de la boutique avant de quitter le mode maintenance.

    Je conviens que c’est une méthode assez lourde et redondante. Cela dit, le résultat est plus que satisfaisant.

    Les commentaires et les critiques sont les bienvenus.

    ++

    1. Bonjour,

      C’est très intéressant de voir la manière dont vous procédez pour effectuer la mise à jour de la boutique Prestashop.

      Est-ce que lors de l’étape « C » vous exportez à nouveau les produits et les catégories ? Le problème c’est que parfois il faut réviser la structure de la nouvelle boutique et qu’il n’est pas toujours possible de réactualiser toutes les informations lors de la réactualisation pour la pré-production.

      Votre manière de procéder est tout à fait jouable, personnellement j’essaie de limiter un maximum les opérations, pour avoir un protocole le plus simple possible et durable. J’ai déjà vu des prestataires avec des pages et des pages + des scripts à exécuter après chaque action… à mon sens bien trop « friable » pour pouvoir réguler les upgrades facilement.

      Finalement c’est ça qui est intéressant, profiter de l’expérience et de savoir comment font les autres.

      Merci pour votre partage !

      1. Bonjour,

        Non, pour l’étape C, je ne récupère que les tables clients, adresses, commandes, paniers, stock…

        C’est pourquoi il est important comme vous le dites dans votre article, que durant la procédure, le moins de changement possible soit effectué sur la boutique sous peine de voir ces changements perdu ou de créer quelques autres difficultés.

  4. Bonjour,

    Merci beaucoup pour toutes vos infos et vidéos.

    Je souhaitais savoir si les noms des tables étaient toujours d’actualité sur Presta 1.7? Si ils y en avaient d’autre?

    Merci beaucoup et passez de bonnes fêtes de fin d’année.

  5. Article très utile, merci beaucoup !

    Pouvez-vous me confirmer que les tables renseignées sont toujours d’actualité pour la version 1.6.1.18 ?

    ps_address_x
    ps_birthdayvoucher
    ps_cart_x
    ps_customer_x
    ps_loyalty_x
    ps_message_x
    ps_order_x
    ps_rewards_x
    ps_stock_x
    ps_supply_x
    ps_wharehouse_x

    J’ai remarqué par exemple qu’il manquait :
    ps_paypal_customer
    ps_paypal_login_user
    ps_paypal_order

    Salutations

  6. Bonjour,
    apres migration des tables 1.6 vers 1.7 j’ai les catégories et les produits dans le front mais coté backoffice je ne vois pas les produits, pouvez vous m’aider sur ce point svp.

    Merci 🙂

    1. Bonjour,

      Cette question est délicate, il faudrait peut-être voir avec la variable « PS_ROOT_CATEGORY » il est possible que cette valeur ne concorde pas avec la catégorie « ROOT » réelle de Prestashop.

      A bientôt !

  7. Bonjour et merci pour ces précieuses informations !

    De mon côté ce qui est assez étrange c’est que je n’ai pas de soucis à mettre en place la procédure, mais lorsque tout est près et que j’applique via la module « click upgrade » la mise à jours de 1.7.0.5 à 1.7.4.2, tout se passe bien, mais une fois terminée, j’ai tout mon design qui est cassé au niveau du BO, et le FO n’en parlons pas ! si déjà je pouvais accéder au BO se serait déjà ça !

    une idée ?

    1. Bonjour,

      Ce n’est pas vraiment possible de vous apporter une réponse sur ce point, il y’a énormément de critères qui entrent en compte (et il faudrait débuguer). Si vous prenez le module payant pour la migration de Prestashop, vous pouvez avoir l’aide du développeur ce qui peut faire gagner un temps considérable.

      A bientôt !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *