SAP Hybris End of Life : la checklist complète de migration pour 2026

Le 31 juillet 2026, la maintenance principale de SAP Commerce on-premise a pris fin (SAP Help Portal). La version 2205 a été la dernière version on-premise. Qui l’exploite encore aujourd’hui dépend d’une maintenance spécifique au client, sans correctifs de sécurité réguliers ni mises à jour réglementaires.

Nous avons publié cette checklist en avril, quand il restait quatre mois. L’échéance est passée, la checklist non : elle décrit toujours l’ordre dans lequel nous faisons passer les installations Hybris vers SAP Commerce Cloud. Je l’ai mise à jour pour la situation d’après juillet et j’y ai réuni ce que nous traitions auparavant dans trois articles distincts : ce qui passe de Hybris, le plan par phases et le travail après la mise en production.

En bref : SAP Commerce on-premise (anciennement SAP Hybris) est sorti de la maintenance principale le 31 juillet 2026 ; depuis, seule une maintenance spécifique au client est disponible. La cible de la plupart des clients est SAP Commerce Cloud : le même cœur que Hybris, mais exploité par SAP et mis à jour en continu. Cette checklist couvre 26 étapes en quatre phases, les délais typiques (de 3 à 18 mois selon le périmètre), des coûts indicatifs, la protection de votre SEO et les premières semaines après la mise en production. Si vous êtes encore on-premise, commencez par l’évaluation : elle vous dit combien de temps vous resterez exposé.

Qu’était SAP Hybris ?

SAP Hybris était la plateforme d’e-commerce rachetée par SAP en 2013. SAP l’a ensuite renommée SAP Commerce pour le produit on-premise et SAP Commerce Cloud pour la version exploitée par SAP ; depuis la version 2211, elle n’est plus livrée que sous forme de SAP Commerce Cloud. Quand on parle aujourd’hui de « Hybris », on désigne presque toujours une installation on-premise de SAP Commerce, et c’est précisément celle dont la maintenance standard a pris fin le 31 juillet 2026.

Ce qui a changé le 31 juillet 2026

« End of life » est l’expression que l’on recherche. Le terme exact est End of Mainstream Maintenance (EoMM), et il a des conséquences précises.

Ce qui a disparu :

• Les correctifs de sécurité réguliers. Votre plateforme de commerce, qui traite des données clients et de paiement, ne reçoit plus de mises à jour de sécurité courantes.
• Les mises à jour légales et fiscales. Les changements de TVA et autres adaptations réglementaires ne sont plus livrés dans le cadre de la maintenance standard.
• Les mises à jour des bibliothèques tierces. Lorsqu’une dépendance embarquée reçoit une CVE, le correctif n’arrive plus d’office dans votre version on-premise.
• La certification du runtime Java. Les nouvelles versions du JDK ne sont pas certifiées pour la 2205 ; le runtime vieillit avec la plateforme.
• Le développement du produit. Plus de nouvelles fonctionnalités, plus de travail sur les performances, plus de nouvelles API. Le produit on-premise est figé.

Ce qui continue, moyennant finance :

• La maintenance spécifique au client. SAP propose un support dans le cadre d’accords individuels. Les conditions et les prix dépendent de votre contrat : demandez-les par écrit à votre équipe de compte SAP.
• Les notes SAP existantes. La base de connaissances reste accessible, mais les correctifs pour de nouveaux problèmes peuvent ne pas exister.

Ce que cela signifie concrètement après juillet et quelles mesures transitoires ont du sens est expliqué dans Le support on-premise de SAP Commerce est terminé : et maintenant ?. Cet article porte sur la sortie.

Hybris, SAP Commerce, Commerce Cloud : ce qui est resté et ce qui a changé

D’abord une remarque sur les noms. SAP a acquis Hybris en 2013 et l’a ensuite renommé : SAP Commerce pour le produit on-premise, SAP Commerce Cloud pour la version exploitée par SAP. « Hybris end of life » désigne donc la version on-premise. Depuis la version 2211, SAP Commerce n’est plus livré que sous forme de SAP Commerce Cloud, et c’est la cible de la migration.

Le malentendu le plus fréquent que nous entendons : « Commerce Cloud est un produit entièrement nouveau. » Ce n’est pas le cas. Le moteur est le même ; c’est la façon de l’exploiter qui a changé.

Ce qui est resté :

