Selective Data Transition (SDT) : qu’advient-il des systèmes legacy SAP après la migration vers S/4HANA ?

Auteur : équipe de contenu de TJC Group

Vous avez donc choisi la Selective Data Transition (SDT) pour votre migration vers S/4HANA et sélectionné les informations à transférer. Mais qu’advient-il des données et des systèmes legacy restants ? Plusieurs options s’offrent à vous : maintenir le système SAP ECC en service, geler le système dans un environnement virtuel, extraire toutes les données pour les stocker dans des référentiels externes, ou décommissionner le système legacy.

Cet article explore toutes les options de gestion des systèmes SAP ECC legacy après une migration SDT, expliquant pourquoi le décommissionnement du système legacy doit être envisagé dès le début du programme S/4HANA, et non après le passage en production.

Introduction : la migration Selective Data Transition (SDT) en quelques mots

La Selective Data Transition se situe entre une conversion de système et une implémentation S/4HANA entièrement nouvelle. Elle permet aux organisations de préserver ce qui fonctionne, d’introduire des changements ciblés, de consolider si nécessaire et de décider quelles données et informations historiques elles souhaitent transférer.

Une décision clé n’est donc pas seulement « Quelle technologie utiliser ? », mais « Quel niveau de changement est nécessaire pour générer de la valeur métier à partir du passage à S/4HANA ? »

Du point de vue de la gestion des données, les organisations peuvent sélectionner les données de base pertinentes, les transactions ouvertes et les informations historiques qu’elles souhaitent conserver, plutôt que de déplacer automatiquement l’intégralité de la base de données ECC.

En termes simples, un projet SDT suit normalement ces phases :

• Créer une copie shell d’ECC.
• Déplacer ou mettre à niveau le shell vers l’environnement S/4HANA souhaité.
• Implémenter les changements ciblés requis par le métier.
• Migrer et convertir les données requises.

Le système SAP ECC de production peut rester intact pendant qu’une grande partie de cette préparation se déroule en parallèle.

En général, la SDT convient mieux aux organisations souhaitant introduire des changements ciblés plutôt que de réimaginer complètement de vastes pans de l’entreprise. Si la transformation est généralisée, une approche Greenfield peut être plus appropriée.

Il existe différentes manières d’exécuter un programme SDT, notamment des approches « lean », complètes ou hybrides. Cependant, quel que soit le chemin choisi, une question cruciale demeure : qu’advient-il des informations et des systèmes qui ne sont pas transférés ?

Pour en savoir plus sur les parcours de migration S/4HANA, téléchargez cet ebook rédigé en collaboration avec les experts en migration de XMATERIA

Pourquoi la SDT crée un défi pour les données legacy

L’un des avantages de la Selective Data Transition est que les organisations n’ont pas à transférer toutes leurs données ECC historiques vers le nouvel environnement S/4HANA.

Les périodes fiscales anciennes, les unités organisationnelles inactives, les codes de société redondants ou les transactions historiques n’ont pas forcément besoin d’occuper de l’espace dans le nouveau système opérationnel.

Cependant, réduire l’empreinte de la migration ne résout qu’une partie du problème. Les données historiques peuvent rester nécessaires pour :

• des fins fiscales et d’audit ;
• des exigences réglementaires et juridiques ;
• le reporting historique ;
• des enquêtes ou litiges ;
• des obligations de confidentialité et de conservation des données ;
• des demandes métier occasionnelles.

Les organisations doivent donc prendre deux décisions liées lors d’un programme SDT :

• Qu’est-ce qui doit être transféré vers S/4HANA ?
• Qu’advient-il des informations qui restent ?

Idéalement, ces décisions devraient être prises conjointement.

L’archivage et la suppression des données font partie de la réponse, mais pas en totalité

Il convient de noter que l’archivage des données SAP et la suppression des données répondent à une partie de ce défi. L’archivage déplace les informations inactives ou rarement consultées hors de la base de données active tout en préservant leur accès, ce qui peut réduire le volume à traiter lors de la migration. La suppression élimine définitivement les informations n’ayant plus de valeur légale ou métier, tout en respectant les règles de conservation et de confidentialité.

