Comment migrer ses données depuis un ERP maison vers SAP Public Cloud ?

Migrer depuis un ERP développé en interne vers SAP S/4HANA Public Cloud est fondamentalement différent d’une migration depuis SAP ECC. Il n’existe pas de chemin de conversion automatique : les données doivent être extraites du système source, transformées pour correspondre aux structures SAP, chargées via le SAP Migration Cockpit, et validées avant la bascule. C’est le chantier le plus sous-estimé de tout projet Grow with SAP, et le plus souvent la première source de dépassement de délais.

Pourquoi la migration depuis un ERP maison est un cas à part

Quand on parle de migration vers SAP S/4HANA, la plupart des ressources disponibles traitent du cas SAP ECC vers S/4HANA. Mais de nombreuses ETI arrivent sur SAP Public Cloud depuis une situation très différente : un ERP développé sur mesure, parfois depuis quinze ou vingt ans, construit en interne ou par un éditeur local, qui reflète fidèlement les processus de l’entreprise avec toutes leurs spécificités.

Depuis SAP ECC, il existe des outils de conversion système, des chemins balisés et une continuité dans le modèle de données. Depuis un ERP maison, il faut repartir de zéro sur la cartographie des données, construire des mappings sans filet, et faire cohabiter deux logiques d’organisation de l’information souvent très différentes.

Six migrations SAP sur dix dépassent leur budget et leurs délais initiaux. (Source : DavFi, 2026) Cette statistique est encore plus vraie lorsque l’organisation part d’un système non-SAP, sans passerelle technique préexistante.

Des données structurées pour un usage, pas pour une migration

Un ERP maison a été construit pour faire fonctionner l’entreprise, pas pour être migré. Les données maîtres — clients, fournisseurs, articles, centres de coûts — sont souvent dispersées dans plusieurs tables sans normalisation cohérente. Un même fournisseur peut exister en doublon sous deux identifiants différents selon qu’il a été créé par la comptabilité ou par les achats.

Les données transactionnelles sont souvent stockées dans des formats propriétaires, avec des champs libres, des codes internes non documentés, et des conventions de saisie qui varient selon les périodes et les utilisateurs. La documentation technique est rarement à jour. Les règles de gestion implicites existent dans les têtes des utilisateurs clés, pas dans une spécification.

La découverte des données cachées

L’un des moments les plus caractéristiques d’un projet de migration depuis un ERP maison est la découverte des données cachées : les données que personne ne connaissait vraiment, qui n’apparaissent pas dans les exports standards, mais qui sont utilisées dans des processus critiques.

Un exemple fréquent : un champ commentaire libre dans les commandes fournisseurs qui contient en réalité des informations structurées (numéro de contrat, code projet, référence budget) que les équipes achats saisissent manuellement depuis des années parce que l’ERP maison n’avait pas prévu de champ dédié. Ces données doivent être soit structurées dans SAP avant le go-live, soit abandonnées, soit traitées différemment. Chacune de ces options a des conséquences sur le périmètre du projet.

Les outils de migration dans SAP Public Cloud

Le SAP Migration Cockpit : l’outil central

Le SAP S/4HANA Migration Cockpit est un outil intégré conçu pour simplifier le processus de migration des données vers SAP S/4HANA. Il fournit des objets de migration prédéfinis, un mapping automatisé, et des options de personnalisation pour assurer un transfert de données précis et efficace depuis les systèmes legacy. (Source : Prometheus Group, 2025)

Le SAP Migration Cockpit est accessible via l’application Fiori ‘Migrate Your Data’. Il propose des objets de migration prédéfinis par SAP avec des templates Excel ou CSV qui définissent exactement les champs attendus et leur format. Il supporte deux approches : les Staging Tables, où les données sont stockées dans des tables temporaires alimentées via fichiers de templates, et le Direct Transfer, qui extrait directement les données depuis SAP ERP. Pour une migration depuis un ERP maison, c’est l’approche Staging Tables qui s’applique.

Le statut de LSMW en 2026

LSMW n’est pas recommandé dans S/4HANA et ne s’applique qu’à ECC ou à des objets personnalisés de petite taille. SAP DMC (Data Migration Cockpit) est l’outil privilégié pour les projets S/4HANA Cloud et les nouveaux déploiements. (Source : Ageis Technova, 2025) LSMW est encore disponible dans S/4HANA mais est déprécié — il n’est pas recommandé pour une utilisation à long terme. Si votre prestataire propose LSMW comme outil principal pour votre migration vers SAP Public Cloud, c’est un signal d’alerte.

