Stratégie de migration des données vers SAP S/4HANA : approches de décommissionnement des systèmes existants

Découvrez comment le périmètre des données, la complexité du système et les décisions de mise hors service influencent les résultats de la migration vers SAP S/4HANA et l'architecture des données à long terme.

La transformation vers SAP S/4HANA est souvent présentée comme une simple évolution du système. Dans la pratique, cette vision est réductrice.

Il s’agit en réalité de repenser en profondeur la manière dont les données sont structurées, stockées et exploitées à l’échelle de l’entreprise. Et même après la mise en production du nouveau système, une question essentielle reste souvent en suspens :

Que deviennent les données et les systèmes qui n’ont pas été repris ?

Dans de nombreux projets, SAP S/4HANA est opérationnel, les données ont été migrées et les processus métiers fonctionnent comme prévu. Pourtant, les anciens systèmes restent actifs en parallèle, non parce qu’ils ont été oubliés, mais parce que certaines dépendances subsistent. Consultation de données historiques, exigences d’audit, obligations de conservation, intégrations non encore traitées : les raisons sont rarement uniques.

À ce stade, la migration entre dans une nouvelle phase. L’enjeu ne relève plus uniquement de l’exécution technique, mais de la rationalisation de l’architecture du système d’information et du décommissionnement maîtrisé des environnements existants.

La complexité cachée des environnements existants

Avant même le lancement de la migration, les entreprises sont souvent confrontées à une réalité qu’elles sous-estiment : leur système d’information ne repose pas sur un environnement unique, mais sur un écosystème composé de multiples instances, applications et interconnexions.

Dans ce contexte, les environnements existants présentent généralement les caractéristiques suivantes :

• Plusieurs instances ERP, par exemple régionales ou propres à certaines unités opérationnelles
• Des systèmes de reporting et des entrepôts de données fonctionnant en parallèle
• Des modèles de données de référence hétérogènes ou incohérents
• Des intégrations non documentées avec des systèmes SAP et non-SAP
• Un chevauchement des responsabilités entre les différentes équipes et fonctions

En pratique, cette complexité peut entraîner plusieurs points de blocage au cours de la migration.

Il s’agit donc moins d’un problème de volume de données que d’un enjeu d’architecture d’entreprise qui se manifeste à travers le projet de migration.

L’approche de migration et son impact sur la stratégie de données

L’approche de migration est souvent présentée comme un choix entre les scénarios « Brownfield », « Greenfield » et la transition sélective des données (« Bluefield »). Dans la pratique, cette distinction ne suffit pas à elle seule à définir la stratégie à adopter. L’enjeu réside surtout dans la manière dont l’approche retenue influence trois décisions structurantes :

• Quelles données doivent être migrées ?
• Comment ces données seront-elles structurées dans le nouvel environnement ?
• Où les données historiques seront-elles conservées et selon quelles modalités pourront-elles être consultées ?

Les réponses à ces trois questions façonnent davantage l’architecture cible des données que le scénario technique de migration lui-même.

Selon l’approche retenue, plusieurs dimensions du projet peuvent être affectées.

Comme vous pouvez le constater, l’approche de migration détermine la part de l’environnement existant à transférer vers SAP S/4HANA, ainsi que le niveau de complexité à conserver en dehors du système cible.

Pour approfondir la planification de votre projet, consultez notre guide de migration de SAP ECC vers SAP S/4HANA.

Définir le périmètre des données

La migration prend tout son sens lorsqu’il s’agit de déterminer ce qui doit être transféré et ce qui peut rester en dehors du système cible. À ce stade, les équipes doivent identifier les ensembles de données indispensables à la continuité des opérations et ceux qui peuvent être archivés ou conservés dans un environnement distinct. Traiter toutes les catégories de données de la même manière crée souvent des difficultés, car chacune répond à des exigences différentes.

La complexité des données de référence

Les données de référence sont rarement homogènes. Un même fournisseur ou client peut disposer d’identifiants ou d’attributs différents selon les systèmes existants. Ces écarts doivent être harmonisés avant la migration. Cela implique notamment d’aligner les structures des partenaires commerciaux et d’identifier les doublons. Si cette étape est insuffisamment préparée, les incohérences risquent de réapparaître dans SAP S/4HANA, notamment dans le reporting ou sous la forme de doublons de partenaires commerciaux.

Traitement des transactions en cours

