Migration S/4HANA : calendrier et plan de projet selon la voie

D'après mon expérience, une migration S/4HANA depuis SAP ECC prend 12 à 18 mois pour une conversion brownfield et 18 à 24 mois pour une mise en œuvre greenfield. Une selective data transition prend 12 à 18 mois. Le plan de projet suit les six phases de SAP Activate, et la phase qui dépasse le plus souvent est celle du code spécifique.

En bref : commencez le plan par le SAP Readiness Check et réservez 30 à 40 % de l'effort aux données. Sur un brownfield, prévoyez trois conversions à blanc et attendez-vous à un arrêt de bascule qui va d'un week-end à une semaine.

Cet article détaille le calendrier et la planification derrière mon guide de migration d'ECC vers S/4HANA, qui couvre les voies et les échéances d'ECC. Si vous mettez en œuvre SAP pour la première fois au lieu de quitter ECC, mon guide du calendrier de mise en œuvre SAP couvre ce cas, avec la durée des phases.

C'est la voie qui fixe la durée. 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, et sélective quand les processus de certains domaines doivent être redéfinis.

Voici la durée de chaque voie dans les programmes que j'ai vus, et ce qui l'allonge le plus souvent :

Voie	Durée typique	Autour de quoi le plan est construit	Ce qui l'allonge le plus souvent
Brownfield (conversion de système)	12 à 18 mois	Conversion du système ECC existant avec le Software Update Manager, puis conversions de test répétées	L'adaptation du code spécifique et la conversion vers le partenaire commercial (business partner)
Greenfield (nouvelle mise en œuvre)	18 à 24 mois	Conception Fit-to-Standard, réalisation et cycles répétés de chargement des données	Des ateliers Explore qui se transforment en longues listes d'exigences, et le nettoyage des données
Selective data transition	12 à 18 mois	Accord sur les sociétés, les entités et l'historique qui migrent, puis outillage spécialisé	Le périmètre des données et la dépendance envers des partenaires spécialisés

Le calendrier compte autant que la voie. Pour ECC sur les enhancement packages 6 à 8, la maintenance standard prend fin le 31 décembre 2027 (SAP News). Un brownfield lancé ce mois-ci passe en production entre octobre 2027 et avril 2028, et un greenfield lancé maintenant arrive en 2028.

La plupart des plans écrits aujourd'hui doivent donc prévoir de la maintenance étendue dans le budget. Inscrivez-la dès le départ, pas comme une surprise la deuxième année.

RISE with SAP est une offre commerciale, pas une voie. Un brownfield ou une migration sélective sous RISE aboutit sur SAP Cloud ERP Private, le nom actuel utilisé par SAP pour ce que beaucoup recherchent encore sous le nom de S/4HANA Cloud Private Edition. Les 6 à 9 mois que j'annonce pour GROW with SAP et les 9 à 18 mois pour RISE concernent de nouvelles mises en œuvre, pas des migrations depuis ECC.

SAP Activate est la méthode de livraison de SAP pour S/4HANA. Elle comporte six phases : Discover, Prepare, Explore, Realize, Deploy et Run (SAP Activate).

Une migration utilise les mêmes phases. Ce qui change, c'est le travail à l'intérieur de chacune.

Le plan de projet de migration

1. 01

   Discover

   Readiness Check, choix de la voie et business case.

2. 02

   Prepare

   Plan, gouvernance, équipe et premier sandbox.

3. 03

   Explore

   Fit-to-Standard ou conception des écarts, liste WRICEF validée.

4. 04

   Realize

   Réalisation, code spécifique, chargements de données, conversions de test.

5. 05

   Deploy

   Répétition générale, bascule et go-live.

6. 06

   Run

   Hypercare, stabilisation et décommissionnement d'ECC.

Voici ce que contient chaque phase lors d'une migration, et où les voies diffèrent :

Phase	Ce qui se passe lors d'une migration	En quoi les voies diffèrent
Discover	SAP Readiness Check, choix de la voie, business case, première vue du code spécifique et des données	La voie sélective a besoin ici d'un premier périmètre de données
Prepare	Plan, gouvernance, équipe, responsabilité des données, sandbox	Le brownfield fait une première conversion en sandbox ; le greenfield met en place le système et le calendrier des ateliers
Explore	Ateliers Fit-to-Standard ou conception des écarts, liste WRICEF validée, mapping des données	Le greenfield passe ici le plus de temps ; le brownfield traite les simplification items qui s'appliquent
Realize	Réalisation, adaptation du code spécifique, cycles de chargement, campagnes de test	Le brownfield enchaîne les conversions à blanc ; le greenfield enchaîne les cycles de chargement, en général avec le Migration Cockpit
Deploy	Répétition générale, bascule, go-live	La fenêtre d'arrêt dépend de la voie, du volume de données et de l'approche
Run	Hypercare, stabilisation	Décommissionner ECC et archiver ce que vous avez conservé

