Vous voulez migrer votre PrestaShop, et depuis deux semaines vous lisez des comparatifs. Tous vous alignent le même tableau 8 contre 9, tous concluent par un « ça dépend » qui ne vous avance à rien. On va faire l’inverse.
La version à viser en 2026, c’est PrestaShop 9.1. On ne s’arrête en 8.2 que si un module bloquant l’impose, jamais par principe. Et si vous êtes encore en 1.7, sachez que cette branche n’est plus maintenue depuis la sortie de PrestaShop 9, en juin 2025, et que son dernier correctif date de janvier 2024.
Tout se joue sur deux questions : votre parc de modules est-il prêt, et combien de migrations êtes-vous prêt à payer. Nos prix pour une migration standard : 69 € HT (8 vers 9), 269 € HT (1.7 vers 8), 469 € HT (1.6 vers 8). Au-delà, et pour une reconstruction complète, c’est sur devis, à prix fixe validé avant de commencer.
Je vais être direct, parce que sur cette question la plupart des agences vous conseillent de jouer petit bras : « passez d’abord en 8, vous verrez pour la 9 plus tard ». Nous, non. Notre métier, c’est de vous emmener aussi loin que votre boutique le permet, et c’est presque toujours plus loin qu’on vous l’a dit.
Parce que le vrai sujet, ce n’est pas « 8 ou 9 ». Ce sont deux questions que personne ne pose clairement : est-ce que votre parc de modules est prêt, et combien de migrations vous êtes prêt à payer. Répondez à ces deux-là, et la version se choisit toute seule. Et puisqu’on va parler d’argent, autant le faire franchement, avec des chiffres que vous ne trouverez nulle part ailleurs : ce qu’une montée de version coûte vraiment, et surtout ce que vous ne payez pas.
Un mot pour poser l’enjeu. Si vous êtes encore en 1.7, sa dernière version, la 1.7.8.11, date du 2 janvier 2024. L’éditeur a officiellement cessé de maintenir la branche le 10 juin 2025, jour de la sortie de PrestaShop 9.0. Depuis, plus rien. Chaque mois, vous tournez sur un socle que plus personne ne répare. Ce n’est pas un détail, c’est le point de départ.
Dans cet article, je ne vais pas vous noyer. On répond aux deux vraies questions, chiffres à l’appui, on parle prix sans langue de bois, et à la fin vous saurez exactement vers quelle version aller dans VOTRE cas. Pas « ça dépend ». Une réponse.
- 018 ou 9, la comparaison que tout le monde vous montre
- 02Question 1 : votre parc de modules est-il prêt ?
- 03Question 2 : une migration, ou deux ?
- 04Ce qu’une migration coûte vraiment (et ce que vous ne payez pas)
- 05La réponse selon votre profil
- 06Le cas de la 1.6 : ce n’est pas une migration
- 07Comment décider sans se tromper
Vous préférez qu’on migre pour vous ? Prix fixe annoncé avant de commencer, selon votre version de départ : migration standard à 69 € HT de 8 vers 9, 269 € HT de 1.7 vers 8. Réponse sous 1 h, 7j/7.
Demander ma migration · voir l’offre · ou appelez le 09 72 03 59 17
8 ou 9, la comparaison que tout le monde vous montre (et pourquoi elle ne décide rien)
Commençons par ce que vous êtes venu chercher, parce que ce serait malhonnête de l’esquiver. Voici le comparatif entre les deux versions stables du moment, la 8.2 et la 9.1 (dernières versions au 26 septembre 2026 : 8.2.8 et 9.1.5, sorties toutes les deux le 18 août 2026).
| Critère | PrestaShop 8.2 | PrestaShop 9.1 |
|---|---|---|
| Socle technique | Symfony 4.4 | Symfony 6.4 LTS |
| PHP | 7.2.5 à 8.1 | 8.1 à 8.5 |
| Thème par défaut | Classic | Hummingbird 2.0 |
| Interface d’administration | historique | modernisée, nouvelle API d’administration (OAuth2) |
| Performance | référence | plus rapide selon l’éditeur, sans chiffre officiel |
| Écosystème de modules | complet, éprouvé | en croissance |
| Support sécurité | correctifs critiques et de sécurité jusqu’à la sortie de PrestaShop 10 | version stable courante, correctifs complets |
Voilà. Vous l’avez, ce tableau. Maintenant, regardez-le bien, parce qu’il a un défaut fatal : il compare des fonctionnalités, pas votre situation. Il vous dit ce que la 9 fait de mieux, il ne vous dit pas si VOUS pouvez y aller. Et c’est ça, la seule chose qui compte.
Et d’ailleurs, oubliez le conseil « visez la 9.0 »
Petite mise au point au passage, parce que je vois encore ce conseil partout. Au printemps 2026, juste après la sortie de la 9.1 (le 23 mars), tout le monde répétait : « allez en 9.0, mais évitez la 9.1, il n’y a pas assez de modules ». Ça ne tient plus. La branche 9.0 ne reçoit plus de correctifs depuis la 9.0.3 du 3 février 2026. La 9.1 est devenue la version stable par défaut, celle que PrestaShop installe et fait vivre. La 9.0, elle, est devenue une simple marche que l’on quitte. Quant à la 9.2, elle est en version candidate depuis le 21 septembre 2026 : tant qu’elle n’est pas sortie en version stable, on ne met pas une boutique en production dessus, et le passage de 9.1 à 9.2 sera une mise à jour mineure.
Autrement dit, viser la 9.0 aujourd’hui, c’est vous condamner à une mini-migration 9.0 vers 9.1 quelques mois plus tard. Pour rien. La vraie question de 2026, ce n’est pas 9.0 contre 9.1. C’est 8.2 contre 9.1. Et pour y répondre, deux questions suffisent. On y va.
Votre parc de modules est-il prêt ?
Si une migration vers la 9 déraille, c’est presque toujours à cause d’un module. C’est ce qu’on constate chantier après chantier, et les autres agences PrestaShop font le même constat. Votre thème, votre serveur, vos données, tout ça se gère. Le point qui casse, c’est le parc de modules. On commence donc par lui.
Pourquoi certains modules cassent et d’autres non
La 9 a modernisé le cœur de PrestaShop en profondeur, et cette modernisation a un prix : tout ce qui s’accrochait à l’ancienne mécanique doit être adapté. Quatre choses ont changé et cassent des modules : le passage à Symfony 6.4 (les contrôleurs d’administration ont été réécrits), l’exigence de PHP 8.1 minimum (le vieux code PHP 7 déclenche des erreurs), la mise en page du back-office désormais entièrement gérée par Symfony et Twig, sans Smarty, et la suppression de certains anciens points d’accroche.
Traduit en clair : tous vos modules ne courent pas le même risque. Voici comment je les classe.
| Type de module | Risque sur la 9 | Pourquoi |
|---|---|---|
| Module de paiement | Élevé | API et contrôleurs d’administration réécrits, contraintes de sécurité |
| Module qui surcharge l’administration | Élevé | Les contrôleurs d’admin passent à Symfony 6.4 |
| Module très lié au thème | Élevé | La 9.1 installe le thème Hummingbird par défaut : un module pensé pour Classic doit être revérifié |
| Module dépendant d’anciens hooks | Moyen | Certains points d’accroche ont été supprimés |
| Module « maison » ou surcharge (override) | Moyen | Les fichiers de surcharge cassent quand le cœur change |
| Module d’affichage simple | Faible | Peu touché par la refonte |
Un module d’affichage tout simple sur votre page d’accueil passera sans broncher. Votre module de paiement, celui qui touche à l’administration et à une API sécurisée, c’est le premier suspect. Vous voyez déjà où votre boutique se situe.
Comment savoir, concrètement, si un module donné passera ? Trois réflexes. Sur la marketplace officielle, la fiche du module indique les versions compatibles : cherchez la mention « PrestaShop 9 ». Si le module vient d’un éditeur, écrivez-lui et demandez sa feuille de route pour la 9, une réponse floue est déjà une réponse. Et pour un module sur mesure, seul un développeur tranche en regardant le code : surcharge-t-il un contrôleur d’administration, utilise-t-il du vieux PHP 7, s’accroche-t-il à un point d’accroche supprimé ? Ces trois vérifications suffisent à classer la grande majorité de votre parc.
Et si un module ne suit pas ? Ce n’est pas la fin du monde, c’est une décision. Soit il existe une alternative compatible, et on bascule dessus. Soit le module est stratégique et sans équivalent, et il faut le faire adapter, ce qui a un coût et un délai qu’il vaut mieux connaître avant la migration plutôt que découvrir en plein chantier. C’est tout l’intérêt de noter son parc en amont : on ne se lance jamais à l’aveugle.
Le score de compatibilité de votre parc, notre méthode
Tout le monde vous dit « auditez vos modules ». Personne ne vous dit comment. Voici la méthode qu’on applique chez nous, ramenée à un score sur 100 que vous pouvez estimer vous-même. Pour chaque module actif, quatre questions :
1. Est-il critique ? Bloquant (paiement, transport, sécurité, connecteur ERP : sans lui, vous ne vendez plus), important (marketing, SEO, relation client : ça dégrade sans casser), ou cosmétique (affichage, remplaçable en cinq minutes) ?
2. Quel est son risque technique ? Voir le tableau ci-dessus.
3. Existe-t-il une version compatible PrestaShop 9 ?
4. Sinon, existe-t-il une alternative crédible ?
Un module bloquant, à risque élevé, sans version 9 ni alternative, c’est un point noir majeur : il plombe le score. Un cosmétique remplaçable sans version 9, on s’en moque, on le change. Ce que votre score vous dit :
| Score du parc | Ce que ça veut dire | Ce qu’on vous recommande |
|---|---|---|
| 80 à 100 | Parc prêt | Visez la 9.1 directement |
| 50 à 79 | Partiellement prêt | Remplacez un ou deux bloquants, ou passez par la 8.2 en attendant |
| moins de 50 | Parc à risque | 8.2 d’abord, chantier de remplacement des bloquants avant la 9 |
Ce qu’on constate sur nos audits : une mise à jour d’une 1.7 vers la 8 passe à environ 90 % sans toucher aux modules, quasi indolore. Pour viser la 9, tout se joue sur le poids du parc : une boutique légère, on l’y emmène avec quelques contournements ou un peu de custom ; un parc lourd et très modulé, on le sécurise d’abord en 8.2, le temps de remplacer les bloquants. La leçon revient à chaque fois : on trouve presque systématiquement des modules qu’on croyait indispensables et dont on peut très bien se passer.
Une migration, ou deux ?
Voici l’angle que personne ne vous donne, et c’est peut-être le plus important de tout l’article. Quand vous choisissez votre version cible, vous ne choisissez pas seulement une version. Vous choisissez combien de chantiers vous allez payer.
Suivez le raisonnement. Vous êtes en 1.7. On vous conseille « prudemment » de passer en 8. D’accord. Mais dans deux ans, la 8 aura vieilli à son tour, et vous devrez migrer de 8 vers 9. Deux migrations. Deux périodes de test. Deux fois le risque. Deux factures. À l’inverse, si votre parc le permet, on fait le trajet en une seule fois : de 1.7 jusqu’à la 9, dans un seul chantier, la 8.2 n’étant qu’une marche technique au milieu du parcours : la 1.7 tourne au plus en PHP 7.4, la 9 demande au moins PHP 8.1, et la 8.2 est la version qui permet de changer de PHP en route. Un test. Une bascule. Un risque.
Et méfiez-vous d’une idée reçue tenace : il n’existe aucun outil qui convertit automatiquement, et sans casse, une boutique 8 en boutique 9. Chaque migration se prépare, se teste et se vérifie à la main. C’est justement ce qui rend le doublon coûteux. Deux migrations, ce n’est pas seulement deux fois le travail technique, c’est deux fois la période de test complète, sur chaque parcours, chaque paiement, chaque transporteur. Ce temps de vérification, invisible sur un devis, est le vrai coût caché de la prudence par étapes.
Ce que ça donne sur trois ans
| Scénario | Chantiers | Sur 3 ans | Risque |
|---|---|---|---|
| Rester en 1.7 | 0 planifié | 0 € de projet, mais une migration forcée plus tard, et plus chère | Élevé (failles, blocage PHP) |
| Prudent : 8 maintenant, 9 dans 2 ans | 2 | Deux projets séparés, deux périodes de test | Deux tests, deux bascules |
| Direct : 1.7 vers 8.2 vers 9 en un chantier | 1 | Un seul projet | Un test, une bascule |
L’enseignement saute aux yeux : si votre parc est prêt, le chantier unique jusqu’à la 9 vous épargne une deuxième période de test et une deuxième bascule. La prudence par défaut, celle qu’on vous conseille partout, vous fait tout vérifier deux fois. Ce n’est pas prudent, c’est du risque en double. Les prix, on les voit juste après.
Et pendant ce temps, l’attente vous coûte aussi
Il y a un coût qu’on oublie toujours : celui de ne rien faire. Rester sur une vieille version, ce n’est pas gratuit, c’est un coût différé, et il monte.
| Si vous attendez | Prix du projet | Compétences disponibles | Coût d’un incident |
|---|---|---|---|
| Aujourd’hui | référence | correctes | migration standard planifiée, dès 69 € HT |
| Dans 12 mois | en hausse | en baisse | failles non corrigées qui s’accumulent |
| Dans 24 mois | nettement plus élevé | rares et chères | migration en catastrophe après un incident, plus le nettoyage et les ventes perdues |
Le prix de votre migration augmente chaque mois où vous attendez : les modules abandonnés à remplacer se multiplient, les développeurs capables de travailler sur une vieille stack se raréfient et se paient plus cher. Et le pire scénario, c’est l’incident. Une boutique piratée sur une version non patchée, c’est une boutique fermée qui ne vend plus : à 300 000 € de chiffre d’affaires par an, chaque jour d’arrêt représente environ 820 € de ventes perdues. Et 60 % des acheteurs en ligne français disent qu’ils cesseraient d’acheter chez un marchand victime d’une cyberattaque (Akamai/YouGov, 2022). À comparer avec une migration planifiée qui, on va le voir tout de suite, démarre bien plus bas.
La checklist de migration PrestaShop, point par point
- 37 points, de l’inventaire des modules à la surveillance après la bascule
- Redirections 301, mots de passe clients, recette : ce qu’on oublie le plus souvent
- À imprimer ou à partager avec la personne qui gère vos commandes
Ce qu’une migration coûte vraiment chez nous (et ce que vous ne payez pas)
Parlons argent, sans détour. Quand vous cherchez « prix migration PrestaShop », vous tombez sur des fourchettes qui donnent le vertige : 3 000 à 20 000 €. Et là, vous refermez l’onglet, vous vous dites que ce n’est pas le moment, et vous repartez pour un an sur votre vieille version.
Le problème, c’est que ce chiffre est trompeur. Il existe, mais il ne s’applique qu’à un seul cas : la reconstruction complète, ou la boutique tellement personnalisée qu’il faut tout reprendre. Pour tout le reste, la réalité est très différente. Voici nos prix, en clair.
| Type d’intervention | Ce que c’est | Prix chez nous |
|---|---|---|
| Mise à jour mineure | 8.1 vers 8.2, stabilisation d’une 1.7, paliers 9.0 vers 9.1 vers 9.2 | Incluse dans la maintenance, 69 €/mois. Zéro à l’acte. |
| Montée de version, parc sain | migration standard | 69 € HT de 8 vers 9, 269 € HT de 1.7 vers 8 |
| Migration projet | 1.7 vers 8 ou 8 vers 9 avec adaptations, parc à trier | Sur devis, à prix fixe validé avant de commencer, après audit gratuit |
| Reconstruction | 1.6, ou boutique très personnalisée (thème à refaire) | Sur devis, à prix fixe validé avant de commencer |
Pour être transparent : une migration standard se paie une fois, et son prix est déduit si vous passez ensuite à la maintenance.
Ce qui fait grimper la facture au-delà de la migration standard, ce n’est jamais la version en elle-même, c’est ce qu’il y a autour : l’audit du parc, le remplacement des modules bloquants, l’adaptation d’un thème très personnalisé, la reprise de développements sur mesure. Une migration projet, c’est ce travail-là, pas le simple fait de cliquer sur « mettre à jour ». Pour situer le marché : un freelance expérimenté facture 400 à 700 € la journée, une agence souvent le double, frais de structure compris. Chez nous, pas de compteur à la journée : une migration standard coûte 69 € HT ou 269 € HT, moins qu’une seule journée de freelance.
Ce que personne ne vous dit sur les montées de version
Regardez la deuxième ligne du tableau, parce que c’est là que se cache l’argument que je n’ai jamais lu ailleurs. Une montée de version majeure sur un parc propre, une 8 vers 9 par exemple, ce n’est pas un grand projet. C’est une migration standard : 69 € HT, et 269 € HT pour une 1.7 vers 8. Le catastrophisme du marché, les « 3 000 à 20 000 € », ne concerne que les reconstructions. Pas votre cas, si votre parc est sain.
Et il y a mieux. Les mises à jour mineures, celles qui font vivre votre boutique au quotidien, une 8.1 vers 8.2, la stabilisation d’une 1.7, les paliers 9.0 vers 9.1 vers 9.2 quand ils sortiront, tout ça est inclus dans notre forfait de maintenance à 69 €/mois. Vous ne les payez jamais à l’acte.
C’est là qu’est la vraie économie, et la vraie réponse à « combien de migrations vais-je payer ». Une fois à jour et sous maintenance, vous payez la grosse marche une seule fois. Toutes les petites qui suivent sont comprises. Vous ne repayez plus jamais une montée mineure.
Faites le calcul sur trois ans. Une montée majeure payée une seule fois (269 € HT de 1.7 vers 8, 69 € HT de 8 vers 9 en migration standard), plus la maintenance à 69 €/mois qui absorbe tous les paliers suivants : aucun chantier à plusieurs milliers d’euros comme ceux que le marché agite. Et surtout, vous ne vous retrouvez plus jamais coincé cinq ans en arrière, à devoir tout reprendre en catastrophe. C’est ça, la différence entre subir ses versions et les piloter.
En pratique, dès que le parc est sain, une montée de version tient dans une migration standard. Les fourchettes à quatre ou cinq chiffres qu’agite le marché ne concernent que les reconstructions, jamais une montée de version sur une boutique en bon état. Sur ce point, on n’a rien à cacher : nos forfaits de maintenance incluent la mise à jour continue de votre boutique, version après version.
La réponse selon votre profil
Assez de théorie. Voici, noir sur blanc, ce que je vous recommande selon votre situation. Et vous allez le voir, on penche vers la 9 dès que c’est raisonnable. Ce n’est pas de la mode, c’est de l’économie : viser la version que vous garderez le plus longtemps, c’est ne pas repayer une migration dans deux ans.
| Votre situation | Version à viser | Étape | Ordre de prix |
|---|---|---|---|
| Boutique neuve 2026 | 9.1 | aucune | installation neuve |
| En 1.6 | 9.1 | reconstruction du thème | projet dédié, sur devis |
| En 1.7, parc sain | 9.1 | via la 8.2, un seul chantier | 269 € HT + 69 € HT en migration standard |
| En 1.7, très custom / gros catalogue | 8.2 | audit d’abord | sur devis |
| Déjà en 8, parc sain | 9.1 | aucune | 69 € HT (migration standard) |
Reprenons chaque cas, parce que les nuances comptent.
Vous créez une boutique neuve en 2026 ? PrestaShop 9.1, sans une seconde d’hésitation. Démarrer aujourd’hui sur la 8, ce serait choisir volontairement une version qui vieillira avant vous. Aucun sens.
Vous êtes en 1.6 ? On y revient en détail juste après, parce que votre cas est particulier. Mais la réponse courte est déjà là : visez la 9.1. Vous allez reconstruire de toute façon, autant reconstruire sur la version d’avenir.
Vous êtes en 1.7 avec des modules courants et un parc sain ? C’est le cas le plus fréquent, et c’est là qu’on se distingue des conseils prudents. On vous emmène jusqu’à la 9.1, en un seul chantier qui passe par la 8.2. Comptez 269 € HT pour la marche 1.7 vers 8 et 69 € HT pour la marche 8 vers 9, en migration standard si votre parc est vraiment propre, prix fixe annoncé avant de commencer. Vous ne vous arrêtez en 8.2 que si un module bloquant vous y force, pas par principe.
Vous êtes en 1.7 avec beaucoup de développements sur mesure, ou un très gros catalogue ? Là, on ralentit. Le risque module est à son maximum, et on ne joue pas avec une boutique qui fait votre chiffre. On sécurise en 8.2, on audite le parc, on remplace ce qui doit l’être, et on vise la 9 dans un second temps, une fois le terrain déminé.
Concrètement, pour ce profil, un module sur mesure à réécrire pour la 9, c’est en général deux à cinq jours de développement chacun. Multipliez par le nombre de modules concernés et vous comprenez pourquoi, ici, on sécurise en 8.2 d’abord : on ne transforme pas une migration en refonte non budgétée.
Vous êtes déjà en 8 ? Vous avez le luxe du temps, à une condition : être en 8.2, la seule version de la branche qui reçoit encore des correctifs de sécurité, jusqu’à la sortie de PrestaShop 10. En 8.0 ou 8.1, passez d’abord en 8.2, c’est une mise à jour mineure. Préparez votre parc tranquillement et visez la 9.1. Et surtout, pas la 9.0 : ce serait viser une marche que vous quitteriez aussitôt.
Vous remarquez le fil conducteur : dans quatre profils sur cinq, la réponse est la 9.1. Ce n’est pas un parti pris technophile, c’est le résultat du raisonnement de tout l’article. On ne vise la 8.2 comme destination que dans un seul cas, celui où un parc lourd et sur mesure l’impose. Partout ailleurs, s’arrêter en 8 reviendrait à payer aujourd’hui pour une version que vous quitteriez demain.
Le cas de la 1.6 : ce n’est pas une migration, c’est une reconstruction
Je garde ce cas pour la fin parce qu’il mérite qu’on s’y arrête, et parce que c’est là que la plupart des conseils que vous lirez ailleurs se trompent.
Il faut distinguer deux choses qu’on appelle à tort du même nom. Passer de 1.7 à 8, c’est une mise à jour, quasi indolore : techniquement, la 8 est surtout une 1.7 renommée. Passer de 1.6 à quoi que ce soit, c’est une reconstruction. Ce n’est ni le même métier, ni le même budget.
Pourquoi ? Parce qu’entre la 1.6 et la 1.7, PrestaShop a changé d’architecture de fond en comble en 2016. Le thème doit être entièrement refait, la documentation officielle des contributeurs le dit noir sur blanc, et les modules des pages produit adaptés un par un. Vous ne mettez pas à jour une 1.6, vous reconstruisez la boutique sur des fondations neuves.
Une précision technique qui compte : on ne migre pas une 1.6 directement vers la 9. Le chemin officiel passe par des étapes intermédiaires (l’assistant de mise à jour de PrestaShop ne part que d’une 1.7 : depuis une 1.6, il faut d’abord passer en 1.7 avec une ancienne version du module), et de toute façon, dans une reconstruction, on repart le plus souvent d’une installation neuve de la version cible, sur laquelle on réimporte votre catalogue, vos clients et vos commandes. Raison de plus pour choisir tout de suite la bonne cible : autant réimporter vos données une fois, dans la 9.1, plutôt que de refaire l’opération deux ans plus tard.
Et c’est précisément ce qui change la recommandation. Puisque vous payez une reconstruction dans tous les cas, la logique « 8 d’abord » s’effondre pour la 1.6. Pourquoi reconstruire sur la 8, une version qui vieillira, quand reconstruire sur la 9.1 ne coûte pas plus cher et vous met sur la version d’avenir ? Si vous êtes en 1.6, visez la 9. C’est l’avis tranché que peu d’agences osent formuler, et il tient debout.
Un mot sur la réalité de votre 1.6, pour finir de vous convaincre de bouger : elle plafonne à PHP 7.1, une version elle-même en fin de vie ; elle repose sur l’architecture Smarty, sans cache moderne et structurellement lente ; ses modules ne sont plus maintenus ; et les développeurs encore à l’aise sur cette stack se comptent, et se paient cher.
Concrètement, reconstruire depuis une 1.6, c’est 5 à 10 jours de travail effectif, étalés sur un à deux mois de projet : auditer les modules, choisir un thème, monter le staging, refaire la vitrine, puis réintégrer vos données une fois le visuel validé. Si votre 1.6 entre dans le cadre d’une migration standard vers la 8, c’est 469 € HT. Au-delà, le prix se fixe sur devis, avant de commencer, licences de modules et nouveau thème compris.
En pratique, ce que donnent nos migrations
Les chiffres du marché, c’est bien. Les nôtres, c’est mieux, parce que ce sont de vraies boutiques, migrées pour de vrais marchands.
En 2025, une quarantaine de migrations. La grande majorité, des 1.7 vers 8. Et une dizaine de reconstructions complètes depuis une 1.6, vers la 8 ou la 9 selon le parc. Le fil conducteur : chaque fois que le parc le permettait, on a poussé jusqu’à la version la plus récente, quitte à remplacer un module par une alternative.
Et voici comment on s’y prend, de la copie de test à la mise en ligne :
On héberge et on monte votre environnement de staging gratuitement. On y joue la migration à blanc, on liste tout ce qui a cassé, on patche et on met à jour les modules. On vous fait vérifier vos parcours critiques (paiement, transporteurs, tunnel), on synchronise les dernières données, et on met en ligne sur un créneau calme, jamais en pleine journée de vente. Rien ne bascule sans votre feu vert.
Comment décider sans se tromper
Pour finir, la marche à suivre, dans l’ordre.
D’abord, l’audit. Il représente 30 à 50 % du temps total d’une migration, et c’est lui qui fait la différence entre une bascule propre et une catastrophe. Comptez vos modules, notez votre parc, identifiez vos bloquants. C’est là que tout se décide.
Ensuite, le calendrier. On ne migre jamais en pleine saison. Jamais en novembre-décembre. La bonne fenêtre, c’est janvier-février, quand le trafic est calme et qu’un imprévu ne coûte pas votre mois le plus important.
Enfin, la préproduction. On teste la migration sur une copie de votre boutique, jamais en direct sur le site en ligne. Ça vous évite la seule vraie catastrophe : casser une boutique qui vend.
Trois étapes, dans cet ordre, ni plus ni moins. La plupart des migrations qui tournent mal ont sauté l’une des trois, presque toujours l’audit ou la préproduction. Prenez le temps de les faire, ou confiez-les à quelqu’un dont c’est le métier.
On calcule votre score, on vous dit la version
Notre audit de migration est gratuit et livré sous 24h. On note votre parc de modules, on vous dit vers quelle version aller, et à quel prix. Sans engagement.
Et une fois que vous serez à jour, ne repartez pas pour cinq ans de retard. Notre forfait de maintenance garde votre boutique à jour version après version, les montées mineures comprises. Vous ne repayez plus jamais une migration mineure.
Vous voulez qu’on s’occupe de votre migration ?
Donnez l’adresse de votre boutique et un numéro : on vous rappelle sous 1 h, 7j/7, avec un prix fixe selon votre version de départ (migration standard dès 69 € HT). Le détail est sur la page migration PrestaShop.