• Le système de types (les types d’items se définissent toujours en XML)
• Le mécanisme d’extensions et Spring comme conteneur des services
• Le backend Java et les modules commerce : catalogue, panier, checkout, tarification, gestion des commandes

Ce qui a changé :

• L’exploitation. SAP provisionne, dimensionne, corrige et surveille l’infrastructure. Les équipes qui passaient la moitié de leur temps sur les serveurs peuvent travailler sur la boutique.
• Les mises à jour. Au lieu de grandes montées de version tous les quelques ans, SAP livre des mises à jour en continu. Les nouvelles fonctionnalités arrivent désactivées et vous les activez quand votre équipe est prête. Le revers : on ne peut plus repousser les mises à jour pendant des années. Ce que cela signifie concrètement, le framework update 2211-jdk21 avec Java 21 et Spring 6 le montre.
• Le déploiement. Les builds et les déploiements passent par le Cloud Portal au lieu de vos propres scripts.
• La vitrine. Le frontend recommandé est SAP Composable Storefront, en mode headless (anciennement Spartacus), qui dialogue avec le backend via les API REST OCC. SAP a déclaré obsolètes les modèles Accelerator basés sur JSP avec la version 2205 et, selon son plan publié, les retire de Commerce Cloud en septembre 2027 (SAP KBA 3263872).

Pour votre équipe, cela signifie : les compétences Java et système de types restent utiles. Il lui faut apprendre le modèle de déploiement cloud, le Cloud Portal et, si vous utilisez encore Accelerator, un frontend Angular. C’est de la formation, pas une reconversion.

Le cadre de décision pour la migration

Avant la checklist, une question appelle une réponse : rester sur SAP ou partir ?

Nous sommes partenaire SAP et avons donc un intérêt commercial à ce que vous restiez. Voici quand chaque voie a du sens.

Restez sur SAP Commerce Cloud si :

• Vous exploitez un ERP SAP (S/4HANA ou ECC) et dépendez d’une intégration ERP profonde : prix, disponibilités, commandes, conditions spécifiques par client. Si cet ERP est encore ECC, sa propre fin de maintenance de SAP ECC en 2027 entre dans le même plan.
• Votre modèle B2B utilise des fonctions propres à SAP : tarification complexe, contrats, catalogues par client, circuits d’approbation.
• Votre équipe maîtrise SAP Commerce. Passer à une plateforme entièrement différente coûte des mois.
• Vous devez avancer vite. Commerce Cloud conserve le modèle de données, la logique métier et de nombreuses personnalisations ; un changement complet de plateforme, non.

Envisagez un départ si :

• Vous n’avez pas d’ERP SAP, ou l’intégration se limite à un simple envoi de commandes.
• Votre vitrine est du pur B2C avec catalogue, panier et checkout standard.
• Votre équipe n’a pas de compétences SAP et ne souhaite pas en acquérir.
• Vous visez de toute façon une architecture entièrement composable. Cela prend nettement plus de temps qu’une migration vers Commerce Cloud ; notre analyse du composable commerce en B2B explique quand cela en vaut la peine.

Pour la plupart des clients on-premise, SAP Commerce Cloud est la réponse pragmatique : risque minimal, exécution la plus rapide, investissements existants préservés. Pragmatique ne veut pas dire automatique pour autant : prenez la décision en connaissance de cause. Une vue d’ensemble de la plateforme actuelle se trouve sur notre page SAP Commerce Cloud.

La checklist complète de migration

Vingt-six points en quatre phases. C’est la checklist que nous utilisons avec nos clients.

Phase 1 : évaluation (semaines 1 à 4)

C’est la phase la plus souvent bâclée. Tout le reste en dépend.

1. Inventorier chaque personnalisation. Exportez une liste complète des extensions maison, scripts ImpEx, personnalisations HAC et API de plateforme modifiées. Classez chaque élément : toujours nécessaire, remplaçable par une fonction standard de Commerce Cloud ou obsolète. Dans nos audits, une part considérable tombe généralement dans les deux dernières catégories ; les 5 erreurs de migration montrent pourquoi c’est important.

2. Repérer les modifications du cœur. Le code qui modifie des classes livrées par SAP au lieu d’utiliser des extensions, ou qui contourne le système de types pour accéder directement à la base de données, doit être restructuré avant la migration. Ce sont précisément ces points qui font dérailler les calendriers : trouvez-les en premier.

