5 erreurs que commettent les entreprises lors de la migration hors de SAP Commerce On-Prem

Nous avons migré des plateformes SAP Commerce pour des entreprises comme Franke, ANWR et Distrelec. Chaque projet nous à appris quelque chose. Mais les leçons les plus précieuses sont venues des erreurs que nous avons aidé nos clients à éviter — où à surmonter.

Voici les cinq erreurs les plus courantes que commettent les entreprises lors de la migration hors de SAP Commerce on-prem. Chacune est évitable si vous savez quoi surveiller.

Erreur 1 : Reproduire les personnalisations on-prem à l’identique dans le cloud

C’est l’erreur la plus coûteuse. Les entreprises passent des années à développer des fonctionnalités personnalisées sur leur plateforme on-prem. Quand vient le moment de migrer, l’instinct est de tout transférer tel quel vers SAP Commerce Cloud.

Le problème ? Nombre de ces personnalisations étaient des solutions de contournement pour des limitations on-prem que Commerce Cloud à déjà résolues. Couches de cache personnalisées, scripts de mise à l’échelle manuels, pipelines de déploiement sur mesure — Commerce Cloud gère tout cela nativement.

Nous avons observé des migrations où 30 à 40 % du code personnalisé était inutile sur la plateforme cible. Chaque ligne de code superflue ajoute du temps de migration, de l’effort de test et des coûts de maintenance futurs.

Ce qu’il faut faire à la place : Avant de migrer une seule ligne de code, auditez chaque personnalisation. Classez-les : toujours nécessaire, remplaçable par une fonctionnalité de la plateforme, où obsolète. Nous menons une évaluation structurée qui identifie généralement 25 à 35 % des personnalisations comme supprimables. Cela réduit directement le coût et le calendrier de migration.

Erreur 2 : Sous-estimer la complexité de la migration des données

La migration des données semble simple sur le papier : exporter de la source, transformer, importer vers la cible. En pratique, c’est la phase qui fait déraper le plus de calendriers.

Les problèmes commencent par la qualité des données. Les systèmes on-prem accumulent des années de données incohérentes — doublons de fiches clients, références produits orphelines, commandes avec des attributs manquants, structures de catalogue qui ont évolué sans nettoyage.

Puis il y à le volume. Une plateforme de commerce B2B de taille moyenne peut avoir 50 millions de lignes de commande, 2 millions de fiches clients et 500 000 variantes de produits. Déplacer ces données proprement nécessite une conception ETL soignée, de multiples exécutions de test et une stratégie de migration delta pour la fenêtre de basculement.

Un projet lié à Distrelec sur lequel nous avons travaillé comportait des données couvrant plus de 15 ans d’historique commercial. Le seul mapping des données à pris trois semaines — et cet investissement nous à évité un problème catastrophique de qualité des données qui serait apparu après la mise en production.

Ce qu’il faut faire à la place : Commencez la découverte des données dès la première semaine. Profilez vos données pour détecter les problèmes de qualité avant d’écrire un seul script de migration. Intégrez la capacité de migration delta dès le départ — vous en aurez besoin. Et budgétisez 20 à 25 % de votre effort total de migration pour le travail sur les données. Si quelqu’un vous dit que la migration de données est « juste un export/import », il n’en à jamais réalisé une à grande échelle.

Erreur 3 : Ne pas nettoyer la dette technique avant de migrer

Migrer un système désordonné produit un déploiement cloud désordonné. La dette technique ne disparaît pas quand vous changez de plateforme — elle vous suit.

La dette technique courante que nous observons dans les déploiements SAP Commerce on-prem :

• Extensions inutilisées : Installées il y à des années pour une fonctionnalité ensuite abandonnée. Toujours chargées, toujours consommatrices de ressources, toujours créatrices de conflits de dépendances.
• Configurations codées en dur : Valeurs spécifiques à l’environnement intégrées dans le code au lieu d’être externalisées. Fonctionne on-prem où vous contrôlez l’infrastructure. Ne fonctionne plus dans le cloud où les environnements sont dynamiques.
• Intégrations obsolètes : Connexions à des systèmes remplacés où mis hors service. L’intégration fonctionne encore, génère encore des logs, ajoute encore de la complexité.
• Données de test en production : Restes de cycles UAT jamais nettoyés. Polluent les analyses et créent de fausses dépendances.

Une phase du projet ANWR à nécessité deux semaines de nettoyage avant que le travail de migration proprement dit puisse commencer. Cet investissement initial à réduit le calendrier de migration d’un mois car l’équipe ne déboguait pas des dépendances fantômes pendant la construction.

