Migration d'ECC vers S/4HANA : voies, étapes et échéances SAP ECC

Une migration d'ECC vers S/4HANA fait passer votre système SAP ERP de SAP ECC 6.0 à SAP S/4HANA, avec une nouvelle base de données, un nouveau modèle de données financières et une nouvelle interface utilisateur. La décision qui vous attend : quelle voie choisir, et pouvez-vous passer en production avant la fin de la maintenance standard d'ECC le 31 décembre 2027 ?

Réponse courte : greenfield si vous venez d'autres systèmes ou avez besoin de nouveaux processus, brownfield si vos processus sont définis et fonctionnent, selective data transition si seuls certains domaines doivent être repensés. 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. Lancez le SAP Readiness Check avant de vous engager sur l'une d'elles.

Passer d'ECC à S/4HANA n'est pas une simple mise à niveau. Cela change la façon dont les données sont stockées, dont les transactions sont comptabilisées et dont les utilisateurs travaillent.

Sur un projet auquel j'ai participé, une équipe a fait reconstruire des dizaines de rapports spécifiques exactement comme ils étaient dans ECC. Personne n'a demandé s'ils servaient encore. Par la suite, la moitié n'a jamais été utilisée.

La migration était techniquement propre. La valeur, non.

SAP ECC signifie SAP ERP Central Component. C'est le cœur de SAP ERP 6.0, l'une des applications centrales de SAP Business Suite 7, et quand on dit « SAP ECC », on parle presque toujours d'ECC 6.0. Il gère la finance, le contrôle de gestion, les achats, les ventes et la production sur toute base de données prise en charge par SAP, d'Oracle à SQL Server et Db2.

La première raison de migrer, c'est la maintenance. Pour SAP ERP 6.0 sur les enhancement packages 6 à 8, la maintenance standard prend fin le 31 décembre 2027. Les systèmes sur l'enhancement package 5 ou inférieur sont sortis de la maintenance standard fin 2025 (SAP).

SAP S/4HANA est le successeur, et SAP s'est engagé à le maintenir jusqu'à fin 2040.

La deuxième raison, c'est le temps. Lancez aujourd'hui, en octobre 2026, une conversion brownfield, et le go-live tombe entre fin 2027 et le printemps 2028. Lancez un greenfield aujourd'hui, et vous passez en production en 2028.

Pour la plupart des clients ECC, la question n'est donc plus de savoir s'il faut migrer. C'est quelle voie prendre, et combien de maintenance étendue budgéter pendant la migration.

J’aborde aussi ce sujet dans une vidéo sur ma chaîne YouTube (en anglais).

Voici les différences qui génèrent l'essentiel de l'effort de migration :

Domaine	SAP ECC	SAP S/4HANA
Base de données	Toute base de données prise en charge (Oracle, Db2, SQL Server, autres)	SAP HANA uniquement
Modèle de données financières	Tables FI, CO et rentabilité séparées, avec tables de totaux	Universal Journal (table ACDOCA) comme source unique au niveau des postes individuels
Données de base clients et fournisseurs	Fiches clients et fournisseurs séparées	Le business partner est obligatoire
Numéro d'article	18 caractères	Jusqu'à 40 caractères, si vous activez la longueur étendue
Gestion du crédit	Gestion du crédit SD	SAP Credit Management (FIN-FSCM)
Interface utilisateur	SAP GUI	Applications SAP Fiori, SAP GUI restant disponible on-premise et en Private Edition
Déploiement	On-premise	On-premise, Private Edition (RISE with SAP) ou Public Edition (GROW with SAP)
Extensions	Programmes Z et modifications	Clean Core : API publiées, ABAP Cloud on-stack ou side-by-side sur SAP BTP
Maintenance	EHP 6 à 8 : standard jusqu'à fin 2027, étendue jusqu'à fin 2030	Garantie jusqu'à fin 2040

SAP consigne chacune de ces différences comme un simplification item et les publie dans la Simplification List de chaque version de S/4HANA. Certaines sont obligatoires pour tous les clients, comme le business partner. D'autres ne comptent que si vous utilisez la fonction, et le SAP Readiness Check vous indique celles qui s'appliquent à votre système.

