Migration de données IFS Cloud : le guide complet 2026 (DMM, FNDMIG, Excel)

Publié le 11 juin 2026 — par l’équipe ERP Control (Globasoft) · Lecture : 8 min

En résumé : une migration de données IFS échoue rarement sur la technique pure — elle échoue sur la préparation, le mapping et l’ordre de chargement. Ce guide couvre les trois outils natifs (Migration Job/FNDMIG, Data Migration Manager, Excel), la méthode en 7 étapes, le dictionnaire des erreurs ORA les plus fréquentes, et les pièges qui font dérailler un projet.

La reprise de données est le point de bascule de tout projet IFS Cloud. Le paramétrage peut être impeccable et les processus parfaitement modélisés : si les données de référence (clients, fournisseurs, articles, structures, soldes) n’arrivent pas correctement, le go-live déraille. Et pourtant, c’est la phase la plus sous-estimée — souvent lancée tard, sans méthode, avec les mauvais outils.

Les 3 outils natifs de migration IFS (et quand utiliser chacun)

Confondre Migration Job, DMM et Excel add-in — ou utiliser le mauvais pour un cas — est l’une des premières causes de perte de temps.

Migration Job (FNDMIG) — le moteur technique

Le moteur de chargement de masse : il lit une source (CSV chargé dans une IC table, ou une requête) et écrit via les API métier d’IFS. Procédures clés : CREATE_TABLE_FROM_FILE, MIGRATE_SOURCE_DATA, INSERT_OR_UPDATE. Idéal pour les gros volumes, les données techniques, les scénarios répétables.

Data Migration Manager (DMM) — l’approche projet

Structure la migration en projet (scope, basic data container, mapping guidé, étapes jusqu’à Approved). L’outil le plus encadré. Attention : un projet DMM « Approved » peut quand même renvoyer une erreur de basic data validation.

Excel add-in — l’outil des key users

Exporter une structure, l’éditer dans Excel, ré-importer. Le plus accessible aux métiers. Limite connue : au-delà de ~3 000 lignes, l’add-in renvoie souvent une erreur de validation, obligeant à découper en lots. Et une MAJ Office peut casser l’add-in du jour au lendemain.

Comment migrer des données dans IFS Cloud : la méthode en 7 étapes

1. Cadrage du périmètre
2. Extraction & profilage de la source
3. Construction du mapping
4. Chargement dans le bon ordre
5. Validation avant l’exécution réelle
6. Réconciliation (volumes + totaux)
7. Bascule & gel

Industrialisez les étapes 3 à 5 sur un environnement CFG d’abord, puis rejouez la même reprise sur UAT, TRN puis PROD. Une migration qui n’a pas été rejouée à l’identique entre environnements n’est pas fiable.

L’ordre de chargement : la règle des dépendances

• Basic data avant transactionnel — codes, unités, devises, comptes d’abord.
• Parents avant enfants — le champ de rattachement (ex. SUP_MCH_CODE) est souvent insert-only : raté à l’insertion, on recommence.
• En-têtes avant lignes (customer orders) — sinon ORA-20111 Site.NOTEXIST2.
• Structures avant composants — PROD_STRUCTURE_HEAD avant ce qui s’y rattache.

Le mapping : là où se jouent 80 % des erreurs

• Champs non modifiables — ORA-20122 … may not be modified (ex. CATALOG_TYPE sur SALES_PART).
• INSERT vs UPDATE — ORA-20112 FND_RECORD_EXIST → passer en INSERT_OR_UPDATE ou dédoublonner.
• Champs obligatoires non désirés — gérer PARTY_TYPE en valeur par défaut plutôt que retirer la colonne.
• Custom fields (CFV) sur deux structures → ROWKEY error.
• Ordre des enregistrements (SEQUENCE_NO) — 6 records sur 8, sans erreur affichée : réconciliez toujours.

Dictionnaire des erreurs de migration IFS

Les 6 pièges qui font dérailler une migration

1. Sous-estimer la préparation
2. Les volumes (Excel ~3 000 lignes)
3. Les permissions (SE_UNAUTHORIZED)
4. Les statuts & champs verrouillés
5. L’absence de réconciliation
6. La non-répétabilité entre environnements

Automatiser et sécuriser la migration

Les outils natifs font le travail mais laissent à la charge des équipes tout ce qui est répétitif et risqué : refaire le mapping à chaque environnement, gérer les gros volumes par lots, garder une trace auditable de ce qui a été chargé.

C’est précisément ce que ERP Control automatise : export des données IFS vers Excel structuré, édition dans un outil familier, puis ré-import validé ligne à ligne avec mapping colonne-à-champ et orchestration automatique POST / PATCH / DELETE — sur tous vos environnements, via l’API ODATA standard, sans développement spécifique. Cela complète la promotion de parametrage, securite & permissions et la qualite des donnees & anonymisation RGPD.

Vous préparez une reprise de données IFS Cloud ? Demandez un POC gratuit de 2 semaines et testez la migration automatisee, validee ligne a ligne, sur vos propres donnees.

FAQ

Comment migrer des données dans IFS Cloud, étape par étape ?

Suivez sept étapes : cadrage, extraction & profilage, mapping, chargement dans le bon ordre, validation, réconciliation, puis bascule & gel. Industrialisez-les sur CFG et rejouez-les à l’identique sur UAT, TRN et PROD.

Quel est le meilleur outil pour migrer des données dans IFS Cloud ?

Cela dépend du volume et du profil : l’Excel add-in pour les ajustements et petits volumes, le DMM pour une reprise structurée, et le Migration Job (FNDMIG) pour les gros volumes techniques et répétables.

Que signifie l’erreur ORA-20112 FND_RECORD_EXIST ?

L’enregistrement existe déjà : vous tentez un INSERT sur une clé présente. Passez en INSERT_OR_UPDATE ou dédoublonnez la source.

Pourquoi mon Excel migration plante-t-il au-delà de 3 000 lignes ?

L’add-in Excel atteint une limite de validation sur les gros volumes. Découpez en lots ou basculez sur un Migration Job.

Dans quel ordre charger les données dans IFS ?

Toujours : basic data d’abord, puis parents avant enfants, en-têtes avant lignes, structures avant composants.

Faut-il rejouer la migration sur plusieurs environnements ?

Oui. Une reprise fiable est conçue pour être rejouée à l’identique de CFG à UAT, TRN puis PROD — c’est ce qui garantit qu’il n’y aura pas de surprise au go-live.

Cas remontés par la communauté IFS et le terrain. Tout élément non vérifié est signalé « à confirmer selon la version IFS Cloud et le contexte client ».