Migration d'ECC vers S/4HANA : voies, étapes et calendrier

La maintenance standard de SAP ECC prend fin le 31 décembre 2027, dans environ 15 mois. La maintenance étendue optionnelle court jusqu'à fin 2030, pour un tarif plus élevé (SAP News). Les migrations complexes dépassent facilement 18 à 24 mois dès que les vrais tests démarrent. Si vous n'avez pas encore choisi de voie, un go-live avant l'échéance est déjà peu probable.

Si vous êtes le DSI ou le responsable de programme qui doit trancher, vous avez trois voies : greenfield, brownfield ou transition sélective des données. Le travail derrière chacune suit les mêmes cinq étapes. Lancez d'abord le SAP Readiness Check, puis choisissez.

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 avait fait reconstruire à l'identique des dizaines de rapports spécifiques d'ECC. Personne ne s'était demandé s'ils servaient encore. Plus tard, la moitié n'a jamais été utilisée. La migration était techniquement propre. La valeur, non.

Les différences qui déterminent 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 distinctes pour FI, CO et la rentabilité, avec des tables de totaux	Universal Journal (table ACDOCA) comme source unique des postes d'écriture
Données de base client et fournisseur	Fiches client et fournisseur distinctes	Le partenaire commercial est obligatoire
Interface utilisateur	SAP GUI	Applications SAP Fiori, SAP GUI restant disponible en 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 : maintenance standard jusqu'à fin 2027, étendue jusqu'à fin 2030	SAP s'engage à assurer la maintenance jusqu'à fin 2040

Un client avec qui j'ai travaillé se demandait sans cesse pourquoi ses jobs batch spécifiques ne fonctionnaient plus après la conversion. Leur logique reposait sur des structures de tables ECC que S/4HANA avait modifiées. La migration était terminée. 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 décisions de conception dont vous héritez.

Decide

Quelle voie de migration correspond à votre situation ?

Le legacy est fragmenté et vous voulez repenser les processus

→Greenfield

Les processus sont sains, ECC est stable, l'historique doit rester

→Brownfield

Plusieurs entités, réutilisation partielle et données sélectives

→Bluefield

Greenfield : repartir de zéro

Une nouvelle implémentation de S/4HANA. Aucune configuration héritée n'est reprise, les processus sont repensés par rapport au standard SAP, et seules les données nécessaires sont chargées avec le SAP S/4HANA Migration Cockpit.

À choisir quand les systèmes existants sont trop fragmentés pour être convertis proprement, ou quand l'entreprise veut repenser ses processus plutôt que les copier.

À surveiller : la charge de changement. Les utilisateurs perdent leurs habitudes de travail. J'ai vu des entreprises regretter de ne pas avoir préparé leurs utilisateurs à quel point tout paraît différent dans un système greenfield. Si la préparation à l'adoption commence à la formation, il est déjà tard.

Brownfield : conversion du système

Votre système ECC existant est converti sur place. La configuration, le code spécifique et l'historique viennent avec vous. La conversion technique passe par le Software Update Manager (SUM) avec son option de migration de base de données.

À choisir quand les processus sont matures, que l'historique des transactions compte pour la conformité et qu'aucune restructuration majeure n'est en cours.

À surveiller : la dette technique que vous emportez. La complexité héritée vous suit, sauf si vous la nettoyez délibérément pendant la conversion.

Transition sélective des données

Parfois vendue sous le nom de « bluefield ». Vous déplacez des sociétés, des unités opérationnelles ou des tranches de temps choisies, pas tout, en général avec des outils spécialisés et un partenaire qui en a l'expérience. Cela convient aux groupes constitués par fusions ou carve-outs, ou quand des années d'historique n'ont plus d'importance.

À choisir quand vous voulez la liberté de processus du greenfield avec la continuité des données du brownfield là où elle compte.

Voici comment les trois voies se comparent sur les questions que posent habituellement les conseils d'administration :

Critères	Greenfield	Brownfield	Sélective
Refonte des processus	Complète, par rapport au standard SAP	Largement conservée	Choisie par unité
Données historiques	Non reprises (ou seulement les postes ouverts et les soldes)	Entièrement reprises	Périmètre sélectionné
Délai avant le go-live	Plus long	Plus court	Selon le périmètre
Dette technique	Supprimée	Reportée	Réduite pour le périmètre migré
Impact du changement	Élevé	Plus faible	Modéré
Idéal pour	Legacy fragmenté, refonte majeure	ECC stable et bien entretenu	Fusions, carve-outs, déploiements par phases