Les postes ouverts, notamment les créances, les dettes et les commandes clients, doivent être transférés en préservant leur intégrité financière. La difficulté tient souvent aux chaînes documentaires incomplètes, par exemple lorsqu’une commande n’est pas associée à un document de livraison. Comme ces données soutiennent les opérations quotidiennes, toute anomalie devient immédiatement visible après la mise en production.

Historique et besoins de reporting

La question n’est pas uniquement de savoir combien d’années d’historique doivent être migrées, mais surtout comment ces données seront utilisées. Il faut déterminer si les rapports doivent être produits directement dans SAP S/4HANA ou si un référentiel externe peut répondre aux besoins. De nombreuses entreprises choisissent de migrer uniquement les données récentes et d’archiver le reste. Cette approche permet de maîtriser le périmètre, à condition que les équipes Finance, Audit et Reporting s’accordent dès le départ sur les modalités d’accès aux données historiques.

Rapprochement des exercices clôturés

Les exercices clôturés soulèvent avant tout des enjeux de rapprochement. Il faut notamment déterminer si les états financiers historiques doivent pouvoir être reproduits directement dans SAP S/4HANA. Dans ce cas, la charge de migration et de validation augmente sensiblement. Des difficultés apparaissent souvent lorsque la Finance attend un reporting historique complet dans le nouveau système tandis que l’IT prévoit uniquement un accès aux archives. Ce désalignement doit être résolu suffisamment tôt pour éviter des ajustements tardifs du périmètre.

Décisions de configuration

La configuration ne se limite pas à des paramètres techniques : elle reflète aussi des choix métiers accumulés au fil du temps. Tout reprendre à l’identique peut préserver des complexités ou des contournements devenus inutiles. À l’inverse, tout repenser exige davantage d’implication des équipes métiers. L’enjeu consiste donc à trouver le bon équilibre entre rapidité de migration, simplification et qualité de la conception cible.

Le compromis entre périmètre et complexité

Un périmètre large peut sembler plus simple à court terme, car il limite les arbitrages sur les données à exclure. Il augmente toutefois le volume à traiter et les efforts de rapprochement. Un périmètre plus ciblé nécessite davantage de décisions en amont, mais permet généralement de mieux maîtriser l’environnement cible. L’objectif ne consiste donc pas seulement à transférer des données, mais à aligner le périmètre de migration sur les besoins réels de l’entreprise.

La qualité des données : un facteur déterminant pour la migration

La qualité des données est souvent traitée comme un chantier parallèle lors de la préparation de la migration. En pratique, elle conditionne directement la capacité du projet à progresser d’une étape à l’autre.

Certains problèmes constituent des points de blocage récurrents : incohérences des données de référence entre les systèmes, problèmes non résolus liés à l’intégration client-fournisseur (Customer/Vendor Integration, CVI) ou écarts entre les soldes des grands livres auxiliaires et ceux du grand livre général. Ces situations sont fréquentes dans les environnements reposant sur plusieurs systèmes sources.

La principale difficulté réside dans le moment où ces problèmes sont identifiés. Ils apparaissent souvent lors des tests d’intégration ou des opérations de rapprochement, alors que les données ont déjà été transformées et chargées. Leur résolution impose alors de revenir sur des étapes antérieures, ce qui augmente à la fois la charge de travail, les délais et les risques du projet.

Comment éviter les silos de données qui freinent progressivement votre activité

Retours d’expérience de LeverX et SAP PLM

En savoir plus

La réalité du décommissionnement des systèmes existants

Les anciens systèmes ne disparaissent pas simplement lors de la mise en production d’un nouvel environnement. Ils restent souvent indispensables pour les audits, le reporting historique ou certains contrôles opérationnels. Leur décommissionnement est rarement immédiat : il s’inscrit généralement dans une démarche progressive.

L’accès en lecture seule comme filet de sécurité

Maintenir le système existant en lecture seule constitue souvent une première étape. Les utilisateurs peuvent ainsi consulter les informations nécessaires sans risque de créer de nouvelles données ou de modifier les enregistrements existants. Cette approche permet également de préserver un environnement stable pour répondre aux exigences de conformité pendant la transition vers la nouvelle plateforme.

Séparer les données dès le début

Distinguer dès le début du programme les données actives des données historiques facilite considérablement la transition. Reporter cette décision à la fin du projet peut transformer la migration en véritable point de blocage. Définir ces catégories en amont réduit les efforts de nettoyage et de préparation ultérieurs.