3. Cartographier toutes les intégrations. ERP, PIM, CRM, paiement, expédition, fiscalité, fidélisation, automatisation marketing. Pour chacune : protocole (API, IDoc, transfert de fichiers, connexion directe à la base de données), volume, fréquence, responsable. Les dépôts de fichiers et les connexions directes à la base de données ne fonctionnent pas dans Commerce Cloud, et c’est le point qui provoque le plus souvent le fameux « comment avons-nous pu passer à côté ? ».

4. Vérifier les extensions tierces. Clarifiez avec l’éditeur la compatibilité Commerce Cloud de chaque add-on et extension tierce, et testez-la dans une sandbox cloud. Certaines existent en version cloud, d’autres doivent être remplacées.

5. Recenser les vitrines. Nombre de sites, de langues, de catalogues. Les configurations multi-pays avec leurs propres règles de prix, de fiscalité et de logistique sont un autre projet qu’une vitrine unique.

6. Profiler les données. Comptez les produits (avec variantes), catégories, clients, commandes historiques, pages de contenu et médias. Vérifiez en même temps la qualité : doublons, références orphelines, formats incohérents, données que personne n’a touchées depuis des années. Nettoyez dans le système source ; des données sales n’ont rien à faire dans un nouvel environnement.

7. Relever les valeurs de référence. Temps de réponse, débit, taux de conversion, taux d’erreur. Sans ces chiffres, personne ne peut prouver après la mise en production si la nouvelle plateforme fait mieux ou moins bien.

8. Évaluer votre empreinte SEO. Extrayez l’inventaire complet des URL depuis Google Search Console. Combien de pages sont indexées, et combien de trafic organique apportent-elles ? Les sites à forte valeur SEO ont besoin d’une stratégie de redirection détaillée.

9. Documenter le chiffrement et les accès. Si vous utilisez le Transparent Attribute Encryption avec vos propres clés, documentez tous les attributs chiffrés et planifiez leur reprise dans la gestion des clés de Commerce Cloud.

10. Clarifier licences et contrat. Que prévoit votre contrat actuel pour la période après l’EoMM, et à quoi ressemble un abonnement Commerce Cloud pour vos volumes ? Les négociations prennent des semaines : lancez-les en parallèle.

Phase 2 : architecture et planification (semaines 5 à 10)

11. Choisir l’approche pour la vitrine. Trois options :

• SAP Composable Storefront : le frontend recommandé par SAP. Headless, découplé du backend, déployable de façon indépendante. Le bon choix pour un investissement stratégique ; notre guide pour migrer d’Accelerator vers Composable Storefront en décrit les étapes.
• Reprendre la vitrine Accelerator : la voie la plus rapide pour quitter l’on-premise, car le code de la vitrine reste. Mais les modèles sont obsolètes depuis la 2205 et leur retrait est prévu en septembre 2027 : c’est donc une solution transitoire avec une date d’expiration fixe.
• Votre propre frontend headless : React, Next.js ou Vue sur les API de Commerce Cloud. Liberté maximale, mais le frontend est entièrement à votre charge. Nous comparons les options dans Composable Storefront vs React/Next.js.

12. Concevoir l’architecture cible. Environnements Commerce Cloud, architecture d’intégration (SAP Integration Suite ou API directes), stratégie CDN et mise en cache, supervision et alertes.

13. Planifier la refonte des intégrations. Dans Commerce Cloud, tout passe par des API ou par SAP Integration Suite. Chaque intégration a besoin de son propre plan de migration ; comptez de trois à cinq jours par intégration pour l’analyse et la refonte.

14. Définir la stratégie de migration des données. Big bang (chargement complet dans une seule fenêtre de bascule) ou itérative (chargements progressifs avec synchronisation delta). Au-delà d’un million de produits, nous recommandons des chargements itératifs avec au moins trois essais. Les méthodes disponibles sont décrites dans notre article sur le chargement des données dans SAP Commerce Cloud.

15. Planifier environnements, CI/CD et reprise. Au minimum développement, préproduction et production ; les grands projets ajoutent un environnement de test d’intégration. Mettez en place des pipelines automatisés de build, de test et de déploiement dès le premier jour. Définissez les objectifs de point et de délai de reprise, et testez la restauration avant la mise en production.

16. Mettre en place la gouvernance et figer le périmètre. Un comité de pilotage hebdomadaire doté d’un pouvoir de décision, un journal des décisions, des démonstrations de sprint toutes les deux semaines et un product owner côté client qui tranche sur le périmètre. Ensuite, mettez le périmètre par écrit et faites-le valider. La première cause de retard est « tant qu’on y est, ajoutons aussi… ». D’abord migrer, ensuite enrichir.

