Votre boutique tourne depuis dix ans. Elle vend, elle a ses habitués, son référencement construit patiemment. Mais la plateforme sur laquelle elle repose n'existe plus vraiment : plus de mises à jour, plus de support, plus de développeurs qui savent y toucher. Chaque année qui passe, le risque monte — et la migration devient plus lourde.
La peur principale de tous les e-commerçants dans cette situation est la même : "Et si je perds tout ce que j'ai construit ?". C'est une peur légitime et compréhensible. La réponse honnête : migrer vers PrestaShop, c'est transporter votre boutique — pas la jeter. Catalogue, clients, historique de commandes, référencement acquis : tout se déplace, rien ne repart de zéro si la migration est menée correctement.
Cet article traite quatre situations concrètes que je rencontre régulièrement : les boutiques osCommerce encore en production depuis 15 ans, les Magento 1 sans correctifs depuis 2020, les Oxatis et solutions SaaS fermées dont les propriétaires veulent reprendre le contrôle, et les PrestaShop 1.6 coincées sur PHP obsolète.
Si vous êtes déjà sur PrestaShop 1.7 (et non 1.6), le sujet est légèrement différent — c'est une montée de version dans l'écosystème, pas un changement de plateforme. Le guide dédié à la migration PrestaShop 1.7 vers 8 ou 9 couvre ce cas en détail.
Pour les prestations de migration PrestaShop et les autres services associés : la page dédiée vous en donne une vue complète.
osCommerce
Fondée en 2000
Magento 1
EOL officiel : juin 2020
Oxatis / SaaS
Plateforme propriétaire
PrestaShop 1.6
EOL : 2019
Comment savoir si votre plateforme est en fin de vie
Les quatre plateformes traitées dans cet article ont des histoires différentes, mais elles partagent les mêmes signaux d'alarme. Ce sont ces signaux — pas la simple ancienneté de la plateforme — qui indiquent qu'il est temps de bouger.
Plus aucune mise à jour de sécurité n'est publiée — les failles découvertes restent ouvertes indéfiniment.
Votre hébergeur exige une version de PHP que la plateforme ne supporte pas — ou a déjà retiré la version utilisée.
Les modules et extensions critiques (paiement, transporteurs) ne sont plus maintenus par leurs éditeurs.
Impossible de trouver un développeur qui accepte d'intervenir — ou uniquement à des tarifs prohibitifs.
Le site est lent, non responsive sur mobile, ou échoue aux tests de performance et d'accessibilité.
Les protocoles de paiement dysfonctionnent ou affichent des avertissements de sécurité dans les navigateurs.
Le risque sécurité est le plus immédiat
Une plateforme non maintenue ne reçoit plus de correctifs pour les failles découvertes. Ces failles sont documentées publiquement — et les scans automatisés les ciblent. Les injections SQL, les accès non autorisés aux données clients, le skimming de paiement : ce sont des risques réels, pas hypothétiques. Plus une boutique reste longtemps sur une plateforme abandonnée, plus le risque s'accumule.
Comprendre les vecteurs d'attaque e-commerceSi vous reconnaissez un ou plusieurs de ces signaux, la question n'est plus "faut-il migrer ?" mais "comment migrer sans rien perdre ?". C'est ce que cet article explique, plateforme par plateforme.
osCommerce : la plateforme historique qui ne suit plus
osCommerce a été une des premières plateformes e-commerce à grande diffusion — fondée en 2000, elle a équipé des milliers de boutiques françaises au début des années 2000 et 2010. De nombreuses d'entre elles tournent encore aujourd'hui, souvent depuis 15 ans et plus, avec des personnalisations accumulées au fil du temps.
Les problèmes concrets en 2026 sont multiples. L'architecture d'osCommerce est fondamentalement incompatible avec les versions récentes de PHP : le code repose sur des fonctions PHP 5 dépréciées depuis des années, et les hébergeurs qui retirent PHP 7.x mettent ces boutiques à l'arrêt brutal. L'écosystème d'add-ons est largement abandonné par ses auteurs — trouver un module de paiement maintenu, un module d'expédition compatible avec les APIs actuelles des transporteurs, relève souvent de l'impossible. Et aucune mise à jour RGPD native, aucune conformité PCI-DSS moderne, aucun support des protocoles de paiement récents.
Ce qui se transporte vers PrestaShop
Catalogue produits complet (références, descriptions, images, prix)
Arborescence des catégories
Comptes clients avec historique de commandes
URLs (avec plan de redirections 301 systématique)
Thème et design — à refaire sur PrestaShop
Add-ons spécifiques osCommerce — à remplacer par des modules PrestaShop
Code personnalisé ajouté directement au cœur
Le point de vigilance spécifique d'osCommerce : la structure de base de données est très différente de celle de PrestaShop. La correspondance doit être établie champ par champ — c'est le travail de cartographie le plus important de ce type de migration. osCommerce gère aussi différemment les déclinaisons produits (attributes), ce qui nécessite une recodification pour les boutiques avec beaucoup de variantes.
Les boutiques osCommerce ont souvent accumulé des personnalisations directement dans le code — sans méthode de surcharge propre, tout est mélangé. L'audit identifie ces personnalisations et détermine lesquelles doivent être reproduites sur PrestaShop. Après migration : back-office moderne, boutique responsive sur mobile, paiements et transporteurs à jour, et une plateforme maintenue et évolutive.
Magento 1 : fin de support depuis juin 2020
Support officiel terminé le 30 juin 2020
Aucun correctif de sécurité de la part d'Adobe (propriétaire de Magento) depuis plus de 4 ans. Les failles découvertes depuis cette date restent ouvertes sur toutes les boutiques Magento 1 encore en production.
Les propriétaires de boutiques Magento 1 font face à un dilemme classique : migrer vers Magento 2 (coûteux, complexe, exigeant en ressources serveur) ou basculer vers une solution plus légère et plus adaptée à leur taille. Ce dilemme a conduit beaucoup d'entre eux à rester sur Magento 1 plus longtemps que prévu — au prix d'un risque sécuritaire croissant.
Pour la grande majorité des PME et des e-commerçants de taille moyenne, PrestaShop est souvent le meilleur choix à l'issue d'une migration Magento 1. Pourquoi :
Coûts d'infrastructure nettement inférieurs à Magento 2 (moins gourmand en ressources serveur)
Maintenance moins coûteuse : un développeur PrestaShop est plus facile à trouver, et moins cher qu'un développeur Magento 2
Écosystème francophone actif : modules, thèmes, communauté, documentation
Prise en main du back-office plus intuitive pour les équipes non techniques
Mises à jour et correctifs de sécurité réguliers sur les versions actives
Points d'attention spécifiques à Magento 1
Les attributs produits Magento : correspondance à établir avec le système d'attributs/déclinaisons PrestaShop
Les règles de prix (catalog price rules, cart price rules) : à reproduire avec les règles de promotions PrestaShop
Les extensions Magento 1 : inventaire de ce qui est remplaçable par un module PrestaShop équivalent
Les customisations de layout (XML) : à refaire dans le thème PrestaShop
Une nuance honnête s'impose : pour les très gros projets e-commerce avec des besoins B2B complexes (catalogues de plusieurs dizaines de milliers de références, segmentation client avancée, intégrations ERP Magento-spécifiques), Magento 2 peut rester pertinent. Ce n'est pas une règle universelle — l'audit et la clarification du projet déterminent le bon choix. Ce que je refuse de faire, c'est recommander Magento 2 à une PME qui n'en a pas le besoin et qui paiera sa complexité inutilement.
Oxatis et les solutions SaaS fermées : reprendre le contrôle
Oxatis illustre bien la situation de toute plateforme SaaS propriétaire : vous louez la boutique, vous ne la possédez pas. Tant que tout va bien, ce modèle est simple et confortable. Les problèmes apparaissent quand les tarifs augmentent, quand les limites fonctionnelles bloquent votre développement, ou quand l'éditeur change de stratégie.
Les motifs de départ typiques depuis ce type de plateforme sont bien connus : augmentations tarifaires régulières sur des fonctionnalités qui devenaient basiques ailleurs, plafonds sur le nombre de produits ou de commandes, impossibilité d'ajouter des fonctionnalités sur mesure, dépendance totale à l'hébergement et aux APIs de l'éditeur, et surtout : la question des données — qui appartiennent à qui, et dans quel format.
Ce qui se récupère systématiquement
- →Catalogue produits (titres, descriptions, images, prix, stocks)
- →Arborescence des catégories
- →Comptes clients (email, nom, adresse)
- →Historique des commandes (dans les limites de l'export)
Ce qui est à refaire
- →Le design et le thème — propriétaire, non transférable
- →Les pages de contenu (CGV, FAQ, pages d'information)
- →Les fonctionnalités spécifiques à la plateforme d'origine
- →Les intégrations (marketplace, ERP) — souvent différentes
La difficulté spécifique des plateformes SaaS fermées : l'export des données. Ce qui est exportable, dans quel format, avec quelles limites — c'est l'une des premières questions de l'audit préalable. Certaines plateformes proposent des exports CSV corrects. D'autres exportent dans des formats propriétaires qui nécessitent une transformation. Et certaines données (historique de commandes complet, données de navigation, segmentation avancée) peuvent être difficilement ou pas du tout récupérables.
Pour les boutiques qui souhaitent une refonte complète en même temps que la migration, c'est aussi l'occasion de repartir sur une base saine : une boutique PrestaShop créée sur mesure avec import du catalogue existant.
Si vous hésitez entre PrestaShop et une autre solution SaaS pour la migration, le comparatif PrestaShop vs Shopify vs WooCommerce examine en détail les différences réelles de coût, de flexibilité et d'indépendance entre les approches open source et SaaS.
PrestaShop 1.6 : rester en famille, mais changer d'époque
PrestaShop 1.6 est dans une situation différente des trois plateformes précédentes : vous êtes déjà dans l'écosystème PrestaShop. Les concepts (modules, thèmes, surcharges, back-office), les données, la logique — tout ça est compatible dans les grandes lignes avec PrestaShop 8. C'est la bonne nouvelle.
La mauvaise : le support de PrestaShop 1.6 s'est arrêté en 2019. Les boutiques qui y tournent encore en 2026 le font sur PHP 5.6 ou PHP 7.x, tous deux en fin de vie depuis plusieurs années. L'hébergeur finit toujours par retirer ces versions — et c'est souvent une alerte d'hébergeur qui pousse à migrer en urgence, dans les moins bonnes conditions.
Spécificités de la migration PrestaShop 1.6 → 8
Migration directe 1.6 → 8
Techniquement possible via l'outil officiel de mise à niveau, mais rarement recommandée directement — le saut de version est important et la compatibilité des modules et thèmes n'est pas garantie.
Parcours par étapes 1.6 → 1.7 → 8
Parfois plus sûr selon l'état de la boutique. Chaque étape permet de valider la compatibilité et de corriger les problèmes progressivement.
Reconstruction propre avec import
Pour les boutiques avec un thème très vieillissant et un catalogue simple, souvent le meilleur choix : nouvelle installation PS8 propre, import des données, thème moderne. Plus propre et moins risqué.
Le vrai sujet de la migration PrestaShop 1.6 → 8, ce n'est pas les données — c'est le thème et les modules. Les thèmes PrestaShop 1.6 ne sont pas compatibles avec PrestaShop 8 : ils doivent être remplacés. Les modules 1.6 sont dans la même situation pour la grande majorité. Cela doit être anticipé et budgété dès l'audit.
Si vous êtes sur PrestaShop 1.7 et non 1.6, le guide qui vous concerne directement est le guide de migration PrestaShop 1.7 vers 8 ou 9 — le processus et les enjeux sont différents.
La méthode : migrer sans rien perdre
Quelle que soit la plateforme d'origine, une migration professionnelle suit une logique commune. Ce qui change entre osCommerce et Magento 1, c'est la complexité de la cartographie des données et les spécificités à traiter. La méthode, elle, est la même.
Le principe fondamental : la boutique actuelle ne s'arrête jamais pendant la préparation. Tout est fait en parallèle, sur une copie ou une nouvelle installation. L'ancienne boutique continue de vendre jusqu'à la bascule finale.
Audit et inventaire
Ce qui existe (nombre de produits, catégories, clients, commandes, contenus, URLs), ce qui doit être conservé absolument, et ce qui peut être abandonné ou refait proprement. C'est cette étape qui dimensionne tout le reste — et qui tranche entre migration fidèle ou création neuve avec import.
Cartographie des données
Établir la correspondance précise entre l'ancienne structure et celle de PrestaShop : quels champs vont où, comment gérer les cas sans équivalent direct (déclinaisons, tarifs spécifiques, champs personnalisés). C'est le cœur technique de la migration, celui qui détermine la qualité du résultat final.
Boutique cible préparée en parallèle
Nouvelle installation PrestaShop propre avec la dernière version stable, thème, modules, configuration. Tout est prêt à recevoir les données — pendant que l'ancienne boutique continue de vendre normalement, sans aucune interruption.
Import et vérifications
Migration des données par lots : catalogue, catégories, clients, historique de commandes. Contrôles qualité systématiques — comptages, vérification d'échantillons, cohérence des prix, des stocks, des associations produits-catégories. Rien n'est livré sans validation.
Plan de redirections SEO
Chaque ancienne URL pointée vers son équivalent PrestaShop via une redirection 301 permanente. C'est ce point précis qui protège votre référencement acquis. Une migration sans plan de redirections est une migration qui sacrifie des années de SEO — c'est non négociable.
Bascule planifiée et surveillance
Sauvegarde fraîche juste avant la bascule, mise en maintenance courte, déploiement. Puis 72 heures de surveillance renforcée : Search Console (erreurs 404, indexation), commandes réelles, performance, logs serveur. Toute anomalie est corrigée avant qu'elle coûte quoi que ce soit.
Ce que vos clients voient : rien, ou presque
Tout le travail de préparation se fait dans l'ombre. Vos clients commandent normalement pendant les semaines ou les mois que dure la préparation. Seule la bascule finale, planifiée en heures creuses sur la période la moins active, indisponibilise brièvement la boutique — souvent moins d'une heure. Bien menée, une migration est un non-événement pour vos clients.
Et le référencement ? La vraie question
C'est la peur n°1. Et la réponse est : non, vous ne perdez pas votre référencement si la migration est faite correctement. L'élément décisif est le plan de redirections 301 : chaque ancienne URL redirige vers son équivalent PrestaShop. Google transfère la valeur SEO des anciennes URLs vers les nouvelles. Une période d'ajustement de quelques semaines est normale — les positions fluctuent légèrement pendant que Googlebot recrawle — puis elles se stabilisent.
Ce qui se perd si on bâcle : les URLs sans redirection deviennent des erreurs 404. Google interprète ça comme des pages supprimées. Les positions acquises sur ces URLs disparaissent. C'est pour ça que le plan de redirections est non négociable dans toute migration sérieuse.
Ce qui protège le SEO
Plan de redirections 301 complet, URL par URL
Préservation des balises title, méta-descriptions, textes
Conservation de la structure de navigation et des catégories
Surveillance Search Console post-migration (72h minimum)
Ce qui améliore souvent le SEO après migration
Passage à PHP 8.x : gains de performance mesurables (TTFB, LCP)
Boutique responsive mobile-first dès le départ
Données structurées Schema.org correctement implémentées
Core Web Vitals améliorés — signal de classement Google
Pour les boutiques avec un catalogue important et des exigences de performance élevées, la migration est aussi l'occasion de repenser l'architecture serveur. Le guide sur l'hébergement PrestaShop pour gros catalogues couvre les configurations serveur qui font la différence sur les performances et donc sur le SEO.
Combien coûte une migration depuis une plateforme différente ?
Une migration depuis osCommerce, Magento 1 ou une solution SaaS coûte généralement plus cher qu'une montée de version PrestaShop 1.7 → 8, pour une raison simple : la cartographie des données entre deux architectures différentes est un travail sur mesure. Il n'existe pas d'outil automatique universel — chaque migration est un projet spécifique.
Les facteurs qui font varier le coût : le volume du catalogue, la complexité des données (déclinaisons, tarifs B2B, attributs avancés), le nombre de clients et de commandes à reprendre, l'état du thème actuel (refonte graphique ou non), les développements spécifiques à reproduire, et la présence ou non d'un ERP connecté.
Migration simple
1 500 – 4 000 €
Petit catalogue (< 500 produits), structure simple, thème standard
- Catalogue et clients récupérés
- Thème PrestaShop standard ou légèrement personnalisé
- Modules courants (paiement, transporteur)
- Plan de redirections SEO inclus
À ce niveau, une création neuve avec import du catalogue est souvent comparable en coût et donne un meilleur résultat — les deux devis sont utiles.
Migration classique
4 000 – 8 000 €
Catalogue moyen, personnalisations, historique client important
- Catalogue complet avec déclinaisons et attributs
- Thème personnalisé adapté à l'identité existante
- Modules métier vérifiés ou remplacés
- Redirections 301 sur l'ensemble des URLs
- Développements spécifiques légers reportés
Migration complexe
8 000 – 20 000 €+
Gros catalogue, ERP connecté, données B2B, personnalisations importantes
- Catalogue de plusieurs milliers de références
- Données B2B (tarifs clients, groupes, conditions spéciales)
- Connecteurs ERP ou logistique à réécrire
- Développements spécifiques importants à porter
- Architecture serveur adaptée au volume
L'arbitrage création vs migration
Pour les petites boutiques à design très daté avec un catalogue simple, une création neuve avec import du catalogue revient souvent à un coût comparable à une migration fidèle — et donne un meilleur résultat. L'audit préalable quantifie les deux options pour que la décision soit éclairée, pas subie.
Questions fréquentes
Peut-on migrer une boutique osCommerce vers PrestaShop ?
Oui. Catalogue, catégories, clients et historique de commandes se migrent via une correspondance établie entre les deux structures. osCommerce a une architecture très différente de PrestaShop — la cartographie champ par champ est le vrai travail technique. Le thème et les personnalisations spécifiques sont à refaire. L'audit préalable précise ce qui est automatisable et ce qui demande un travail manuel.
Vais-je perdre mon référencement en changeant de plateforme ?
Non si un plan de redirections 301 complet est mis en place. Chaque ancienne URL redirige vers son équivalent PrestaShop — Google transfère le "jus" SEO vers la nouvelle adresse. Une période d'ajustement de quelques semaines est normale, souvent suivie d'une amélioration grâce aux gains de performance, à la compatibilité mobile et aux données structurées modernes.
Magento 1 ou PrestaShop : que choisir pour migrer ?
Magento 1 n'est plus supporté depuis juin 2020. Pour une PME, PrestaShop offre des coûts d'infrastructure et de maintenance nettement inférieurs à Magento 2, avec un écosystème francophone actif. Pour de très gros projets B2B avec des besoins complexes spécifiques à Magento, Magento 2 peut rester pertinent — mais c'est une exception, pas la règle.
Comment récupérer mes données depuis une solution SaaS fermée ?
Via les exports proposés par la plateforme (produits, clients, commandes) complétés si besoin par d'autres méthodes. L'audit préalable vérifie précisément ce qui est exportable avant tout engagement — certaines données propriétaires ne sont pas extractibles, ce qui est identifié dès cette étape pour qu'il n'y ait pas de surprises.
Combien de temps dure une migration depuis osCommerce, Magento ou Oxatis ?
De quelques semaines à quelques mois selon le volume et la complexité. La boutique actuelle reste en ligne et continue de vendre pendant toute la préparation. Seule la bascule finale, planifiée en heures creuses, l'indisponibilise brièvement — souvent moins d'une heure.
Vaut-il mieux migrer fidèlement ou recréer la boutique ?
Cela dépend de l'état de l'existant. Si le design est très daté et les données simples (quelques centaines de produits sans personnalisations complexes), une création neuve avec import du catalogue donne souvent un meilleur résultat pour un coût comparable. Pour les catalogues complexes et les grands historiques de données, la migration fidèle est le bon choix. L'audit tranche objectivement.
Frédéric — rfdev.fr
Développeur PrestaShop freelance depuis 15 ans · Vosges (88), clients dans toute la France
Je réalise des migrations depuis des plateformes variées vers PrestaShop régulièrement. Si votre situation spécifique ne rentre pas dans les cas décrits ici, contactez-moi : un premier diagnostic de votre boutique actuelle est gratuit, et je vous dis exactement ce qui est récupérable et ce qu'il faudra refaire.