Utiliser des plateformes dédiées à la conservation des données

Le transfert des données historiques vers des plateformes dédiées, telles que SAP Information Lifecycle Management, permet de réduire la dépendance aux anciens systèmes et leurs coûts de maintenance, tout en maintenant l’accès aux informations requises à des fins réglementaires ou d’audit.

SAP Information Lifecycle Management contribue également à répondre à certaines exigences du RGPD, notamment en matière de conservation et de suppression des données. Cette approche s’inscrit par ailleurs dans une stratégie SAP Clean Core, en permettant de conserver les données inactives hors du système opérationnel tout en maintenant leur gouvernance.

Chaque approche implique des arbitrages. Maintenir un système complet en fonctionnement facilite l’accès aux données, mais génère des coûts de maintenance. Externaliser les données vers une plateforme dédiée réduit cette charge, mais exige une stratégie fiable de recherche et de restitution. La réussite ne dépend donc pas uniquement de la rapidité du décommissionnement, mais aussi de la capacité à retrouver les données plusieurs années après la migration.

Les projets qui maîtrisent cet enjeu commencent généralement par une analyse détaillée du profil et de la qualité des données. Identifier et corriger les incohérences en amont évite qu’elles ne se propagent aux différents cycles de migration.

Outils et automatisation : où apportent-ils réellement de la valeur ?

Dans la plupart des projets, les outils sont introduits dès les premières phases, mais leur valeur devient pleinement visible lorsque les problèmes de données apparaissent. Ils permettent notamment de vérifier si les choix effectués en amont restent pertinents face aux données réelles.

SAP Migration Cockpit : une structure stricte, une tolérance limitée

SAP Migration Cockpit constitue généralement le point d’entrée des données préparées dans SAP S/4HANA. Il repose sur des structures d’objets prédéfinies auxquelles les données doivent se conformer.

Le processus fonctionne de manière prévisible lorsque :

• les données des partenaires commerciaux sont déjà conformes aux exigences CVI ;
• les structures des articles et des données financières respectent les exigences de SAP S/4HANA ;
• les relations entre les objets sont cohérentes.

Les difficultés apparaissent surtout lorsque les données proviennent de plusieurs systèmes utilisant des définitions divergentes ou contradictoires. L’outil peut alors rejeter certains enregistrements ou faire apparaître les incohérences, sans les résoudre.

Dans la pratique, les équipes doivent souvent retraiter les données en amont afin de les rendre compatibles avec le chargement. SAP Migration Cockpit agit donc davantage comme un point de contrôle que comme un outil de transformation des données.

SAP Data Services : mettre en évidence les divergences

SAP Data Services permet d’extraire, de consolider et de transformer des données provenant de plusieurs systèmes. Il est notamment adapté pour rapprocher plusieurs sources, appliquer des règles de transformation cohérentes à grande échelle et identifier certains problèmes de qualité des données.

Il ne peut toutefois pas résoudre à lui seul les divergences sémantiques. Lorsque deux systèmes utilisent des clés, des hiérarchies ou des définitions différentes pour un même objet, l’outil peut harmoniser les formats, mais la résolution des incohérences nécessite une décision métier.

C’est souvent à ce stade que l’ampleur des divergences entre les systèmes devient pleinement visible.

Les modèles de transformation : efficaces tant que la complexité reste maîtrisée

Les modèles permettent de standardiser les règles de mapping entre les différents cycles de migration. Ils sont particulièrement utiles pour les scénarios récurrents et les chargements de test successifs.

Ils deviennent toutefois plus difficiles à maintenir lorsque les structures diffèrent fortement entre les systèmes sources ou que les exceptions se multiplient. La logique conditionnelle peut alors devenir suffisamment complexe pour remettre en cause les gains attendus de la standardisation.

Automatisation du rapprochement : détecter rapidement les écarts

Les outils de rapprochement comparent les données source et cible afin d’identifier les écarts. Ils sont particulièrement importants pour les données financières, où toute différence doit pouvoir être expliquée.

Ils permettent notamment de vérifier :

• si les totaux concordent entre les systèmes ;
• si des enregistrements sont manquants ou dupliqués ;
• à quel stade les écarts commencent à apparaître.