Phase 3 : réalisation et migration (semaines 11 à 30)

17. Mettre en place les environnements Commerce Cloud. Provisionnez tous les environnements, vérifiez les pipelines de build et déployez une fois sur toute la chaîne avant d’écrire la moindre logique métier.

18. Reconstruire ou migrer la vitrine. Commencez par les modèles qui portent le plus de trafic : page d’accueil, pages catégories, fiches produits, checkout.

19. Refondre les intégrations. Testez chaque intégration avec des données réelles, pas avec des simulations. C’est dans les tests d’intégration qu’apparaissent la plupart des défauts de migration : testez tôt et souvent.

20. Réaliser des migrations de données d’essai. Au moins deux exécutions complètes avant la vraie bascule. Mesurez la durée, l’exactitude et le taux d’erreur, et corrigez les problèmes entre deux exécutions.

21. Mettre en œuvre le SEO et la performance. Déployez la table de redirections, les URL canoniques, le sitemap XML et le robots.txt, puis explorez l’environnement de préproduction. Optimisez la mise en cache CDN et les temps de réponse des API ; fixez des valeurs cibles pour les temps de chargement et les Core Web Vitals.

Phase 4 : tests et mise en production (semaines 31 à 38)

22. Recette avec les métiers. Des utilisateurs métier, pas des développeurs, testent la recherche, la navigation, le panier, le checkout, le paiement, les retours et les circuits B2B, dans chaque vitrine, chaque langue et chaque segment de clientèle.

23. Tests de charge à l’échelle. Simulez les jours de pointe. Commerce Cloud se dimensionne automatiquement ; votre propre code et vos intégrations, pas forcément.

24. Valider la migration SEO. Comparez les inventaires d’URL, vérifiez chaque redirection, validez les données structurées avec le test des résultats enrichis de Google.

25. Répéter et exécuter la bascule. Rédigez un runbook que chaque membre de l’équipe peut exécuter : gel des contenus, migration delta finale, bascule DNS, vérification de toutes les intégrations, 48 heures de surveillance. Répétez-le au moins une fois et documentez le retour arrière, y compris la manière dont les commandes passées après la bascule reviennent dans l’ancien système si vous devez revenir en arrière.

26. Surveiller après la mise en production. Au moins deux semaines de surveillance rapprochée : taux d’erreur, conversion par rapport à la référence, indexation, erreurs d’intégration, tickets de support. Configurez des alertes pour les écarts.

La mise en production n’est pas la ligne d’arrivée

Le trafic de production réel révèle des goulots d’étranglement qu’aucun test n’a trouvés. Planifiez dès le départ les semaines qui suivent la mise en production :

• Un sprint d’optimisation. Quatre à six semaines pour la mise en cache, les requêtes lentes, les temps de réponse des API et le rendu du frontend.
• La formation. Votre équipe doit savoir exploiter Commerce Cloud, gérer les contenus et circonscrire les incidents de façon autonome. Formez par étapes : d’abord l’exploitation, puis la configuration, puis le développement.
• Un backlog pour ce qui a été reporté. Ce qui est sorti du périmètre pendant la migration va dans un backlog priorisé, pas aux oubliettes. Revoyez-le régulièrement au lieu de tout construire d’un coup.
• Un rythme de mise à jour. Commerce Cloud attend de vous que vous adoptiez régulièrement les mises à jour. Prévoyez des créneaux fixes.

Calculateur de délais

Toutes les migrations ne se ressemblent pas. Ces facteurs déterminent les délais :

Comment lire ces chiffres en septembre 2026 : désormais, chaque mois compte, car chaque mois se passe en maintenance spécifique. Les projets accélérés peuvent être en production avant la fin de l’année ou début 2027. Les projets standard aboutissent dans le courant de 2027, et il vaut mieux découper les projets complexes en vagues, pour que les premiers marchés quittent tôt la plateforme on-premise. Le bas de la fourchette est décrit dans notre playbook en 90 jours.

Estimations de coûts par scénario

On nous pose la question à chaque premier entretien ; voici donc des valeurs indicatives tirées de nos projets plutôt qu’un vague « ça dépend » :