Un client industriel européen avec qui j'ai travaillé en 2023 demandait sans cesse pourquoi ses jobs batch spécifiques ne fonctionnaient plus après la conversion. La logique reposait sur des structures de tables ECC que S/4HANA avait modifiées. Personne ne s'était demandé si ces jobs avaient encore un sens dans le nouveau modèle.

La migration déplace les données. La vraie question, c'est ce que vous faites des choix de conception dont vous héritez.

Ma règle de choix est courte. Greenfield quand vous venez d'autres systèmes ou quand de nouveaux processus doivent être définis. Brownfield quand vos processus sont définis et fonctionnent, et selective data transition quand les processus de certains domaines doivent être redéfinis.

Decide

Quelle voie d'ECC vers S/4HANA correspond à votre situation ?

→Greenfield

Vous venez d'autres systèmes, ou de nouveaux processus doivent être définis

→Brownfield

Les processus sont définis et fonctionnent

→Selective data transition

Seuls certains domaines doivent redéfinir leurs processus

Greenfield : une nouvelle mise en œuvre

Une nouvelle mise en œuvre de S/4HANA. Aucun paramétrage hérité n'est repris, les processus sont conçus selon le standard SAP et seules les données dont vous avez besoin sont chargées.

C'est le choix naturel si une partie de votre activité tourne aujourd'hui sur des systèmes non SAP. J'ai vu des entreprises regretter de ne pas avoir préparé leurs utilisateurs à quel point un système greenfield paraît différent. Si la préparation à l'adoption commence à la formation, il est déjà tard.

Brownfield : conversion du système

Le brownfield est une conversion du système. Votre système ECC existant est converti sur place, et le paramétrage, le code spécifique et l'historique vous suivent. La conversion technique passe par le Software Update Manager (SUM) avec sa Database Migration Option.

SAP publie pour chaque version un Conversion Guide for SAP S/4HANA, avec les prérequis et l'ordre des étapes techniques. Lisez celui de votre version cible avant de planifier des dates. Le risque, c'est la dette technique que vous emportez, car la complexité héritée vous suit si vous ne la nettoyez pas délibérément.

Selective data transition

La selective data transition transfère des sociétés, des unités opérationnelles ou des tranches temporelles de données choisies, pas tout. Elle exige des outils spécialisés et un partenaire qui en a l'expérience. Certains éditeurs la vendent sous le nom de « bluefield ».

Elle convient aux groupes où la finance fonctionne bien mais où les achats doivent être repensés, ou bien où des fusions et des cessions ont laissé côte à côte des processus très différents. Vous repensez les domaines qui en ont besoin et gardez l'historique là où il compte.

Voici comment les trois se comparent sur les questions que posent habituellement les comités de direction :

Voie	Quand la choisir	Délai typique	Risque principal
Greenfield	Vous venez d'autres systèmes, ou de nouveaux processus doivent être définis	18 à 24 mois	Charge du changement pour les utilisateurs, et historique laissé derrière
Brownfield	Les processus sont définis et fonctionnent	12 à 18 mois	Dette technique et code spécifique inutilisé reportés
Selective data transition	Les processus de certains domaines doivent être redéfinis	12 à 18 mois	Dépendance aux outils et partenaires spécialisés, et périmètre de données complexe

La voie change le détail, mais la séquence reste la même. Voici les cinq étapes que je planifierais, dans l'ordre.

La séquence de migration

1. 01

   Readiness check

   Lancez le SAP Readiness Check et confirmez les prérequis techniques.

2. 02

   Choisir et planifier

   Choisissez la voie, fixez le périmètre et planifiez tout le programme avant le début de la réalisation.

3. 03

   Code spécifique

   Identifiez ce qui est utilisé, retirez le reste, adaptez ce qui reste.

4. 04

   Données

   Classez, nettoyez et archivez avant de déplacer quoi que ce soit.

5. 05

   Tester et basculer

   Plusieurs cycles de tests et au moins une répétition complète du cutover.

1. Lancer le readiness check

Commencez ici. Toujours. Le SAP Readiness Check analyse votre système ECC et rend compte des simplification items, de la compatibilité des add-ons, du code spécifique, des volumes de données et du dimensionnement.