Ils n’en déterminent toutefois pas automatiquement la cause. Une fois l’écart identifié, son origine doit encore être retracée à travers les différents systèmes et étapes de transformation. Dans les programmes complexes, cette analyse peut représenter une part importante de l’effort de migration, en particulier lorsque les incohérences n’ont pas été traitées suffisamment tôt.

Dans les projets visant notamment une architecture Clean Core, la chaîne d’outils suit généralement une logique structurée :

• Définition des objets dans SAP Migration Object Modeler (MOM) : définition ou extension des objets cibles, y compris l’ajout de champs personnalisés.
• Configuration de la zone de transit : SAP Migration Cockpit génère l’environnement de staging à partir des objets définis en amont.
• Extraction et transformation : SAP Data Services extrait les données des systèmes existants, les transforme, les nettoie et traite les doublons avant leur transfert vers la zone de transit.
• Validation et rapprochement : les contrôles sont réalisés dès l’arrivée des données dans la zone de transit afin de vérifier leur cohérence avant le chargement définitif.

Chaque étape dépend de la précédente. Les problèmes non résolus en amont se propagent dans la chaîne de migration et deviennent généralement plus coûteux et plus complexes à corriger.

Domaines à risque

La plupart des risques liés à la migration trouvent leur origine dans des hypothèses implicites formulées dès la phase de conception. Ils ne deviennent souvent visibles qu’au moment des tests ou de la mise en production et concernent généralement des pratiques de gestion des données antérieures au projet.

Incohérences dans les soldes historiques

Dans les environnements complexes, les données financières sont rarement parfaitement harmonisées entre les systèmes. Décalages temporels, ajustements locaux ou écarts de rapprochement peuvent créer des différences qui restent invisibles pendant des années et n’apparaissent qu’au moment de consolider et de valider les données dans SAP S/4HANA.

Elles peuvent notamment se traduire par :

• des écarts dans les soldes d’ouverture ;
• des différences entre les livres auxiliaires et le grand livre ;
• des lacunes dans le reporting historique.

Leur résolution nécessite d’analyser les systèmes sources afin d’identifier l’origine des écarts. Détectées tardivement, ces divergences peuvent fortement ralentir les dernières phases de migration.

Dépendances cachées dans les systèmes existants

Les interfaces existantes reposent souvent sur une logique spécifique ou sur des structures de tables personnalisées insuffisamment documentées. Le problème apparaît lorsque certaines interfaces recherchent des champs qui n’existent plus ou lorsque les formats de données ne correspondent plus aux attentes des systèmes en aval.

Même si la migration des données aboutit correctement, ces défaillances d’intégration peuvent perturber des processus critiques tels que la facturation ou le traitement des commandes.

Divergences de données pendant l’exploitation en parallèle

Lorsque l’ancien et le nouveau système fonctionnent simultanément, la synchronisation des données devient un enjeu majeur. Des règles insuffisamment définies peuvent entraîner :

• des transactions présentes dans un système mais absentes de l’autre ;
• des retards de réplication générant des écarts de reporting ;
• des données de référence mises à jour dans un environnement mais pas dans l’autre.

Ces divergences peuvent affecter à la fois les opérations et la fiabilité du reporting, notamment lorsque les utilisateurs travaillent sur les deux environnements en parallèle.

La réalité du rapprochement

Le rapprochement ne constitue pas une simple étape finale : il s’agit d’un processus itératif tout au long de la migration. Le défi consiste à valider de grands volumes de données selon plusieurs dimensions, au niveau des documents comme des soldes, tout en identifiant l’étape de transformation à l’origine de chaque écart.

Sous-estimer cet effort peut rapidement affecter le calendrier du projet. Ces risques sont rarement liés aux outils eux-mêmes ; ils proviennent davantage de lacunes dans la définition des relations et des règles de gestion des données.

LeverX Data Migration pour SAP S/4HANA

Les programmes SAP S/4HANA de grande ampleur cumulent souvent plusieurs enjeux : consolidation des systèmes, maîtrise du périmètre des données, gestion des dépendances existantes et exigences réglementaires. Dans ce contexte, les décisions prises dans un domaine ont généralement des répercussions sur les autres.

Consolidation de plusieurs systèmes

La consolidation constitue souvent l’un des premiers défis. Les différentes instances ERP présentent généralement des données de référence redondantes et des structures hétérogènes.

L’enjeu ne consiste pas simplement à transférer des données, mais à déterminer quelles informations feront autorité dans le futur système et à les harmoniser au sein d’un modèle cible commun.