Accéléré (une vitrine, peu d’intégrations) : de 300’000 à 500’000 USD. Suppose un périmètre ciblé, des compétences SAP dans l’équipe et la volonté de reporter les personnalisations non essentielles.

Taille moyenne (deux ou trois vitrines, complexité modérée) : de 500’000 à 800’000 USD. C’est là que se situent la plupart de nos projets de migration : évaluation, réalisation, migration des données, refonte des intégrations, tests de performance et accompagnement de la mise en production.

Grande entreprise (cinq vitrines ou plus, B2B complexe, plusieurs pays) : de 800’000 à plus de 2 millions d’USD. La fourchette est large, car une activité B2B dans douze pays avec sa propre tarification et une intégration ERP profonde est un autre projet que cinq vitrines B2C avec checkout standard.

Ce sont des coûts de migration ponctuels. Non compris : les licences Commerce Cloud (annuelles, selon les volumes), les licences tierces (PIM, recherche, CMS), l’effort interne et les évolutions ultérieures. Prévoyez une réserve de 15 à 20 pour cent pour la qualité des données et les surprises côté intégrations. Le volet licences est détaillé dans notre guide des coûts de Commerce Cloud.

Ce que coûte l’attente : la maintenance spécifique est tarifée individuellement et se situe en règle générale bien au-dessus de ce que vous payiez pour la maintenance principale, sans nouvelles fonctionnalités ni correctifs réguliers. Comparez ce montant au budget de migration avant de décider d’attendre une année de plus.

Migration SEO : ne perdez pas votre positionnement

Nous avons vu des migrations techniquement impeccables perdre une grande partie de leur trafic organique parce que personne n’avait planifié la transition SEO. Pour de nombreuses boutiques, la recherche organique est l’un des principaux canaux de chiffre d’affaires.

Avant la migration :

1. Tout relever comme référence. URL indexées, clics, impressions et positions moyennes des requêtes principales depuis la Search Console, chaque semaine, car il vous faut la tendance et non un instantané.
2. Explorer le site actuel. Avec Screaming Frog ou Sitebulb : inventaire complet des URL, liens internes, balises canoniques, données structurées.
3. Associer chaque URL. Ancienne URL, nouvelle URL, type de redirection (presque toujours 301).

Pendant la migration :

4. Construire les redirections tôt, en parallèle de la nouvelle plateforme, et les tester en préproduction.
5. Préserver les métadonnées. Titres, descriptions, structure des titres et données structurées doivent être repris.
6. Tenir le sitemap XML prêt et le soumettre juste après la bascule DNS.

Après la migration :

7. Surveiller chaque jour pendant quatre semaines : taux d’indexation, erreurs 404, trafic organique par rapport à la référence, positions des 50 requêtes principales.
8. Corriger les problèmes le jour même. Pendant les premières semaines, Google réévalue l’ensemble de votre site.

Ce que nous avons retenu du lancement de Franke

Chez Franke, nous avons mis en production la plateforme SAP Commerce Cloud en 90 jours ; ce chiffre se rapporte au lancement commerce. Le point de départ était une ancienne plateforme négligée, mise en œuvre par un précédent partenaire. Nous l’avons remplacée par une architecture headless pour le B2B et le B2C, intégrée proprement à S/4HANA et C4C, et elle relie aujourd’hui plus de dix canaux internationaux. Le projet a reçu le SAP Quality Award pour « Rapid Time to Value ». Les détails figurent dans le témoignage Franke.

Trois enseignements valent pour toute migration :

• Auditer avant de migrer. Chaque personnalisation qui s’avère obsolète est du code que vous n’avez ni à migrer, ni à tester, ni à maintenir.
• Mener les chantiers en parallèle. Plateforme, données, intégrations et frontend en parallèle avec une coordination quotidienne, pas l’un après l’autre.
• Livrer par itérations. Déployer tôt dans le cloud, même de façon incomplète, et montrer chaque semaine les progrès aux parties prenantes.

Le risque de rester on-premise

Depuis août, ne rien faire n’est plus un plan, mais un état. Voici ce qu’il implique :

Sécurité. La plateforme traite des données personnelles et de paiement sans correctifs de sécurité réguliers. C’est difficilement compatible avec les exigences de PCI-DSS, du RGPD et de la nLPD suisse, et lors d’un audit, « nous n’avons pas migré à temps » n’est pas un argument.