WRICEF désigne les workflows, états (reports), interfaces, conversions, extensions (enhancements) et formulaires. C'est la liste de tout ce que vous développez au-delà du standard SAP, et c'est le chiffre à surveiller.

Sur les 21 programmes SAP que j'ai dirigés ou redressés, la plus grande erreur est de ne pas planifier correctement au début de la mise en œuvre. Dans Prepare, décidez qui est responsable du nettoyage des données, quel code spécifique est retiré et quand a lieu chaque conversion de test et chaque répétition. Ces dates deviennent la colonne vertébrale du plan.

Brownfield : planifier autour des conversions de test

Un plan brownfield est construit autour du cycle de conversion. Le Software Update Manager convertit le système, et chaque essai vous dit combien de temps prendra la vraie conversion et ce qui casse.

Sur un brownfield, je prévois trois conversions à blanc avant la bascule. Chacune doit tourner sur une copie récente de la production, pour que les durées aient un sens. La dernière doit se comporter comme le go-live : même séquence, mêmes personnes, mêmes contrôles.

Le plan de SAP pour son approche downtime-optimized est similaire. Il prévoit un essai en sandbox, un essai en assurance qualité, une vérification du chargement sur un clone et une répétition générale (SAP Learning). SAP précise que moins d'essais sont techniquement possibles, mais qu'ils augmentent le risque.

Greenfield : planifier autour de la conception et des chargements de données

En greenfield, le temps part dans Explore. Les ateliers Fit-to-Standard décident quelle part du standard SAP vous adoptez, et chaque écart devient un objet WRICEF à développer, tester et maintenir.

Les données migrent par cycles de chargement, en général avec le SAP S/4HANA Migration Cockpit. Prévoyez plusieurs cycles de chargement complets, chacun suivi d'un rapprochement signé par le métier. Mon guide pas à pas du Migration Cockpit couvre les tables de staging, les objets de migration et le processus de chargement.

Sélective : planifier autour du périmètre des données

Un plan sélectif commence par un périmètre de données. Quelles sociétés, quelles unités et combien d'années d'historique migrent, et quels processus sont repensés.

Ce périmètre détermine les outils, le partenaire spécialisé et les cycles de test. Changez-le tard et le calendrier bouge avec lui.

D'après mon expérience, le code spécifique est la phase qui dépasse le plus souvent. C'est aussi le coût caché le plus oublié d'une migration, que mon guide du coût d'une migration S/4HANA couvre.

Voici les points que je surveillerais, dans l'ordre :

1. Le code spécifique. Les équipes l'évaluent à partir d'un rapport, puis découvrent sa vraie taille quand la remédiation commence. Sur un programme, l'analyse avec smartShift a réduit les objets spécifiques de 18 000 à 3 200. Retirez d'abord, adaptez ensuite.
2. Les objets spécifiques que l'évaluation a manqués. D'après mon expérience, les objets spécifiques que le SAP Readiness Check ne voit pas sont ceux qui font mal plus tard. Lisez mon guide du SAP Readiness Check avant de traiter son résultat comme votre périmètre.
3. Les données. La migration des données représente 30 à 40 % de l'effort. Quand le nettoyage n'a pas de responsable, il commence tard, puis comprime les cycles de test. Mon article sur les raisons de l'échec des migrations de données SAP va plus loin.
4. Explore. Les budgets prennent un coup dans Explore, à mesure que la liste WRICEF s'allonge. Quand le prestataire contrôle le périmètre, personne de son côté n'a de raison d'en freiner la croissance.
5. Les répétitions supprimées pour gagner du temps. Une répétition abandonnée pour tenir la date coûte en général plus de temps le week-end du go-live qu'elle n'en a fait gagner.

Mon avis : verrouillez la date de go-live à la fin d'Explore, quand la liste WRICEF et le périmètre du code spécifique sont connus. Une date fixée au lancement est une supposition accompagnée d'une présentation au conseil d'administration.

Les arrêts de bascule que j'ai vus vont d'un week-end à une semaine. Le volume de données, l'approche de conversion, le nombre d'entités et d'interfaces qui démarrent ensemble et la rapidité avec laquelle le métier peut valider la font tous varier.