La séquence de migration

1. 01

   Évaluer

   Lancez le SAP Readiness Check. Inventoriez le code spécifique, les add-ons et les interfaces.

2. 02

   Classer les données

   Classez les données en chaudes, tièdes et froides. Les données froides n'ont pas à être migrées.

3. 03

   Nettoyer

   Résolvez les doublons, les incohérences et les champs manquants. Toujours plus long que prévu.

4. 04

   Adapter le code

   Lancez les contrôles de l'ABAP Test Cockpit. Réduisez le code Z, ne vous contentez pas de le porter.

5. 05

   Tester et basculer

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

1. Évaluation et préparation

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

Les surprises viennent généralement 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, et la plupart sont surpris de la quantité de code inactif qui apparaît. Mieux vaut le découvrir à la semaine deux qu'au douzième mois.

Vérifiez en même temps les prérequis techniques. La conversion part de SAP ERP 6.0, quel que soit le package d'amélioration. Le système doit être en Unicode, ou vous prévoyez une conversion en deux étapes. Les systèmes dual-stack doivent d'abord être séparés. Les données de base client et fournisseur doivent être converties en partenaires commerciaux avant la conversion. Ce dernier point piège plus d'équipes que tout autre.

2. Analyse et classification des données

Mesurez vos données avant de les déplacer, et triez-les :

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

Les données froides n'ont pas besoin d'entrer dans S/4HANA. Archivez-les. Les équipes qui sautent cette étape importent dans le nouveau système un encombrement qui ralentit à la fois la migration et les performances.

3. Nettoyage et archivage des données

Cette étape dure plus longtemps que n'importe quel plan ne le prévoit. Des fiches fournisseur en double. Des unités de mesure incohérentes. Des données de base client à moitié renseignées. Ces problèmes existent dans tous les systèmes ECC, et ils passent tels quels 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. Les équipes qui sautent le nettoyage découvrent les problèmes pendant la bascule, quand il n'y a plus le temps de les corriger proprement. Mon article sur pourquoi la migration de données SAP échoue approfondit cette étape.

4. Adaptation du code spécifique

Lancez les contrôles de préparation S/4HANA de l'ABAP Test Cockpit (ATC), qui comparent votre code aux éléments de simplification de SAP. Le résultat montre ce qui demande une correction de syntaxe, ce qui demande un remplacement fonctionnel et ce qu'il faut retirer.

L'objectif est moins de code Z, pas seulement du code Z qui fonctionne. Chaque objet spécifique que vous reportez ajoute un coût à chaque mise à niveau future. Mon guide du Clean Core explique comment classer ce qui reste.

5. Tests, formation et bascule

Menez les tests par cycles : unitaires, d'intégration, tests d'acceptation utilisateur (UAT), puis au moins une répétition de bascule complète. Mettez dans l'UAT à la fois des utilisateurs avancés et des utilisateurs occasionnels. Ils ne trouvent pas les mêmes problèmes.

La répétition n'est pas facultative. Elle révèle les décalages de calendrier, les validations manquantes et les défaillances d'interfaces qui n'apparaissent que lorsque toute la séquence tourne. Les équipes qui la sautent rencontrent ces problèmes le week-end du go-live.

Les outils SAP que je m'attends à trouver dans tout plan de migration :

Outil	Ce qu'il fait	Quand l'utiliser
SAP Readiness Check	Éléments de simplification, add-ons, code spécifique, dimensionnement	Avant de choisir la voie
ABAP Test Cockpit (ATC)	Repère le code spécifique qui va casser	Adaptation du code spécifique
SAP Signavio	Montre comment les processus tournent réellement, et non comment ils ont été documentés	Avant le gel de la conception
SAP LeanIX	Cartographie les applications et les interfaces	Conception de l'intégration
Software Update Manager (SUM)	Exécute la conversion technique	Conversion brownfield
SAP S/4HANA Migration Cockpit	Charge les données de base et les données transactionnelles	Migration de données greenfield

Pour SAP ERP 6.0 avec les packages d'amélioration 6 à 8, la maintenance standard prend fin le 31 décembre 2027. La maintenance étendue optionnelle court jusqu'au 31 décembre 2030, avec une majoration de deux points sur la base de maintenance. Les packages d'amélioration antérieurs ont quitté la maintenance standard fin 2025.