Aucune de ces approches ne résout toutefois totalement le sort du système ECC legacy lui-même après la migration. Même après avoir supprimé les données éligibles et archivé les informations dormantes, les organisations peuvent conserver des années de dossiers historiques liés à l’environnement ECC. Si ces informations doivent rester disponibles, éteindre le système legacy n’est pas une option. Parallèlement, maintenir l’application legacy en service uniquement pour accéder aux archives génère des coûts importants et des risques en matière de sécurité et de conformité.

Si vous déterminez encore quelles informations appartiennent à S/4HANA, notre article « SAP ECC vers S/4HANA : quelles données migrer ? » fournit un cadre détaillé pour décider ce qui doit être migré, archivé, supprimé ou conservé hors de l’environnement S/4HANA actif.

Qu’advient-il du système ECC legacy après la migration SDT ?

Une fois que l’organisation a décidé ce qui sera migré vers S/4HANA, elle a besoin d’une stratégie pour le système legacy et les données historiques qui y subsistent.

Globalement, quatre grandes possibilités s’offrent à elle.

1. Maintenir ECC en mode lecture seule

Les données historiques restent accessibles, mais les coûts liés au maintien opérationnel du système perdurent. Les dépenses d’infrastructure, de maintenance, de licences et de support spécialisé peuvent s’accumuler même après qu’ECC a cessé d’être le système métier principal.

Ces coûts peuvent être substantiels. Par exemple, une étude Forrester a modélisé une grande organisation mondiale avec environ 7 millions de dollars de coûts annuels d’infrastructure et de maintenance pour son environnement SAP ECC legacy sur site. Pour un aperçu plus approfondi, consultez notre article sur les coûts cachés des systèmes legacy.

Ces coûts pourraient devenir encore plus difficiles à justifier alors qu’ECC atteint la fin de la maintenance standard. La maintenance standard de SAP pour Business Suite 7 court jusqu’à fin 2027, avec une maintenance étendue optionnelle disponible ensuite moyennant un surcoût. Le coût réel variera considérablement selon la taille de l’organisation, son parc SAP, son infrastructure et son modèle de licence.

2. Préserver ou geler ECC dans un environnement virtuel

Geler ECC dans un environnement virtuel peut sembler rentable à court terme, surtout si l’accès est peu fréquent. Cependant, cela peut créer des défis au fil du temps.

Démarrer l’environnement chaque fois qu’une information historique est requise peut être chronophage. Un environnement vieillissant peut également devenir plus difficile à maintenir et à sécuriser.

L’accès peut devenir particulièrement problématique si les spécialistes SAP ou IT qui maintenaient le système legacy quittent l’organisation. Avec le temps, les connaissances nécessaires pour naviguer dans l’ancien environnement et extraire les informations peuvent disparaître.

3. Extraire les données et documents vers des archives externes ou fiscales

Une approche consiste à extraire les données et documents historiques d’ECC sous forme de fichiers plats (format AIS par exemple) et à les stocker dans des référentiels externes. Bien que cela puisse satisfaire à certaines exigences de conservation, l’accessibilité reste une limite majeure.

Si un utilisateur métier a besoin ultérieurement d’informations historiques pour un audit ou un reporting, interpréter des extraits techniques peut s’avérer extrêmement difficile sans support IT dédié. En pratique, un outil de visualisation ou d’audit sera nécessaire pour lire et donner du sens à ces données.

Par exemple, une application de système legacy telle qu’ELSA de TJC Group offre un accès direct aux données legacy via un tableau de bord intuitif, permettant aux utilisateurs métier de générer des rapports dynamiques sans intervention de l’informatique.

Considérez ce scénario : votre organisation a importé quatre ans de données legacy dans S/4HANA. Un utilisateur a besoin de données datant d’il y a cinq ans, stockées uniquement sous forme de fichier plat. Pour travailler avec ces informations, il aura besoin d’un outil dédié pour visualiser les données, ce qui est précisément le rôle d’une application comme ELSA.

La question n’est donc pas seulement de savoir si l’information a été préservée, mais aussi avec quelle facilité elle peut être retrouvée et comprise des années après son archivage.

4. Décommissionner SAP ECC tout en conservant l’accès aux informations historiques

