En bref : IFS Cloud permet de déplacer des jobs de migration entre environnements via les groupes de migration : on affecte un Group ID commun aux jobs, on exporte le groupe dans un fichier, puis on charge ce fichier avec le job standard FNDMIG_IMPORT dans l'environnement cible. Deux points que la documentation ne met pas en avant : l'import remplace tout job existant portant le même nom, et certaines équipes se heurtent encore à une erreur non résolue au moment de l'import. Voici la procédure complète, les risques, et les vérifications à faire avant de toucher à la PROD.
Vous avez passé une journée à construire un job de migration en DEV. Configuration du fichier, mapping des colonnes, règles, method list : il tourne enfin proprement. Il faut maintenant le même job en TEST, puis en PROD. Le reconstruire à la main dans chaque environnement, c'est la garantie que les mappings vont diverger sans bruit, et qu'un job qui fonctionnait en DEV se mettra à échouer en production pour des raisons que personne n'arrive à reproduire.
La question revient régulièrement sur la communauté IFS. Un utilisateur la posait sans détour en 2024 : « J'ai créé un job de migration dans notre environnement DEV et je veux le copier en PROD, quelle est la meilleure façon de faire ? » La réponse acceptée renvoyait à la documentation technique, sans dérouler les étapes. Cet article les déroule.
La méthode native, pas à pas
IFS Cloud ne déplace pas un job seul. Il déplace un groupe de jobs. Le Group ID est ce qui fait fonctionner tout le mécanisme, et c'est aussi ce qui le rend risqué si l'on est négligent sur ce qu'on met dans le groupe.
La procédure ci-dessous provient d'une réponse validée par la communauté en février 2025, sur un fil où une équipe devait déplacer un grand nombre de jobs vers un nouvel environnement IFS Cloud.
1. Affecter un Group ID commun aux jobs.
Dans l'écran des jobs de migration, renseignez le même Group ID sur chaque job à déplacer. Un job sans Group ID reste où il est.
2. Exporter le groupe.
Ouvrez l'écran Migration Groups, sélectionnez votre Group ID, puis lancez la commande Export Group et confirmez la fenêtre qui s'affiche.
3. Écrire l'export dans un fichier.
Lancez la commande Export to File, saisissez un nom de fichier, confirmez. Le fichier arrive dans votre dossier de téléchargements. Rangez-le à un endroit où vous le retrouverez : ce fichier est la seule chose qui voyage d'un environnement à l'autre.
4. Dans l'environnement cible, ouvrir FNDMIG_IMPORT.
Cherchez le job de migration nommé FNDMIG_IMPORT dans l'écran des jobs de migration, puis lancez Execute Job.
5. Charger le fichier.
Lancez la commande Load File, chargez le fichier exporté à l'étape 3, confirmez.
6. Exécuter.
Une fois le fichier chargé, lancez la commande Online. En cas de succès, IFS affiche un message d'information qui résume ce qui a été importé.
C'est tout le flux. Rien à installer, rien à scripter : ce sont des fonctions IFS standard, disponibles dans tous les environnements.
Ce que l'import écrase, et pourquoi c'est important
C'est le passage à lire deux fois.
Lorsque le fichier importé contient un job dont le nom existe déjà dans l'environnement cible, le système remplace le job existant. Pas de fusion, pas de demande de confirmation, pas d'option « garder les deux ». La version qui arrive gagne.
L'auteur de la réponse validée est explicite sur la conséquence : n'affectez un Group ID qu'à des jobs correctement testés, et laissez le système remplacer ce qui est en place. Le conseil est juste, mais il fait reposer toute la sécurité de l'opération sur votre rigueur dans la gestion des Group ID.
Prenons le scénario réaliste. Un job existe en PROD, où quelqu'un a ajusté une règle il y a six mois pour traiter un cas particulier local. La version de DEV n'a jamais reçu cet ajustement. Vous promouvez votre groupe, le job de PROD est remplacé par celui de DEV, et le cas particulier ressurgit silencieusement à la prochaine exécution. Rien dans la procédure ne vous alerte : le message d'import vous dit que l'opération a réussi, pas ce qu'elle a modifié.
Avant toute promotion vers un environnement de production, la question à trancher n'est donc pas « est-ce que mon job fonctionne en DEV », mais « est-ce que la version cible a divergé de la mienne ».
Sous le capot : comment le groupe est sélectionné
Si vous avez besoin de comprendre ou d'ajuster ce qui est exporté, la sélection se fait dans une règle du job FNDMIG_EXPORT. Un membre de la communauté a partagé la clause where utilisée par défaut sur la règle INTFACE_NAME :
`
INTFACE_NAME IN (SELECT intface_name FROM INTFACE_HEADER WHERE GROUP_ID = '<group_id>')
`
En clair : exporter toute définition de job dont le nom appartient au groupe sélectionné. C'est le comportement par défaut de FNDMIG_EXPORT, et c'est utile à connaître quand on veut vérifier ce qu'un groupe contient réellement avant de l'exporter.
Quand ça échoue, et ce que la communauté sait à ce jour
L'honnêteté vaut mieux qu'un tutoriel bien lisse : voici l'état de l'art.
En mai 2026, un utilisateur a suivi exactement les étapes ci-dessus et s'est heurté à une erreur au moment de l'import, avec FNDMIG_IMPORT, dans un autre environnement. Le fil est toujours ouvert à l'heure où nous écrivons. Un membre expérimenté a proposé une piste à tester : la longueur des noms de jobs de migration. Certaines colonnes de la base sous-jacente sont courtes, et un nom de job trop long peut casser l'import. Le test suggéré est simple : renommer les définitions de jobs avec des noms plus courts, puis réessayer.
Deux autres vérifications valent le détour avant de conclure que le mécanisme est cassé :
- vérifier que le fichier d'export contient bien quelque chose, en exportant d'abord un groupe contenant un seul job, petit et connu ;
- vérifier que le Group ID est réellement renseigné sur les jobs attendus, car un job sans Group ID est silencieusement absent de l'export.
Si l'import échoue toujours, vous êtes en terrain connu : c'est un cas documenté et non résolu, pas une erreur de votre part.
Ce que cette méthode ne donne pas
Le mécanisme fonctionne, et pour un déplacement ponctuel il est tout à fait raisonnable. Ses limites apparaissent quand promouvoir du paramétrage devient une routine plutôt qu'un événement.
- Aucun historique. Rien n'enregistre qui a promu quel job, depuis quel environnement, ni quand. Le message d'information disparaît avec la session.
- Aucun aperçu. Vous ne pouvez pas voir ce que l'import s'apprête à remplacer avant qu'il ne le remplace.
- Aucun retour arrière. Si la version importée est mauvaise, la précédente a disparu ; vous la restaurez depuis un autre environnement, à condition qu'il la détienne encore.
- Une granularité de groupe. On déplace un groupe, pas un job : vos Group ID doivent être curés à la main à chaque promotion.
- Un fichier dans un dossier de téléchargements. L'artefact qui voyage entre vos environnements est un fichier sur le poste de quelqu'un.
Et une promotion est rarement un événement isolé : à chaque rafraîchissement d'un environnement de test depuis la production, les jobs que vous y aviez promus sont écrasés, et tout est à refaire. Voir ce qu'un clone remplace réellement.
C'est exactement le terrain pour lequel ERP Control a été conçu : promouvoir du paramétrage entre environnements (CFG, TRN, UAT, PROD) avec une comparaison avant écriture, une sélection au niveau de l'objet, et un journal complet de ce qui a été promu, par qui et quand. Non pas pour remplacer les jobs de migration natifs, qui font leur travail, mais pour rendre la promotion elle-même maîtrisée et reproductible.
Découvrez comment ERP Control gère la promotion de paramétrage entre vos environnements IFS — voir le module de promotion de paramétrage.
Checklist avant de promouvoir en production
Passez ces six points en revue avant de charger quoi que ce soit en PROD :
- Le job est testé dans l'environnement source, sur des données qui ressemblent à celles de la cible.
- Le Group ID ne contient que les jobs que vous avez l'intention de promouvoir, vérifiés un par un.
- Vous avez listé les jobs de même nom déjà présents dans l'environnement cible.
- Pour chacun d'eux, vous avez confirmé que la version cible n'a pas divergé de la vôtre.
- Le fichier d'export est enregistré hors du dossier de téléchargements, avec la date et l'environnement source dans son nom.
- Vous savez comment vous restaureriez la version précédente si l'import s'avérait mauvais.
Voir ERP Control sur votre propre cas
La promotion entre environnements est le quotidien de l'outil. Dans un POC, nous prenons l'une de vos promotions réelles, nous la rejouons dans ERP Control, et vous voyez ce qui change sur votre paramétrage, avec la comparaison et le journal.
La suite : un appel de 30 minutes pour cadrer le besoin, une démonstration sur vos données, puis vous décidez. Sans engagement.
FAQ
Puis-je déplacer tous mes jobs de migration en une fois ?
Oui, c'est précisément l'objet du Group ID. Affectez le même Group ID à tous les jobs à déplacer, puis exportez le groupe en une seule opération.
Que se passe-t-il si un job du même nom existe déjà dans l'environnement cible ?
Il est remplacé par la version importée. IFS affiche un message d'information à la fin de l'import, mais ne demande pas de confirmer le remplacement. Ne groupez que des jobs correctement testés.
Où arrive le fichier exporté ?
Dans le dossier de téléchargements de votre navigateur, une fois la commande Export to File exécutée. Rangez-le ailleurs avec un nom parlant : c'est le seul artefact qui voyage entre les environnements.
L'import échoue avec une erreur, que vérifier ?
D'abord que le Group ID est bien renseigné sur les jobs concernés. Ensuite, essayez avec un seul job de petite taille pour isoler le problème. Si l'échec persiste, testez des noms de jobs plus courts : un cas communautaire non résolu de 2026 pointe la longueur des noms de jobs, limitée par des colonnes courtes en base.
Sources
Cas réels issus de la communauté IFS (discussions avec réponse validée ou réponse d'expert) :
- Discussion IFS Community — déplacer un ensemble de jobs de migration vers un nouvel environnement (2025)
- Discussion IFS Community — erreur à l'import d'un groupe de jobs de migration (2026)
- Discussion IFS Community — copier un job de migration d'une instance à une autre (2024)
- Documentation technique IFS — export et import des jobs de migration
Fait partie de notre guide pilier : Migration de données IFS Cloud, le guide complet 2026.