Au-delà de 2030, il n'existe qu'une voie étroite. L'option de transition de SAP ERP, private edition de SAP couvre 2031 à 2033. Elle ne concerne que les grands systèmes déplacés vers SAP ERP, private edition sur SAP HANA avant fin 2030, et seulement avec le plan max success de SAP. Considérez-la comme une exception, pas comme un plan.

Sur la durée, les migrations complètes de systèmes complexes peuvent dépasser 18 à 24 mois dès que les vrais tests démarrent. Pour les entreprises de taille moyenne à grande, 12 à 18 mois ou plus est réaliste pour une conversion bien préparée. Un grand programme greenfield sur plusieurs entités peut durer 24 à 36 mois.

1. 2027Fin de la maintenance standard d'ECC31 décembre, pour SAP ERP 6.0 EHP 6 à 8
2. 2028Go-live probable si vous démarrez maintenant18 à 24 mois dès que les vrais tests démarrent
3. 2030Fin de la maintenance étendueOptionnelle, avec une majoration de deux points
4. 2033Fin de l'option de transitionPrivate edition, grands systèmes uniquement

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

Le calcul est donc simple. Si vous lancez aujourd'hui une évaluation complexe, le go-live tombe en 2028. Prévoyez un budget pour la maintenance étendue, et profitez de ce temps pour nettoyer les données et retirer du code spécifique plutôt que d'attendre. Pour tester vos options, essayez mon évaluation de migration.

Quelle est la différence entre une migration greenfield et brownfield d'ECC vers S/4HANA ?

Le greenfield est une nouvelle implémentation : aucune configuration ni aucun code spécifique hérité n'est repris, les processus sont conçus par rapport au standard SAP et seules les données nécessaires sont chargées. Le brownfield convertit votre système ECC existant, en conservant la configuration, le code spécifique et l'historique. Il est plus rapide et moins perturbateur, mais la dette technique vient avec. La transition sélective des données se situe entre les deux.

Quelle est l'échéance de migration de SAP ECC vers S/4HANA ?

Pour SAP ERP 6.0 avec les packages d'amélioration 6 à 8, la maintenance standard prend fin le 31 décembre 2027. La maintenance étendue optionnelle court jusqu'au 31 décembre 2030, avec une majoration de deux points sur la base de maintenance. Une option de transition pour 2031 à 2033 n'existe que pour les grands systèmes déplacés vers SAP ERP, private edition sur SAP HANA avant fin 2030.

Que vous apprend le SAP Readiness Check ?

Il analyse votre système ECC et rend compte des éléments de simplification qui touchent votre configuration, de la compatibilité des add-ons, de l'impact sur le code spécifique, des volumes de données et du dimensionnement HANA. Le lancer tôt change la discussion sur le périmètre, car les équipes découvrent régulièrement des add-ons et du code spécifique dont elles ignoraient dépendre.

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

Une conversion bien préparée, pour une entreprise de taille moyenne à grande, dure souvent 12 à 18 mois ou plus. Les programmes complexes à plusieurs entités peuvent dépasser 18 à 24 mois dès que les vrais tests démarrent, et les grands programmes greenfield 24 à 36 mois. Le nettoyage des données est la première cause de glissement du calendrier.

Qu'est-ce que l'Universal Journal (ACDOCA) et pourquoi compte-t-il pour la migration ?

L'Universal Journal est la table unique des postes d'écriture, ACDOCA, qui regroupe les données de comptabilité financière, de contrôle de gestion et de rentabilité qu'ECC conservait dans des tables séparées. Le code spécifique et les rapports qui lisent les anciennes structures, comme COEP ou les tables de rentabilité, doivent être revus. Certains demandent de petits ajustements ; d'autres une refonte.

Quels sont les prérequis techniques pour convertir ECC en S/4HANA ?

La conversion part de SAP ERP 6.0, quel que soit le package d'amélioration. Le système doit être en Unicode, ou vous procédez en deux étapes. Les systèmes dual-stack doivent d'abord être séparés. Les données de base client et fournisseur doivent être converties en partenaires commerciaux. Lancez le SAP Readiness Check et les contrôles ATC du code spécifique avant de vous engager sur des dates.

Dois-je choisir RISE with SAP ou GROW with SAP pour une migration d'ECC ?

La plupart des clients ECC qui ont beaucoup de code spécifique et des processus complexes passent à S/4HANA Cloud Private Edition avec RISE with SAP, qui prend en charge la conversion du système existant. GROW with SAP repose sur la Public Edition, qui est une nouvelle implémentation avec des processus standard et uniquement des extensions par API publiées. Elle convient aux entreprises prêtes à adopter le standard de SAP.