Les limites du Migration Cockpit en Public Cloud

Dans SAP S/4HANA Cloud Public Edition, le SAP Migration Object Modeler est disponible avec des fonctionnalités limitées : pour un petit nombre d’objets de migration, vous pouvez ajouter d’autres champs qui sont déjà disponibles dans l’API de migration des données. (Source : SAP Community, 2026) Si vos données contiennent des informations qui ne correspondent à aucun champ standard SAP, vous avez deux options : les mapper sur un champ existant en acceptant un écart sémantique, ou les archiver dans un système de référence distinct.

Les cinq phases d’une migration depuis un ERP maison

Phase 1 : L’inventaire des données source

L’analyse des données peut commencer dès la phase Prepare de la méthodologie SAP Activate, car elle nécessite que vous mettiez en place vos processus. L’analyse des données constitue également une excellente étape pour identifier et analyser les objets métiers, les objets de migration de données et les systèmes sources afin de prendre des décisions critiques pour le parcours de migration. (Source : Pathlock, 2026)

En pratique, l’inventaire comprend : lister les tables de l’ERP maison et les données qu’elles contiennent, identifier les données maîtres à migrer (clients, fournisseurs, articles, comptes GL, immobilisations) et les données transactionnelles (soldes d’ouverture, commandes en cours, encours fournisseurs), et décider de l’horizon historique : migre-t-on 3 ans, 5 ans, depuis l’origine ? La réponse impacte directement le volume de travail et la durée du projet.

Phase 2 : Le mapping et la transformation

C’est la phase la plus longue et la plus critique. Elle consiste à faire correspondre chaque champ de votre système source à un champ SAP. Un mapping simple est direct : le champ NOM_CLIENT de votre ERP correspond au champ Name 1 de SAP. Un mapping complexe implique des règles de transformation : si le code pays est ‘F’ dans votre ERP, il faut le transformer en ‘FR’ au format ISO dans SAP. Si les montants sont stockés en centimes, il faut les diviser par 100 avant le chargement.

Cette phase nécessite une collaboration étroite entre les équipes IT qui connaissent la structure de l’ERP maison, les équipes métiers qui connaissent la signification des données, et les consultants SAP qui connaissent les structures cibles.

Phase 3 : Le nettoyage des données

C’est souvent la phase la plus longue en termes de travail réel. La mise en oeuvre de S/4HANA présente divers défis, tels que l’intégration des silos de données existants, le maintien d’une autorisation appropriée et l’alignement des systèmes hérités avec le nouveau système ERP. (Source : Stibo Systems, 2025)

Les anomalies les plus fréquentes dans les ERP maison sont les tiers en doublon avec des orthographes légèrement différentes, les codes articles qui ne respectent pas la longueur ou le format SAP, les comptes comptables qui n’existent pas dans le plan comptable SAP cible, les devises ou unités de mesure non reconnues par SAP, et les dates invalides ou incohérentes. Chaque anomalie doit être corrigée avant le chargement. Les équipes découvrent pendant cette phase des problèmes de qualité qui existaient depuis des années dans l’ERP maison sans que personne ne les ait identifiés.

Phase 4 : Les tests de migration

SAP Best Practices for Data Migration permet la validation des données dans une zone de staging, réduisant le processus chronophage de chargement répété de données incorrectes dans SAP. (Source : Prometheus Group, 2025)

Un projet de migration depuis un ERP maison réalise en général trois à cinq runs de migration avant la bascule finale. Le premier run, dit de migration à blanc, charge les données dans un environnement de test et permet d’identifier les erreurs de mapping. Les runs suivants affinent les règles de transformation. Le dernier run avant go-live doit fonctionner sans erreur bloquante. Ces runs doivent être planifiés dans le calendrier du projet. Sur un projet de 6 mois, la phase de migration de données mobilise souvent 2 à 3 mois de travail, répartis sur l’ensemble du projet.

Phase 5 : La migration finale et la bascule

La migration finale, dite de cutover, est réalisée pendant le week-end de bascule. Elle comprend l’extraction finale des données de l’ERP maison à une date et heure précises, la transformation et le chargement dans SAP Production, la validation des données chargées par les key users, et l’ouverture du système aux utilisateurs finaux.