Les surprises viennent en général des add-ons et du code spécifique. Certains clients avec qui j'ai travaillé avaient des centaines d'objets spécifiques dans le périmètre. Mieux vaut le découvrir la deuxième semaine que le douzième mois.

Pour une conversion brownfield, vérifiez en même temps ces prérequis :

1. Version : la conversion fonctionne à partir de SAP ERP 6.0 sur n'importe quel enhancement package.
2. Unicode : le système doit être en Unicode, sinon vous prévoyez une conversion en deux étapes.
3. Dual-stack : les systèmes dual-stack doivent d'abord être scindés.
4. Business partner : les données de base clients et fournisseurs doivent être converties en business partners avant la conversion. C'est ce point qui piège le plus d'équipes.

2. Choisir la voie et planifier le programme

Utilisez les résultats du readiness check et ma règle ci-dessus pour choisir la voie. Planifiez ensuite tout le programme, données, tests et cutover compris, avant que quiconque commence la réalisation.

Sur les 21 programmes SAP que j'ai dirigés ou redressés, la plus grosse erreur de migration que je constate, c'est de ne pas la planifier correctement au début de la mise en œuvre. Décidez dans les premières semaines qui est responsable du nettoyage des données, quel code spécifique est retiré et quand ont lieu les répétitions du cutover. Ces décisions coûtent cher si elles sont prises tard.

3. Adapter le code spécifique

Lancez les contrôles S/4HANA dans l'ABAP Test Cockpit, qui comparent votre code aux simplification items de SAP. L'application Custom Code Migration affiche les mêmes résultats avec les données d'utilisation, pour que vous voyiez ce qui est utilisé avant de corriger quoi que ce soit.

L'objectif, c'est moins de code Z, pas seulement du code Z qui fonctionne. Sur un programme, l'analyse avec smartShift nous a fait passer de 18 000 objets spécifiques à 3 200.

Chaque objet spécifique que vous emportez renchérit chaque future mise à niveau. J'ai vu des entreprises réduire de 40 % la durée de leurs mises à niveau grâce aux principes du Clean Core, et mon guide SAP Clean Core explique comment classer ce qui reste.

4. Préparer et transférer les données

Classez, nettoyez et archivez avant de déplacer quoi que ce soit. Cette étape prend plus de temps que ne le prévoit n'importe quel plan, elle a donc sa propre section plus bas.

5. Tester, former et basculer

Testez par cycles : tests unitaires, tests d'intégration et tests d'acceptation utilisateur (UAT), puis au moins une répétition complète du cutover. Faites participer aux UAT à la fois des utilisateurs clés et des utilisateurs occasionnels, car ils trouvent des problèmes différents.

La répétition n'est pas optionnelle. Elle révèle des écarts de timing, des validations manquantes et des défaillances d'interfaces qui n'apparaissent que lorsque toute la séquence s'exécute. Les équipes qui la sautent rencontrent ces problèmes le week-end du go-live.

D'après mon expérience, la migration des données représente 30 à 40 % de l'effort de mise en œuvre. C'est aussi la raison la plus fréquente des glissements de planning.

La manière dont les données sont transférées dépend de la voie. En brownfield, SUM convertit les données sur place. En greenfield, vous chargez les données de base et les postes ouverts avec le SAP S/4HANA Migration Cockpit, et en selective data transition, des outils spécialisés transfèrent le périmètre que vous avez choisi.

Quelle que soit la voie, triez les données avant de les déplacer :

1. Chaudes : utilisées souvent, nécessaires aux opérations courantes.
2. Tièdes : accès occasionnel, pertinentes mais pas au quotidien.
3. Froides : historiques ou inutilisées, conservées uniquement pour l'audit.

Les données froides n'ont pas à aller dans S/4HANA. Archivez-les. Fiches fournisseurs en double, unités de mesure incohérentes et données de base clients à moitié renseignées existent dans tous les systèmes ECC, et elles passent intactes dans S/4HANA si personne ne les corrige avant.

Un client avec qui j'ai travaillé a passé cinq mois rien que sur le nettoyage et l'archivage des données. Mon article sur les raisons de l'échec des migrations de données SAP approfondit cette étape.

