Moderniser SAP Commerce sans perdre le contrôle de la livraison.
Évaluation, remédiation, migration, validation, mise en production et stabilisation — un parcours par phases à travers JDK 21, Spring et Jakarta.
Pourquoi les montées de version s'enlisent
La plateforme a plusieurs versions de retard et l'effort n'a jamais été correctement dimensionné. Les extensions personnalisées reposent sur des internes : chaque tentative se transforme en débat de réécriture. Le métier refuse un gel de la livraison, donc la montée de version n'obtient jamais de créneau. Aucune couverture de non-régression fiable ne permet de prouver que la mise en production est sûre.
Ce que couvre une mission de montée de version
Évaluation de montée de version: Analyse de l'écart de version, inventaire des personnalisations, revue des dépendances et add-ons, plan chiffré. Modernisation du code: Refactoring des extensions personnalisées pour sortir des API dépréciées et des dépendances internes. Migration du framework: Changements JDK, Spring et espaces de noms Jakarta EE, alignement des librairies et correctifs de build. Migration CCV2: Passage des charges on-premise ou CCV1 vers CCV2 : manifeste, environnements et pipelines. Filet de non-régression: Couverture de tests automatisés sur les parcours critiques avant fusion de la branche de montée de version. Bascule et validation: Bascule répétée, validation des données, comparaison de performance et plan de retour arrière.
Domaines techniques traités
Sauts de version: D'anciennes versions Hybris jusqu'à SAP Commerce Cloud actuel, y compris les trajectoires en plusieurs étapes. Suppression des API dépréciées: Remplacement des API plateforme retirées ou dépréciées dans les extensions personnalisées. Migration du modèle de données: Évolutions du type system, mises à jour ImpEx et corrections de données appliquées sans risque. Stratégie d'add-ons: Décider quels add-ons conserver, remplacer ou retirer avant la montée de version. Build et pipeline: Manifeste CCV2, performance de build, propriétés d'environnement et automatisation des déploiements. Nouvelle référence de performance: Comparaison des parcours clés avant et après, pour rendre les régressions visibles.
Notre façon de mener une montée de version
Commencer par une évaluation : aucun plan n'est crédible sans connaître l'empreinte des personnalisations. Fixer une version cible et un séquencement compatible avec votre calendrier de releases. Construire la couverture de non-régression sur les parcours qui ne doivent pas casser. Réaliser la montée de version sur une branche parallèle fusionnée en continu avec la livraison courante. Répéter la bascule dans un environnement proche de la production avant la vraie bascule. Valider performance et stabilité après le go-live, avec une fenêtre de support définie.
Questions sur les montées de version
Combien de temps dure une montée de version SAP Commerce ? Cela dépend surtout de la profondeur des personnalisations et de l'écart de version : nous le dimensionnons par une évaluation plutôt que par une estimation générique. L'évaluation est courte et produit un plan chiffré et séquencé. Peut-on continuer à livrer des fonctionnalités pendant la montée ? Oui. La montée est réalisée sur une branche parallèle fusionnée en continu avec votre branche principale : la livraison ne gèle pas. Traitez-vous les anciennes versions Hybris ? Oui, y compris les trajectoires en plusieurs étapes depuis d'anciennes versions Hybris vers une version SAP Commerce Cloud actuelle. Et la migration vers CCV2 ? Nous couvrons le manifeste et la définition des environnements, les pipelines de build et de déploiement, la gouvernance des propriétés et secrets, ainsi que la migration des données et contenus avec une bascule répétée.