Le décommissionnement de système adopte une approche différente. Au lieu de préserver toute l’application legacy, les organisations retirent l’application obsolète tout en préservant les informations historiques ailleurs.

Cela permet de séparer deux éléments souvent confondus : l’application legacy et les informations legacy qu’elle contient.

Le système lui-même peut ne plus être requis pour l’activité quotidienne, tandis que ses données historiques et rapports peuvent conserver leur valeur pendant de nombreuses années.

📖 Pour une vue d’ensemble du décommissionnement de systèmes legacy dans le contexte de S/4HANA, consultez notre article : Tout savoir sur le décommissionnement de systèmes legacy lors de la migration S/4HANA.

Pourquoi le décommissionnement doit être planifié dès le premier jour

Un projet de décommissionnement de système legacy est souvent traité comme un sujet à aborder après la fin de la migration S/4HANA.

Cette approche peut engendrer un travail inutile.

Une fois S/4HANA en production, l’équipe projet se concentre sur la stabilisation. Lancer un autre projet à ce stade pour déterminer le sort d’ECC revient à rouvrir les mêmes questions :

• De quelles informations avons-nous encore besoin ?
• Qu’est-ce qui peut être supprimé ?
• Qu’est-ce qui doit être conservé ?
• Qui a besoin d’un accès ?
• Comment les informations historiques doivent-elles être extraites ?
• Quand l’ancienne infrastructure peut-elle enfin être éteinte ?

Pour cette raison, le décommissionnement est mieux envisagé dès le début de la transformation S/4HANA. Lorsque les organisations analysent quelles données seront transférées vers S/4HANA, elles devraient également planifier le sort des données restantes. Cela crée une stratégie de données plus holistique et évite d’ajouter un processus décisionnel majeur à la fin du projet de migration.

Cela peut aussi s’étendre au-delà du système SAP ECC principal. Les organisations peuvent avoir des applications satellites ou d’autres systèmes legacy connectés à ECC qui pourraient être retirés dans le cadre de cette même transformation.

Planifier ensemble la migration SDT et le décommissionnement

Une stratégie SDT et une stratégie de système legacy répondent à des questions différentes, mais elles doivent être planifiées en tandem.

Questions sur la migration SDT	Questions sur le décommissionnement legacy
Quelles périodes historiques et quels jeux de données inclure dans la migration S/4HANA ?	Quelles informations SAP historiques doivent rester disponibles après le retrait d’ECC ?
Quel doit être le périmètre de la migration SDT ?	Combien de temps les informations legacy doivent-elles être conservées ?
Quels processus métier et unités organisationnelles doivent être transférés ?	Quelles informations legacy pourront éventuellement être supprimées ?
Quelles exigences métier, de reporting et de conformité doivent façonner la conception SDT ?	Quelles exigences fiscales, d’audit, juridiques et de confidentialité s’appliquent aux données legacy conservées ?
Comment les données sélectionnées seront-elles migrées et validées ?	Comment les utilisateurs accéderont-ils aux informations SAP historiques après le décommissionnement ?
Quand l’environnement S/4HANA est-il prêt pour le passage en production ?	Quand l’application et l’infrastructure legacy peuvent-elles être éteintes en toute sécurité ?

Réfléchir tôt à ces deux flux de travail aide les organisations à éviter de traiter les données legacy comme une conséquence non résolue du projet S/4HANA.

Comment préserver l’accès aux données historiques après le retrait de SAP ECC

L’objectif n’est pas simplement de préserver les données legacy. Il est de s’assurer que les informations créées il y a des années dans un autre système ERP soient facilement accessibles aujourd’hui.

Prenons un exemple simple. Un auditeur demande une facture d’il y a X années. Cette facture n’a pas été migrée vers S/4HANA. Que se passe-t-il ensuite ? Assurez-vous de disposer d’une application de système legacy offrant un accès sécurisé aux données historiques.

Lorsque les informations historiques sont dispersées dans plusieurs environnements legacy, trouver le dossier requis peut devenir difficile et chronophage.

Le défi peut s’accentuer avec le temps, à mesure que les spécialistes SAP quittent l’organisation et que la connaissance de l’extraction des données des anciens systèmes se perd.

C’est là qu’un accès centralisé aux données legacy devient précieux.