Voici les cinq outils que j'ai utilisés sur des programmes ECC vers S/4HANA. Deux viennent de SAP et trois d'éditeurs spécialisés :

Outil	Éditeur	Ce qu'il fait	Où il s'insère
SAP Readiness Check for SAP S/4HANA	SAP	Rend compte des simplification items, de la compatibilité des add-ons, de l'impact sur le code spécifique, des volumes de données et du dimensionnement	Avant le choix de la voie
Application Custom Code Migration	SAP	Application SAP Fiori qui exécute les contrôles S/4HANA de l'ABAP Test Cockpit et s'appuie sur les données d'utilisation pour repérer le code inutilisé ; fonctionne dans S/4HANA ou dans l'environnement ABAP de SAP BTP	Cadrage et adaptation du code spécifique
smartShift	smartShift Technologies	Analyse et transformation automatisées du code ABAP spécifique pour S/4HANA	Analyse et correction du code spécifique
SNP (plateforme Kyano)	SNP Group	Logiciel de transformation des données pour la selective data transition, commercialisé sous l'approche « Bluefield » de SNP	Selective data transition, fusions et cessions
Natuvion	Natuvion Group	Logiciel de conversion des données et outils de cutover pour les transitions vers S/4HANA	Selective data transition et cutover

SNP et Natuvion sont tous deux membres fondateurs de la Selective Data Transition Engagement community de SAP. Les autres outils SAP que vous croiserez sont SUM pour la conversion brownfield et le Migration Cockpit pour les chargements de données greenfield.

Un outil ne remplace pas les décisions. Quelqu'un de votre côté doit encore valider ce qui est retiré.

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 court de 2028 au 31 décembre 2030, avec une majoration de deux points de pourcentage sur votre base de maintenance actuelle (SAP News).

Au-delà de 2030, il existe une voie étroite, la SAP ERP, private edition, transition option. Elle offre une maintenance de 2031 à 2033 aux clients qui transfèrent leur système ECC dans le cloud privé de SAP en tant que SAP ERP, private edition, sur SAP HANA, dans le cadre de RISE with SAP. Le système doit être transféré avant le 31 décembre 2030, faire au moins 2 To et nécessite le max success plan de SAP.

2033 n'est donc pas une échéance générale. Elle s'applique aux grands systèmes qui ont déjà transféré ECC dans le cloud de SAP. Pour tous les autres, ECC sur votre propre infrastructure a 2027 comme date de fin de maintenance standard et 2030 comme fin de la maintenance étendue.

1. 2027Fin de la maintenance standard d'ECC31 décembre, pour SAP ERP 6.0 EHP 6 à 8
2. 2028Go-live probable si vous commencez maintenantBrownfield 12 à 18 mois, greenfield 18 à 24
3. 2030Fin de la maintenance étendueOptionnelle, avec deux points de majoration
4. 2033Fin de la transition optionSAP ERP, private edition uniquement, systèmes de 2 To ou plus

Source: SAP News, février 2020 et août 2025

Le calcul est simple. Budgétez au moins un peu de maintenance étendue, et utilisez ce temps pour nettoyer les données et retirer du code spécifique plutôt que pour attendre.

Le coût suit les mêmes facteurs que le délai : la voie, le volume de code spécifique, l'état de vos données et le nombre d'entités qui passent en production. Les données à elles seules représentent 30 à 40 % de l'effort, c'est pourquoi un plan de données propre fait économiser plus d'argent que n'importe quelle négociation de tarifs. Mon guide du coût d'une migration S/4HANA couvre ce qui détermine un budget de migration, et mon guide du coût d'une mise en œuvre SAP détaille le budget par taille d'entreprise.

Pour voir comment un programme s'est déroulé, lisez mon étude de cas de migration d'ECC vers S/4HANA. Pour évaluer vos propres options, essayez l'évaluation de migration greenfield ou brownfield.

Cet article est la vue d'ensemble. Chaque guide ci-dessous répond entièrement à une question.

