Coût d'une migration S/4HANA : ce qui le détermine selon la voie

Le coût d'une migration S/4HANA se situe dans les mêmes fourchettes que n'importe quel programme SAP. Prévoyez 500 000 $ à 2 M$ dans une entreprise de taille intermédiaire, 2 M$ à 10 M$ ou plus dans une grande entreprise et 10 M$ à 50 M$ ou plus dans un groupe mondial. L'endroit où vous tombez dans la fourchette dépend moins de la voie que du code spécifique, des données, des conversions à blanc, du double fonctionnement et de votre contrat SAP.

En bref : aucune voie de migration n'est moins chère par défaut. Le coût brownfield ou greenfield dépend de la quantité de code spécifique que vous traînez, de la propreté de vos données et de l'ampleur des changements de processus que vous voulez. D'après mon expérience, le code spécifique est la phase qui dépasse le plus souvent, et le coût caché que les entreprises oublient le plus souvent.

Cet article porte précisément sur la facture de la migration. Les voies, les étapes et les échéances d'ECC sont dans mon guide de migration d'ECC vers S/4HANA.

Pour ce que coûte SAP en général et où va l'argent, lisez combien coûte une mise en œuvre SAP. Pour comprendre pourquoi les budgets dérapent une fois le travail lancé, lisez pourquoi les projets SAP dépassent leur budget.

Une migration est un programme SAP complet, elle utilise donc les mêmes fourchettes de travail que j'utilise pour tout programme SAP. Elles couvrent les services du partenaire, l'abonnement ou les licences, les données, les tests, la formation et l'hypercare.

Voici où se situe chaque tranche, et ce qui fait monter une migration dans sa tranche :

Taille de l'entreprise	Coût total du programme (USD)	Ce qui fait monter une migration dans la fourchette
Petite (moins de 200 salariés)	80 K$ à 500 K$	Volume des données historiques, add-ons sans version S/4HANA
Taille intermédiaire (200 à 1 000)	500 K$ à 2 M$	Volume de code spécifique, intégrations, qualité des données
Grande (1 000 à 10 000)	2 M$ à plus de 10 M$	Code spécifique, nombre de conversions à blanc, périmètre des tests de non-régression
Groupe mondial (plus de 10 000)	10 M$ à plus de 50 M$	Nombreuses entités et nombreux pays, double fonctionnement sur plusieurs vagues de déploiement

Deux proportions valent pour toutes les tranches. Les services du partenaire représentent 35 à 50 % du total, et une réserve de 10 à 20 % vient s'ajouter, détenue par vous plutôt qu'intégrée au prix du partenaire.

Les références publiques se situent au même niveau. LeverX, un partenaire SAP, estime une mise en œuvre greenfield dans une grande entreprise aux États-Unis à 4 M$ à plus de 10 M$ (guide des coûts LeverX pour les États-Unis, 2026). Pour un premier chiffre sur votre propre périmètre, essayez le calculateur de coût de mise en œuvre SAP.

On veut un pourcentage : le brownfield coûterait X % de moins que le greenfield. Ma réponse honnête est que cela dépend, et je ne donne pas de pourcentage. La voie change davantage la destination de l'argent que son montant.

Une conversion de système (brownfield) conserve votre paramétrage, votre code spécifique et votre historique. Une nouvelle mise en œuvre (greenfield) repart de zéro et ne charge que les données dont vous avez besoin, et une selective data transition fait un peu des deux avec des outils spécialisés.

Voici où chaque voie dépense l'argent :

Voie	Où va l'argent	Ce qui la rend chère	Ce qui la garde basse
Brownfield (conversion de système)	Remédiation du code spécifique, essais de conversion avec le Software Update Manager, tests de non-régression de tout ce que vous avez conservé	Un gros code spécifique que personne n'utilise, des add-ons à remplacer, une fenêtre d'arrêt courte sur une grosse base de données	Retirer le code inutilisé avant la conversion, des processus qui fonctionnent déjà
Greenfield (nouvelle mise en œuvre)	Conception des processus, paramétrage, extensions, chargements de données, formation et conduite du changement	Reconstruire d'anciens états et une ancienne logique spécifiques dans le nouveau système, repenser des domaines qui fonctionnaient	Adopter le standard SAP, ne charger que les postes ouverts et l'historique dont vous avez besoin
Selective data transition	Outils et partenaire spécialisés, cadrage des données, plus un peu de refonte et un peu de conversion	Sélection complexe de sociétés et d'historique, fusions et cessions (carve-outs)	Une décision serrée sur les domaines à repenser

Alors, de quoi cela dépend-il ? Ces quatre questions tranchent :

1. Quelle quantité de code spécifique vous traînez, et quelle part est utilisée. Dans une conversion, chaque objet conservé doit être vérifié, corrigé si nécessaire et testé.
2. La propreté de vos données et la quantité d'historique dont vous avez besoin. Des données de mauvaise qualité coûtent de l'argent sur toutes les voies, à un endroit différent sur chacune.
3. L'ampleur des changements de processus que vous voulez. Ma règle : greenfield quand vous venez d'autres systèmes ou que de nouveaux processus doivent être définis, brownfield quand les processus sont définis et fonctionnent, sélective quand certains domaines doivent être repensés. Payer pour repenser des processus qui fonctionnent déjà est le choix coûteux.
4. L'arrêt que le métier peut supporter. Les grands systèmes avec des fenêtres courtes ont besoin de techniques de réduction de l'arrêt et des spécialistes pour les mettre en œuvre.