Ce qu’il faut faire à la place : Réalisez un audit de la dette technique 2 à 3 mois avant le début de la migration. Supprimez les extensions inutilisées, externalisez les configurations, dépréciez les intégrations mortes et purgez les données de test. Traitez cela comme un livrable autonome avec son propre calendrier et sa propre validation. L’équipe de migration doit hériter d’une base de code propre, pas d’un musée.

Erreur 4 : Choisir une approche en cascade au lieu d’une livraison itérative

Le plan classique : 3 mois de spécifications, 4 mois de développement, 2 mois de tests, puis un big-bang de mise en production. Nous l’avons vu. Cela échoue à grande échelle.

L’approche en cascade échoue dans les migrations commerce pour trois raisons :

1. Les exigences évoluent pendant le projet. Les besoins métier changent. SAP publie des mises à jour de la plateforme en pleine migration. Ce que vous avez spécifié au mois un peut être obsolète au mois cinq.
2. Les tests tardifs révèlent des problèmes tardifs. Quand vous testez tout à la fin, les problèmes s’accumulent. Une erreur de mapping de données découverte au mois huit nécessite une reprise de tout le développement.
3. Les basculements big-bang sont à haut risque. Basculer chaque marché, chaque vitrine et chaque intégration en un seul week-end crée une exposition maximale. Un seul échec affecte tout.

La migration Franke à réussi en 90 jours en partie parce que nous avons livré de manière itérative. Plateforme principale d’abord, puis vitrines, puis intégrations — chaque phase testée et validée avant le démarrage de la suivante.

Ce qu’il faut faire à la place : Découpez la migration en cycles de livraison de 2 à 4 semaines. Chaque cycle produit un incrément fonctionnel et testable. Priorisez par valeur métier : migrez votre vitrine à plus fort trafic en premier, stabilisez-la, puis étendez. Utilisez des feature flags pour contrôler le déploiement. Cette approche détecte les problèmes plus tôt, répartit les risques et offre aux parties prenantes une progression visible dès la deuxième semaine.

Erreur 5 : Attendre trop longtemps et se précipiter sous la pression des délais

C’est la méta-erreur — et la plus courante. Les entreprises connaissent l’échéance EoMM. Elles en discutent en comités de pilotage. Elles l’ajoutent aux registres de risques. Et puis elles n’agissent pas avant qu’il ne soit trop tard pour un calendrier confortable.

Une migration précipitée est une migration coûteuse. Voici ce qui se passe quand vous démarrez trop tard :

• Pas de temps pour le nettoyage. Vous migrez le désordre tel quel, puis passez des mois à le corriger dans le cloud.
• Tarifs premium pour les talents. Tous les partenaires d’implémentation sont complets. Vous payez un prix majoré pour la disponibilité.
• Tests compressés. Des raccourcis sont pris. Des problèmes qui auraient dû être détectés en recette atteignent la production.
• Pas de plan de repli. Si quelque chose tourne mal dans un basculement précipité, il n’y à pas de marge pour la récupération.

Nous observons que les entreprises qui démarrent 12 mois avant l’EoMM terminent leur migration pour 30 à 40 % de moins que celles qui démarrent avec 4 mois devant elles. Le travail est le même. La différence de coût vient entièrement du rythme, de la planification et de la disponibilité des bonnes personnes.

Ce qu’il faut faire à la place : Commencez maintenant. Pas le trimestre prochain. Maintenant. Même si la migration elle-même ne prend que 90 jours — comme pour Franke — vous avez besoin de temps pour l’évaluation, le nettoyage, la sélection du partenaire et l’alignement de l’équipe. Une migration de 90 jours nécessite une phase de préparation de 30 à 60 jours. Intégrez cela dans votre calendrier.

Le schéma commun derrière ces cinq erreurs

Chaque erreur de cette liste partage une cause racine : traiter la migration comme un exercice technique plutôt qu’une transformation métier. Les entreprises qui migrent en douceur sont celles qui :

• Auditent avant de construire
• Nettoient avant de déplacer
• Livrent par incréments au lieu de big-bangs
• Commencent assez tôt pour avoir des options

Nous avons réalisé des migrations SAP Commerce pour ANWR, Franke, Distrelec et d’autres — chacune avec des contraintes, des calendriers et des architectures différents. Le fil conducteur des projets réussis est la discipline dans la préparation.

Prêt à éviter ces erreurs ?

Si vous planifiez une migration SAP Commerce, commencez par une évaluation de migration. Nous auditerons vos personnalisations, profilerons vos données, estimerons votre calendrier et identifierons les pièges spécifiques à votre configuration.

Contactez-nous — faisons en sorte que votre migration se retrouve du bon côté de ces cinq leçons.