1. Calendrier et plan de projet de migration S/4HANA : phase par phase, selon la voie, avec les conversions à blanc et la bascule.
2. Coût d'une migration S/4HANA : ce qui détermine le budget d'une conversion, d'une nouvelle mise en œuvre ou d'une transition sélective.
3. SAP Readiness Check et évaluation de migration : ce que le check vous dit et ce qu'il manque.
4. SAP S/4HANA Migration Cockpit, pas à pas : charger les données avec des tables de staging ou par transfert direct.
5. RISE with SAP : cloud public ou cloud privé : quelle édition convient à vos processus.
6. Contrat et tarification RISE with SAP : ce que couvre l'abonnement et ce qu'il faut négocier.
7. Comment choisir un partenaire de migration S/4HANA : les questions à poser et les signaux d'alerte.
8. Redressement de projet SAP : comment sauver une migration qui dérape.

Deux outils aident pour les chiffres : le calculateur de coût de mise en œuvre SAP et l'estimateur de migration des données.

Qu'est-ce que SAP ECC ?

SAP ECC (SAP ERP Central Component) est le cœur de SAP ERP 6.0, qui fait partie de SAP Business Suite 7. Il couvre la finance, le contrôle de gestion, la logistique et d'autres processus clés, et fonctionne sur plusieurs bases de données. SAP S/4HANA est son successeur et ne fonctionne que sur SAP HANA.

Combien de temps dure une migration d'ECC vers S/4HANA ?

D'après mon expérience, une conversion brownfield prend 12 à 18 mois, une mise en œuvre greenfield 18 à 24 mois et une selective data transition 12 à 18 mois. Le nettoyage des données est la raison la plus fréquente des glissements de planning, car la migration des données représente 30 à 40 % de l'effort de mise en œuvre.

Que se passe-t-il pour SAP ECC après 2027 ?

Pour SAP ERP 6.0 sur les enhancement packages 6 à 8, la maintenance standard prend fin le 31 décembre 2027. Vous pouvez souscrire une maintenance étendue optionnelle jusqu'au 31 décembre 2030 moyennant deux points de pourcentage supplémentaires. De 2031 à 2033, la maintenance n'est disponible que via la SAP ERP, private edition, transition option, pour les grands systèmes transférés dans le cloud privé de SAP avant fin 2030.

Brownfield ou greenfield : lequel est le meilleur ?

Aucun n'est meilleur en général. Choisissez le greenfield quand vous venez d'autres systèmes ou que de nouveaux processus doivent être définis, et le brownfield quand vos processus sont définis et fonctionnent. Si seuls certains domaines doivent être repensés, envisagez la selective data transition.

Qu'est-ce que la selective data transition chez SAP ?

La selective data transition transfère vers S/4HANA des sociétés, des unités opérationnelles ou des tranches temporelles de données choisies, au lieu de tout convertir ou de repartir de zéro. Elle vous permet de repenser certains domaines tout en gardant l'historique dans d'autres. Elle exige des outils spécialisés, comme ceux de SNP ou de Natuvion, et un partenaire expérimenté.

Quels sont les prérequis pour convertir ECC 6.0 vers S/4HANA ?

La conversion fonctionne à partir de SAP ERP 6.0 sur n'importe quel enhancement package. Le système doit être en Unicode, sinon vous passez par une approche en deux étapes, et les systèmes dual-stack doivent d'abord être scindés. Les données de base clients et fournisseurs doivent être converties en business partners avant la conversion.

Que vous apprend le SAP Readiness Check ?

Il analyse votre système ECC et rend compte des simplification items qui vous concernent, de la compatibilité des add-ons, de l'impact sur le code spécifique, des volumes de données et du dimensionnement HANA. Lancez-le tôt, car les équipes découvrent régulièrement des add-ons et du code spécifique dont elles ignoraient dépendre.

Faut-il choisir RISE with SAP ou GROW with SAP pour une migration ECC ?

La plupart des clients ECC qui ont beaucoup de code spécifique et des processus complexes vont vers S/4HANA Cloud Private Edition dans le cadre de RISE with SAP, qui prend en charge la conversion du système existant. GROW with SAP utilise la Public Edition, c'est-à-dire une nouvelle mise en œuvre avec des processus standard et des extensions uniquement via des API publiées. Elle convient aux entreprises prêtes à adopter le standard SAP.