Pour un brownfield, SAP propose une approche de conversion downtime-optimized dans le Software Update Manager. Elle déplace une partie de la conversion et de la migration des données vers la période d'activité, pendant que la production continue de tourner.

Ce temps n'est pas gratuit. SAP mentionne des essais supplémentaires, une planification plus complexe, des gels du paramétrage et des développements avant l'arrêt, et un expert formé à l'approche.

Mettez-vous donc d'accord sur l'arrêt que le métier peut accepter avant de choisir l'approche technique. Prouvez-le ensuite lors des conversions à blanc, pas le week-end du go-live. Gardez la bascule à l'écart de la clôture mensuelle et des pics d'activité.

Un plan ne vaut que par les hypothèses qui le sous-tendent. Voici les questions que je poserais avant toute signature :

1. Quelle voie le plan suppose-t-il, et qu'est-ce qui, dans nos résultats du Readiness Check, la justifie ?
2. Combien d'objets spécifiques restent dans le périmètre après l'analyse d'utilisation, et combien seront retirés ?
3. Qui est responsable du nettoyage des données, et dans quelle phase commence-t-il ?
4. Combien de conversions à blanc ou de cycles de chargement sont prévus, et sur quelles données ?
5. Quel arrêt le plan suppose-t-il, et quel essai le prouve ?
6. Quand la date est-elle verrouillée, et que devient-elle si la liste WRICEF s'allonge dans Explore ?

Demandez au partenaire des références de programmes comparables au vôtre et sa conception générale. Si les réponses sont génériques et pas propres à votre entreprise, considérez-le comme un signal d'alerte.

Lancez le SAP Readiness Check ce trimestre. Présentez les constats sur le code spécifique et les données au CFO et au directeur de programme avant que quiconque ne s'engage sur une date de go-live.

Construisez ensuite le plan à rebours à partir de la fenêtre de bascule que vous pouvez accepter, avec trois conversions à blanc sur un brownfield ou les cycles de chargement dont votre voie a besoin. Pour tester d'abord la voie elle-même, essayez mon évaluation de migration greenfield ou brownfield.

J'aide les organisations à construire et à mettre à l'épreuve des plans de migration comme celui-ci. Si vous voulez un avis indépendant, contactez-moi.

Combien de temps dure une migration S/4HANA ?

D'après mon expérience, une conversion brownfield depuis ECC prend 12 à 18 mois, une mise en œuvre greenfield 18 à 24 mois et une selective data transition 12 à 18 mois. Le code spécifique est la phase qui dépasse le plus souvent, et la migration des données représente 30 à 40 % de l'effort.

Quelles sont les phases d'un plan de projet de migration S/4HANA ?

Le plan suit SAP Activate : Discover, Prepare, Explore, Realize, Deploy et Run. Lors d'une migration, Discover contient le Readiness Check et le choix de la voie, Realize contient le code spécifique, les chargements de données et les conversions de test, et Deploy contient la répétition générale et la bascule.

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

Sur un brownfield, je prévois trois conversions à blanc avant la bascule. Pour son approche downtime-optimized, SAP prévoit un essai en sandbox, un essai en assurance qualité, une vérification du chargement et une répétition générale, et indique que moins d'essais augmentent le risque.

Combien de temps dure l'arrêt de bascule vers S/4HANA ?

Les arrêts de bascule que j'ai vus vont d'un week-end à une semaine. Ils dépendent du volume de données, de l'approche de conversion et du nombre d'entités et d'interfaces qui démarrent ensemble. La conversion downtime-optimized de SAP déplace une partie du travail vers la période d'activité, mais demande plus d'essais et de planification.

Pouvons-nous terminer une migration S/4HANA avant la fin du support d'ECC en 2027 ?

La maintenance standard d'ECC sur les enhancement packages 6 à 8 prend fin le 31 décembre 2027. Un brownfield lancé en octobre 2026 passe en production entre octobre 2027 et avril 2028, et un greenfield en 2028. La plupart des programmes qui démarrent maintenant devraient prévoir de la maintenance étendue dans leur budget.

Qu'est-ce qui retarde le plus les projets de migration S/4HANA ?

D'après mon expérience, le code spécifique dépasse le plus souvent, suivi d'un nettoyage des données qui commence tard et d'une liste WRICEF qui ne cesse de s'allonger dans Explore. Ne pas planifier correctement au début du programme est la racine de la plupart de ces problèmes.