Transition sélective des données

Une migration complète n’est pas toujours nécessaire. Certains ensembles de données peuvent être transférés vers le nouveau système tandis que d’autres restent temporairement dans l’environnement existant.

Cette coexistence impose des règles de synchronisation précises afin de préserver la cohérence des données entre les différents systèmes pendant la période de transition.

Décommissionnement progressif des systèmes

Les anciens systèmes ERP ne sont généralement pas arrêtés dès la mise en production du nouvel environnement. Les exigences d’audit, de reporting ou de conservation peuvent nécessiter leur maintien pendant une période prolongée.

Les entreprises peuvent alors conserver ces systèmes en lecture seule ou transférer les données vers des plateformes dédiées. Cette approche permet de réduire progressivement l’empreinte informatique tout en maintenant l’accès aux informations historiques nécessaires, notamment en cas d’audit fiscal ou juridique.

Harmonisation internationale

Les programmes internationaux ajoutent une dimension supplémentaire. Les structures financières et les données fiscales doivent être harmonisées entre les différents pays tout en respectant les exigences réglementaires locales.

Cela nécessite des règles de transformation adaptées afin de concilier les standards du groupe avec les obligations propres à chaque juridiction.

Gouvernance structurée et rapprochement

Le rapprochement doit être envisagé comme un processus continu. Un cadre de gouvernance clair définit les responsabilités relatives aux données, les contrôles à effectuer et les modalités de résolution des écarts.

L’application de ces principes à chaque cycle de migration contribue à garantir la fiabilité des données transférées.

Stabilisation après la mise en production

Le projet ne s’arrête pas à la mise en production. Certaines anomalies de reporting ou d’intégration n’apparaissent qu’une fois le système utilisé dans des conditions réelles.

Une collaboration étroite entre les équipes métiers et IT reste donc nécessaire pendant la phase de stabilisation afin d’identifier et de corriger rapidement les écarts.

LeverX aborde ces étapes comme les composantes d’une même stratégie de migration. Consolidation, transformation, gouvernance des données et décommissionnement sont ainsi traités de manière cohérente, plutôt que comme une succession de tâches techniques indépendantes.

L’impact réel des choix en matière de migration des données

Les effets concrets d’une stratégie de migration des données apparaissent souvent après la mise en production. C’est lorsque les utilisateurs commencent à exécuter les opérations quotidiennes et à produire les reportings de clôture que la pertinence des décisions prises en amont devient pleinement visible.

Maintenance au quotidien et performances du système

Maîtriser dès le départ le périmètre des données améliore l’exploitation du système. En réduisant les dépendances aux systèmes existants, le nouvel environnement contient moins de données redondantes, d’objets obsolètes et d’exceptions. La gestion des données de référence s’en trouve simplifiée, tout comme le recours aux traitements manuels et aux solutions de contournement.

Renforcer la confiance dans le reporting

C’est souvent dans le reporting qu’une migration bien préparée produit les bénéfices les plus visibles. L’harmonisation des données en amont réduit les besoins de rapprochement manuel et facilite l’identification des écarts résiduels. Des structures cohérentes et des référentiels clairement définis permettent également de mieux retracer l’origine des chiffres.

Des responsabilités clairement définies

Une migration structurée conduit généralement l’entreprise à clarifier les responsabilités en matière de données. Lorsque ces rôles sont définis pendant le projet, il devient plus simple de maintenir la qualité des données après la mise en production et de traiter rapidement les anomalies liées, par exemple, aux données de référence ou aux ajustements financiers.

Préparer l’évolution du système

La capacité du système à évoluer dépend aussi de ce qui n’est pas repris lors de la migration. Éliminer les configurations obsolètes et les données devenues inutiles facilite l’évolution du reporting et des processus métiers, tout en limitant la dette technique. L’entreprise dispose ainsi d’une architecture plus flexible pour répondre à ses besoins futurs.

La stratégie avant la technologie

Ces bénéfices ne découlent pas automatiquement de l’adoption de SAP S/4HANA. Ils dépendent avant tout des choix effectués concernant la sélection, la transformation et la gouvernance des données pendant la transition. Des décisions insuffisamment préparées risquent de reproduire dans le nouvel environnement les difficultés rencontrées auparavant. La réussite d’une migration repose donc autant sur la préparation et la gouvernance que sur la technologie elle-même.

Les réalités du décommissionnement des données SAP