Le coût suit aussi la durée. D'après mon expérience, un brownfield prend 12 à 18 mois, un greenfield 18 à 24 mois et une selective data transition 12 à 18 mois. Mon calendrier et plan de projet de migration S/4HANA détaille ces durées phase par phase.

Le code spécifique est la phase que je vois dépasser le plus souvent lors d'une migration. C'est aussi le coût que les entreprises oublient le plus souvent quand elles fixent le budget.

Il se cache parce qu'il ressemble à une tâche technique. Dans une conversion brownfield, vos programmes Z, vos extensions et vos modifications sont repris, et chacun de ceux qui touchent un modèle de données modifié doit être adapté et retesté.

Le SAP Readiness Check est le bon point de départ, mais c'est un outil de planification. D'après mon expérience, ce qu'il manque et qui fait mal plus tard, ce sont les objets spécifiques.

Le Conversion Guide for SAP S/4HANA Cloud Private Edition 2025 de SAP vous renvoie à l'ABAP Test Cockpit pour les contrôles du code spécifique. Il recommande aussi de supprimer le code spécifique qui n'est plus utilisé avant de convertir.

C'est dans cette recommandation que se trouvent les économies. Sur un programme, l'analyse avec smartShift nous a fait passer de 18 000 objets spécifiques à 3 200, et chaque objet retiré était un objet que personne n'avait à corriger, à tester ou à emporter dans les futures mises à niveau.

Avant que quiconque ne chiffre une migration, je voudrais des réponses à ces questions :

1. Combien d'objets spécifiques existent ? Comptez-les à partir de votre propre système, pas à partir de l'estimation du partenaire.
2. Combien sont réellement utilisés ? Des données d'utilisation issues de la production, sur un cycle d'activité complet, clôture annuelle comprise.
3. Lesquels seront retirés, et qui décide ? Une autorité de conception réunissant le métier et l'informatique, pas les développeurs seuls.
4. Qu'est-ce qui remplace ceux que vous gardez ? Des fonctions standard, des API publiées ou des extensions side-by-side, dans l'esprit du Clean Core.

Réduisez les développements spécifiques au minimum et gouvernez le reste. L'erreur courante que je vois est de vouloir faire fonctionner SAP comme Oracle, ce qui transforme chaque différence en code. Mon guide du Clean Core SAP explique comment classer ce qui reste.

D'après mon expérience, la migration des données représente 30 à 40 % de l'effort. Une bonne part de cet effort repose sur vos propres utilisateurs métier, qui nettoient et valident, et elle apparaît donc rarement dans un devis de partenaire.

Sur une conversion brownfield, je prévois trois conversions à blanc avant la bascule. Chacune coûte de l'argent réel : une copie de système, l'équipe technique qui exécute la conversion, des contrôles fonctionnels et le rapprochement des résultats par le métier.

Vérifiez ce que votre contrat couvre déjà. Le guide de conversion de SAP pour la Private Edition indique que le périmètre contractuel standard inclut deux essais à blanc (dry runs), un pour les systèmes hors production et un pour la production. D'autres peuvent être ajoutés sous forme de service facturable.

Si vous en prévoyez trois, convenez dès le départ de qui paie le troisième.

L'arrêt est l'autre coût de cette phase. Les arrêts de bascule que j'ai vus vont d'un week-end à une semaine, et le métier paie chaque jour où il ne peut ni expédier, ni facturer, ni clôturer.

Vous pouvez le raccourcir. Le Software Update Manager propose une conversion downtime-optimized, mais le guide de SAP indique que la version Private Edition exige un expert SAP ayant suivi la formation ADM329. C'est une ligne de spécialiste dans le budget, pas un interrupteur gratuit.

Les tests bouclent la boucle. Une conversion conserve tout, donc les tests de non-régression doivent couvrir tout ce que vous avez conservé, et ce périmètre grandit avec chaque objet spécifique que vous n'avez pas retiré.

Deux coûts se situent hors du plan de projet, et tous deux atterrissent sur le bureau du CFO.

Le premier est le double fonctionnement. Pour SAP ERP 6.0 sur les enhancement packages 6 à 8, la maintenance standard prend fin le 31 décembre 2027. La maintenance étendue optionnelle jusqu'à fin 2030 coûte deux points de pourcentage supplémentaires (SAP News).

Un programme greenfield lancé aujourd'hui court jusqu'en 2028 : ECC continue donc de tourner, et de coûter, pendant que vous construisez. Prévoyez au moins une partie de maintenance étendue, l'équipe de support ECC et les interfaces qui doivent alimenter les deux systèmes pendant un déploiement par phases.