Au lieu d’obliger les utilisateurs à retourner dans chaque système legacy, l’organisation peut préserver les informations requises dans un environnement conçu spécifiquement pour l’accès historique.

La clé est de planifier l’accès aux données non migrées au moment de décider ce qui sera transféré vers S/4HANA.

Comment ELSA offre un accès centralisé aux données historiques

Un environnement dédié aux données legacy est un moyen de séparer l’accès aux données historiques de l’infrastructure legacy d’origine.

L’application Enterprise Legacy System Application (ELSA) de TJC Group a été développée à cette fin.

ELSA offre un accès centralisé aux données, documents, rapports et transactions historiques après le retrait du système d’origine. Les utilisateurs accèdent aux informations de plusieurs systèmes décommissionnés via un environnement unique, avec des contrôles de confidentialité appliqués.

L’objectif n’est pas de reproduire indéfiniment le système ECC d’origine, mais de préserver l’accès aux informations de valeur sans obliger les utilisateurs à naviguer dans l’application legacy elle-même.

Cela est particulièrement utile pour les utilisateurs de la finance, de la fiscalité et de l’audit qui peuvent avoir besoin de récupérer des informations des années après la migration.

Le processus de décommissionnement avec ELSA

Le processus de décommissionnement d’un système legacy avec ELSA comprend quatre étapes clés :

• Extraire l’intégralité de la base de données du système legacy. Cela couvre 100 % des informations, y compris les tables, documents, pièces jointes et rapports. Rien n’est laissé de côté.
• Charger les informations extraites dans le stockage de votre choix. Choisissez une base de données MySQL hébergée sur AWS, Azure, Oracle ou sur site, ainsi qu’un stockage de fichiers ou blob chez un hyperscaler.
• Charger les données pertinentes dans ELSA. Vous pouvez choisir de ne charger que les données nécessaires immédiatement. Si des données plus anciennes sont requises plus tard, elles peuvent être chargées à la demande.
• Accéder aux données historiques via l’espace de travail ELSA. Les utilisateurs finaux visualisent tous les systèmes décommissionnés (SAP et non-SAP) via le Legacy Systems Directory, sans avoir à se connecter séparément à chaque système.

Figure 1. Le processus de décommissionnement de système avec ELSA

Étude de cas réelle sur le décommissionnement de systèmes legacy

Un client de TJC Group en fournit un exemple concret. Ce leader mondial de la conception et de la fabrication de solutions innovantes pour plafonds commerciaux et systèmes muraux a utilisé ELSA dans le cadre de sa stratégie de retrait de systèmes legacy après sa migration S/4HANA.

En retirant l’environnement SAP ECC legacy tout en conservant l’accès aux informations historiques, l’organisation a évité plus de 250 000 $ par an en coûts de licence et de maintenance SAP et Oracle.

Conclusion et points clés à retenir

La Selective Data Transition ne consiste pas seulement à déplacer une portion de données SAP ECC vers S/4HANA. Il s’agit de décider où introduire le changement, où préserver l’investissement SAP précédent et quelles informations doivent réellement faire partie du futur environnement opérationnel.

Mais décider de ce qui est transféré n’est que la moitié de la stratégie de données. Les informations laissées de côté ne peuvent être ignorées. Certains dossiers seront archivés, d’autres supprimés, tandis que d’autres doivent rester accessibles pour des raisons fiscales, d’audit ou juridiques.

Maintenir ECC en service ou le geler peut offrir un accès à court terme, mais les défis de maintenance et de sécurité perdurent. Retirer le système legacy avec une application dédiée, telle qu’ELSA, est la voie la plus sûre pour garantir un accès conforme aux données legacy.

Enfin, le décommissionnement du système legacy doit être planifié dès le début d’un programme SDT. En définissant les deux stratégies ensemble, les organisations transfèrent les bonnes informations vers S/4HANA tout en établissant un chemin clair vers le retrait de l’infrastructure legacy.

TJC Group accompagne les organisations tout au long de ce cycle, de l’évaluation des volumes de données SAP à la planification de l’accès aux données legacy et au retrait des systèmes SAP ECC. Lorsqu’un environnement legacy n’est plus requis, ELSA offre un moyen contrôlé de préserver l’accès aux informations essentielles.