En bref : DMM est l'outil natif d'IFS, puissant et gratuit, pensé pour les chargements structurés à grande échelle. Sa contrepartie, c'est une vraie expertise technique : templates par version, validation targets, mapping fin, et des échecs parfois silencieux. ERP Control se place ailleurs : des opérations no-code, ciblées et répétables sur vos environnements (CFG · UAT · TRN · PROD), sans Method List ni PL/SQL. Ce ne sont pas deux outils identiques, mais deux philosophies. Voici comment trancher.
Vous devez charger ou mettre à jour des données dans IFS Cloud, et la question revient à chaque projet : on reste sur les outils natifs d'IFS, ou on prend une solution dédiée ? Ce comparatif ne cherche pas à disqualifier DMM, qui est un bon outil. Il vous aide à choisir selon votre équipe, vos volumes et la fréquence de vos opérations.
Les outils natifs de migration IFS, en une minute
IFS Cloud propose en réalité plusieurs mécanismes, qu'on confond souvent sous « la migration » :
- DMM (Data Migration Manager) : l'approche moderne et recommandée par IFS. On part de projets basés sur des templates, on mappe des tables sources vers des tables cibles, on valide par paliers (Input, Output, Deploy), puis on déploie.
- FndMig / « Data Migration » : l'outil historique à base de jobs (
CREATE_TABLE_FROM_FILE,MIGRATE_SOURCE_DATA), encore très utilisé, qui demande de configurer fichier, mapping et règles à la main. - L'add-in Excel : pratique pour des charges ponctuelles, mais limité dès qu'on sort du cas simple.
Ces outils sont gratuits (inclus dans IFS) et profondément intégrés. C'est leur grande force. Leur contrepartie : ils supposent qu'on maîtrise le modèle de données IFS, les colonnes _DB, les flags On New / On Modify, les Method Lists. C'est là que les projets dérapent.
Ce que DMM fait très bien
DMM reste l'outil de référence dans plusieurs situations :
- vous réalisez un chargement initial structuré (montée de version, nouvelle entité, reprise legacy) ;
- vous avez besoin de rejouer une migration à l'identique entre environnements via un projet template ;
- vous avez une compétence technique IFS en interne ou chez un partenaire ;
- vous voulez rester 100 % dans le standard IFS, sans outil tiers.
Pour ces cas, DMM est puissant et c'est généralement le bon choix.
Là où DMM (et FndMig) montrent leurs limites
C'est l'autre face, et elle est documentée par la communauté IFS elle-même. Quatre exemples réels, tous issus de discussions à réponse validée.
1. Des échecs qui ne disent pas leur nom
Un consultant migre des Posting Controls via DMM. Toutes les étapes passent au vert, jusqu'au « Deploy with Commit », sans aucune erreur affichée. Sauf qu'en base, rien n'a été écrit : l'outil a avalé l'exception qui empêchait l'insertion, sans la remonter. Un échec silencieux est le pire scénario en migration : on croit la donnée en place, on s'en aperçoit bien plus tard, en production.
2. Le piège de la « Validation Target »
Une équipe a tout fait dans les règles : données mappées, importées, statut « Approved ». Et elle bute pourtant sur une erreur de validation des basic data. La cause n'a rien d'évident. Selon que la Validation Target de la définition de table cible est renseignée ou non, DMM valide soit contre son propre conteneur, soit contre la table cible réelle. Tant qu'on ne connaît pas ce comportement interne, on tourne en rond. C'est typique de DMM : la logique est cohérente, mais elle exige de connaître les rouages.
3. Des templates à gérer version par version
Pour démarrer un projet DMM, il faut souvent un Template Project, et celui-ci dépend de la version IFS. Sur la communauté, des utilisateurs s'échangent les fichiers de template pour 23R2, 24R1, etc., et signalent au passage des vues manquantes ou des templates qui ne remontent pas dans la liste « Based On Template Project ». Autrement dit : la mise en route a un coût, et ce coût se répète à chaque montée de version.
4. FndMig : la complexité du mapping
Sur l'outil historique, un cas parlant : à la migration d'utilisateurs, le champ Description se retrouve rempli avec la concaténation de tous les champs au lieu du seul nom. Le diagnostic implique d'inspecter le séparateur de colonnes, le « column embrace », le job TMP_IMPORT_USERS, l'onglet File Configuration, le bouton Unpack File. Un simple import d'utilisateurs devient une enquête technique.
Le point commun de ces quatre cas n'est pas que DMM ou FndMig soient mauvais. C'est qu'ils réclament une expertise pointue du modèle de données IFS. Quand on l'a, ils sont puissants. Quand on ne l'a pas, chaque opération devient un projet.
ERP Control vs DMM : le comparatif
| Critère | DMM / FndMig (natif IFS) | ERP Control |
|---|---|---|
| Approche | Jobs, templates, mapping de tables | No-code, par configuration |
| Compétence requise | Modèle de données IFS, PL/SQL, Method List | Métier, sans développeur |
| Type d'opération | Chargement initial structuré, gros volumes | Opérations ciblées et répétables, mises à jour, promotion de paramétrage |
| Mises à jour | Le job envoie toutes les colonnes mappées (risque ORA-20122 sur champs verrouillés) | Updates ciblés (PATCH OData) : seuls les champs modifiés sont envoyés |
| Multi-environnements | Rejouable via templates, à gérer manuellement | Promotion CFG · UAT · TRN · PROD intégrée |
| Remontée d'erreurs | Parfois silencieuse (cf. cas Posting Controls) | Contrôles et journal d'opération |
| Coût | Inclus dans IFS | Licence SaaS dédiée |
| Idéal pour | Reprises lourdes, équipes techniques | Équipes fonctionnelles, opérations courantes, cohérence inter-environnements |
Où se place exactement ERP Control
ERP Control n'est pas un « DMM en mieux ». C'est une réponse à un autre besoin. Là où DMM excelle sur les chargements lourds et ponctuels, ERP Control vise les opérations récurrentes que vivent les équipes IFS au quotidien :
- promouvoir du paramétrage d'un environnement à l'autre sans le ressaisir ;
- mettre à jour des données de façon ciblée, sans craindre les champs insert-only (les updates n'envoient que ce qui change) ;
- importer / exporter via Excel proprement, au-delà du cas simple ;
- le tout en no-code, donc accessible à une équipe fonctionnelle, sans mobiliser un consultant technique pour chaque manipulation.
L'objectif n'est pas de remplacer DMM sur une reprise de données massive. Il est d'éviter de sortir l'artillerie technique pour des tâches qui devraient être simples, et de les rendre cohérentes et répétables entre vos environnements.
Alors, lequel choisir ?
La vraie réponse dépend de trois questions :
- Avez-vous une compétence technique IFS disponible ? Si oui, DMM est à votre portée. Si non, le no-code change la donne.
- Est-ce une opération ponctuelle ou récurrente ? Une reprise unique justifie l'effort DMM. Des opérations hebdomadaires sur plusieurs environnements appellent un outil dédié.
- Le risque d'échec silencieux est-il acceptable ? En production, la traçabilité et les contrôles ne sont pas un luxe.
Beaucoup d'équipes utilisent d'ailleurs les deux : DMM pour les grands chargements initiaux, ERP Control pour le quotidien (promotion de paramétrage, mises à jour ciblées, import/export). Ce n'est pas un choix idéologique, c'est une question d'outil adapté à la tâche.
Pour comprendre la mécanique des erreurs de migration côté natif, voir notre guide pilier Migration de données IFS Cloud; pour les opérations Excel, la page Import / Export Excel IFS.
Découvrez comment ERP Control simplifie les opérations de données IFS Cloud : voir le module migration.
Voir ERP Control sur votre propre cas
Un comparatif aide à se décider, mais le meilleur juge de paix reste un essai sur vos données. Lors d'un POC, on prend une opération réelle de votre environnement (promotion de paramétrage, mise à jour ciblée, import Excel) et on la rejoue dans ERP Control, en no-code. Vous voyez le résultat sur votre cas concret.
Ce qui se passe ensuite : un échange de 30 minutes pour cadrer le besoin, une démonstration sur vos données, puis vous décidez. Sans engagement.
FAQ
ERP Control remplace-t-il DMM ?
Non, pas pour les chargements initiaux massifs et structurés, où DMM reste pertinent. ERP Control adresse les opérations ciblées et répétables (promotion de paramétrage, mises à jour, import/export) en no-code. Les deux sont complémentaires.
DMM est gratuit, pourquoi payer un outil dédié ?
DMM est inclus, mais son coût réel est la compétence qu'il exige : temps d'apprentissage, dépendance à un profil technique, risque d'erreurs coûteuses. Un outil no-code se rentabilise s'il libère ce goulot et fiabilise des opérations récurrentes.
Peut-on éviter les erreurs ORA-20xxx avec ERP Control ?
Une partie d'entre elles, oui : sur les mises à jour, ERP Control n'envoie que les champs réellement modifiés (PATCH ciblé), ce qui évite les rejets de type « may not be modified » (ORA-20122) sur les champs verrouillés.
Faut-il un consultant pour utiliser ERP Control ?
Non, c'est tout l'objet du no-code : les opérations se font par configuration, sans développement ni connaissance du modèle de données interne d'IFS.
Sources
Cas réels issus de la communauté IFS (discussions à réponse validée) :