Le second est la conversion du contrat. Passer à RISE with SAP signifie S/4HANA Cloud Private Edition, que SAP commercialise désormais sous le nom de SAP Cloud ERP Private. Votre position en licences et en maintenance se transforme en abonnement, et les conditions sont négociées, pas publiées.

Les plus gros pièges que je vois dans un contrat RISE sont les conditions de renouvellement, le dimensionnement en full user equivalent (FUE) et les crédits AI. Ce que je négocie toujours, c'est la liste des modules inclus et une tarification par phase, pour que vous payiez au fur et à mesure que les phases passent en production plutôt que dès le premier jour.

Demandez à SAP par écrit ce que deviennent vos licences existantes et vos paiements de maintenance. Mon guide sur le contrat et la tarification RISE with SAP couvre ce qui est inclus, ce qui ne l'est pas et les points sur lesquels insister.

Sur les 21 programmes SAP que j'ai dirigés ou redressés, la plus grande erreur que je vois est de ne pas planifier correctement au départ. Les budgets prennent un coup dans la phase Explore, à mesure que la liste WRICEF (états, interfaces, conversions, extensions, formulaires, workflows) s'allonge, et laisser les prestataires contrôler le périmètre en est une cause profonde.

Voici l'ordre que je suivrais :

1. Lancez le SAP Readiness Check et les contrôles du code spécifique avant de demander un prix à qui que ce soit.
2. Décidez quel code spécifique est retiré via une autorité de conception réunissant le métier et l'informatique.
3. Profilez les données et dimensionnez l'effort données à 30 à 40 % du programme.
4. Comptez les conversions à blanc et les essais à blanc, et convenez de qui paie chacun.
5. Chiffrez le double fonctionnement, y compris la maintenance étendue si le go-live tombe après 2027.
6. Rédigez le périmètre vous-même, pour que le partenaire chiffre votre périmètre et non le sien.
7. Ajoutez 10 à 20 % de réserve, détenue de votre côté.

Allez ensuite voir les partenaires. Demandez des références et leur conception générale de votre migration, et écartez les réponses génériques qui pourraient s'appliquer à n'importe quelle entreprise. Mon guide pour choisir un partenaire de migration S/4HANA couvre la suite de cette conversation.

L'étape concrète suivante : extrayez ce mois-ci le nombre d'objets spécifiques et les données d'utilisation de votre propre système de production. C'est le chiffre qui fait le plus bouger un budget de migration, et vous pouvez l'avoir avant qu'un partenaire n'entre dans la pièce.

Si vous voulez un avis indépendant sur un budget de migration ou une proposition de partenaire, j'aide les organisations sur ce sujet. Vous pouvez me contacter ici.

Combien coûte une migration S/4HANA ?

Les fourchettes de travail que j'utilise sont de 80 000 $ à 500 000 $ pour une petite entreprise et de 500 000 $ à 2 millions de dollars pour une entreprise de taille intermédiaire. Une grande entreprise devrait prévoir 2 à 10 millions de dollars ou plus, et un groupe mondial 10 à 50 millions de dollars ou plus. Les services du partenaire représentent 35 à 50 % du total, et le code spécifique, les données et le nombre de conversions à blanc décident de votre position dans la fourchette.

Le brownfield est-il moins cher que le greenfield pour S/4HANA ?

Pas par défaut. Cela dépend de la quantité de code spécifique que vous traînez, de la propreté de vos données, de l'ampleur de la refonte des processus et de l'arrêt que vous pouvez supporter. Une conversion brownfield avec un gros code spécifique inutilisé peut coûter plus cher qu'une mise en œuvre greenfield qui adopte le standard SAP.

Quel est le plus gros coût caché d'une migration S/4HANA ?

Le code spécifique. D'après mon expérience, c'est le coût que les entreprises oublient le plus souvent et la phase qui dépasse le plus souvent. Comptez vos objets spécifiques et vérifiez lesquels sont utilisés avant que quiconque ne chiffre la migration.

Combien de conversions à blanc faut-il pour une conversion S/4HANA ?

Sur une conversion brownfield, je prévois trois conversions à blanc avant la bascule. Le guide de conversion de SAP pour la Private Edition inclut deux essais à blanc dans le périmètre contractuel standard, un pour le hors production et un pour la production, d'autres étant disponibles sous forme de service facturable. Convenez de qui paie tout essai supplémentaire avant de signer.

Quelle réserve ajouter au budget d'une migration S/4HANA ?

Gardez 10 à 20 % en plus du budget, de votre côté plutôt qu'intégrés au prix du partenaire. Débloquez-les face à des risques identifiés, comme des problèmes de code spécifique ou de données découverts pendant les tests, pas pour couvrir un périmètre qui n'a jamais été chiffré.

RISE with SAP rend-il une migration S/4HANA moins chère ?

Il change la forme du coût plus que son montant. Les licences, l'hébergement et l'exploitation technique passent dans un abonnement, mais le code spécifique, les données, les tests et la conduite du changement restent dans le budget de votre programme. Surveillez les conditions de renouvellement, le dimensionnement FUE et les crédits AI, et négociez les modules inclus et une tarification par phase.