Cette séquence doit être documentée dans un plan de cutover détaillé, avec des jalons horaires, des responsables identifiés pour chaque étape, et des critères de go/no-go explicites. Si une anomalie bloquante est détectée pendant la migration finale, le plan de retour arrière doit permettre de revenir sur l’ERP maison sans perte de données.

Les erreurs les plus fréquentes et comment les éviter

Sous-estimer le volume de données à migrer. Un ERP maison avec 50 000 clients peut sembler migrable en quelques jours. Mais si ces clients ont des données incomplètes, des doublons, des formats non conformes et des relations avec d’autres objets, la charge de travail réelle peut être dix fois supérieure à l’estimation initiale.

Commencer la migration trop tard dans le projet. La migration de données doit démarrer en phase Explore, pas en phase Realize. Les projets qui découvrent leurs problèmes de données tardivement n’ont plus le temps de les corriger sans impacter le planning. (Source : Pathlock, 2026)

Impliquer uniquement l’IT dans la migration. La migration de données est souvent perçue comme un sujet technique confié à l’équipe IT. Les key users métiers sont indispensables pour valider que les données chargées dans SAP représentent fidèlement la réalité opérationnelle. Chaque type de données doit avoir un owner métier qui valide les résultats de migration.

Négliger les données historiques. Décider de ‘tout migrer’ crée une masse de données inutilisables dans SAP et des problèmes de performance. Décider de ‘ne migrer que les soldes’ empêche les équipes de consulter l’historique directement dans SAP. La bonne approche est de définir un horizon de migration par type de données, validé par la direction avant le démarrage du chantier.

Négliger les soldes d’ouverture. La migration des soldes comptables d’ouverture est techniquement simple mais opérationnellement complexe : elle nécessite que les équipes finance réconcicient les soldes SAP avec la comptabilité de l’ERP maison, au centime près, avant le go-live. C’est toujours le dernier chantier, et toujours sous-estimé.

Ce que le terrain nous enseigne

Voici les enseignements qui reviennent le plus fréquemment dans les projets de migration depuis un ERP maison vers SAP Public Cloud.

Questions à se poser pour une migration de données

Peut-on migrer toutes les données d’un ERP maison vers SAP Public Cloud ?

Techniquement, toutes les données peuvent être migrées à condition qu’elles correspondent à des structures SAP ou qu’un mapping soit possible. En pratique, certaines données très spécifiques à l’ERP maison n’ont pas d’équivalent dans SAP standard. Elles doivent soit être adaptées pour correspondre aux structures SAP, soit conservées dans un système d’archivage externe consultable après le go-live.

Combien de temps prend la migration de données dans un projet Grow with SAP ?

Sur un périmètre ETI standard, la migration de données représente entre 30 et 50% de la charge totale du projet. Sur un projet de 6 mois, il faut compter 2 à 3 mois de travail répartis tout au long du projet depuis la phase Explore. Les projets qui traitent la migration de données comme un chantier de fin de projet sont systématiquement en retard.

Qu’est-ce qu’un objet de migration dans SAP Public Cloud ?

Un objet de migration est une entité prédéfinie par SAP dans le Migration Cockpit. Il correspond à un type de données : clients, fournisseurs, articles, comptes GL, immobilisations, commandes d’achat, etc. Pour chaque objet, SAP fournit un template (fichier Excel ou CSV) qui définit exactement les champs attendus et leur format. Le Migration Cockpit génère automatiquement les programmes de chargement sans développement ABAP. (Source : SAP Community, 2026)

Faut-il migrer l’historique des transactions ou uniquement les données maîtres et les soldes ?

Les deux approches sont valides selon le contexte. La migration des données maîtres et des soldes est la plus rapide et la plus sécurisée pour les projets sous contrainte de délai. La migration de l’historique transactionnel permet aux équipes de consulter les anciennes commandes et factures directement dans SAP. La décision doit être prise par métier et par type de données, avec un horizon de migration différencié.

Comment gérer l’ERP maison après la bascule SAP ?

L’ERP maison doit rester accessible en lecture pour les équipes qui ont besoin de consulter l’historique antérieur à la date de bascule. Il est recommandé de le conserver en mode consultation pendant au moins 12 à 24 mois après le go-live. Les accès doivent être progressivement réduits et documentés dans le plan de décommissionnement.