Conformité. Les règles fiscales et les exigences de protection des données continuent d’évoluer. Sans mises à jour SAP, c’est à vous de les mettre en œuvre, dans des modules centraux que peu d’équipes savent modifier sans risque.

Coûts. La maintenance spécifique coûte plus cher que la maintenance principale, et les migrations ne deviennent pas meilleur marché : les développeurs ayant l’expérience de l’on-premise se font plus rares.

Talents. Les développeurs veulent travailler sur des plateformes actuelles. Un système figé complique le recrutement et la fidélisation.

Assurance et audit. Les assureurs cyber et les auditeurs (SOC 2, ISO 27001, PCI-DSS) s’intéressent à l’état de maintenance. Une plateforme de commerce qui n’est plus maintenue finit généralement en constat dans le rapport.

Prochaines étapes

1. Réserver une évaluation. Notre évaluation de migration structurée dure deux à trois semaines et livre l’inventaire des personnalisations, la cartographie des intégrations, l’évaluation de la complexité, le calendrier et l’enveloppe budgétaire. Demandez-la ici.
2. Approfondir. Le support on-premise est terminé : et maintenant ? traite des mesures transitoires ; le playbook en 90 jours montre à quoi ressemble une exécution rapide.
3. Choisir son partenaire en connaissance de cause. Notre panorama des meilleurs partenaires SAP Commerce Cloud en Suisse énumère les critères qui décident d’un projet de migration. Si votre ERP change aussi, nous livrons le cœur S/4HANA et l’ensemble de la pile CX avec une seule équipe ; voir le panorama pour le Cloud ERP et le CRM.
4. Consultez notre page consacrée à l’on-premise pour d’autres ressources.

L’échéance est passée. La durée de votre fenêtre d’exposition dépend toujours de vous. Parlons-en.

Questions fréquentes

Quand la maintenance principale de SAP Hybris on-premise a-t-elle pris fin ?

Le 31 juillet 2026. La version 2205 a été la dernière version on-premise de SAP Commerce, le produit autrefois appelé SAP Hybris. Depuis, SAP ne propose plus qu’une maintenance spécifique au client : les correctifs réguliers et les mises à jour réglementaires n’arrivent plus automatiquement.

Nous sommes encore on-premise après juillet 2026. Que faire maintenant ?

Clarifiez d’abord votre situation contractuelle avec SAP, comblez ensuite les failles de sécurité les plus exposées et lancez l’évaluation pour SAP Commerce Cloud. Une évaluation de deux à trois semaines fournit l’inventaire des personnalisations, la cartographie des intégrations, le calendrier et l’enveloppe budgétaire, afin que les mois passés en maintenance spécifique restent aussi peu nombreux que possible.

Combien de temps dure une migration de Hybris vers SAP Commerce Cloud ?

Une migration accélérée avec une vitrine et peu d’intégrations prend de trois à six mois ; le playbook en 90 jours décrit le bas de cette fourchette. Les projets standard avec deux ou trois vitrines prennent de six à douze mois, les déploiements complexes sur plusieurs pays de douze à dix-huit mois.

SAP Commerce Cloud est-il le même produit que SAP Hybris ?

Le cœur est le même : le système de types, le mécanisme d’extensions, Spring et le backend Java viennent de Hybris. Tout ce qui l’entoure a changé : SAP exploite l’infrastructure, les mises à jour arrivent en continu, les déploiements passent par le Cloud Portal et la vitrine recommandée est SAP Composable Storefront, en mode headless.

Nos personnalisations Hybris fonctionneront-elles dans SAP Commerce Cloud ?

Les extensions qui suivent le modèle de SAP (types personnalisés, surcharges de beans Spring, points de terminaison OCC) migrent généralement avec de petites modifications. Les accès directs à la base de données, les modifications du code livré par SAP, les intégrations par fichiers et les scripts d’infrastructure maison doivent être retravaillés. Le plus gros chantier est généralement la vitrine, surtout si vous utilisez encore une vitrine Accelerator.

Combien coûte une migration de Hybris vers Commerce Cloud ?

À titre indicatif, d’après nos projets : de 300’000 à 500’000 USD pour une migration accélérée, de 500’000 à 800’000 USD pour les projets de taille moyenne avec deux ou trois vitrines et de 800’000 à plus de 2 millions d’USD pour du B2B complexe sur plusieurs pays. Les licences Commerce Cloud, les outils tiers et l’effort interne s’y ajoutent ; prévoyez une réserve de 15 à 20 pour cent.