ServiceNow est la plateforme ITSM de référence des très grandes organisations, mais sa puissance a un prix : licences élevées, mise en œuvre lourde et courbe d’apprentissage raide. Pour une entreprise qui cherche à simplifier sa gestion des services IT tout en réduisant ses coûts, Jira Service Management (JSM) d’Atlassian constitue une alternative crédible, surtout lorsqu’elle évolue déjà dans l’écosystème Atlassian. Réussir cette migration, c’est transférer tickets, catalogue de services, base de configuration (CMDB) et workflows sans dégrader le service rendu aux utilisateurs.
Pourquoi quitter ServiceNow pour Jira Service Management ?
Deux moteurs dominent. D’abord, le coût de licence : ServiceNow facture par utilisateur remplissant un rôle et par module, ce qui peut devenir prohibitif hors du cercle des grandes entreprises. Ensuite, la complexité : ServiceNow exige des administrateurs certifiés et des développements sur la plateforme Now, alors que JSM s’appuie sur une interface plus accessible, une tarification plus simple et une intégration native avec Jira Software — un atout décisif lorsque support et développement doivent collaborer étroitement.
Différences concrètes entre les deux plateformes
| Dimension | ServiceNow | Jira Service Management |
|---|---|---|
| Modèle | Suite ITSM complète (incidents, demandes, changements, CMDB) | Service desk orienté équipes, lié à Jira |
| Personnalisation | Développement sur plateforme Now (scripting, flows) | Interface + Automation, apps Marketplace |
| CMDB | Configuration Management Database native et riche | Assets (inventaire) intégré |
| Coût | Élevé, par rôle/module | Plus accessible, par agent |
| Intégration dev | Via intégrations | Native avec Jira Software |
Les étapes d’une migration ServiceNow → JSM
- Audit du périmètre ServiceNow : recenser les tables de tickets (incidents, demandes, problèmes, changements), le catalogue de services, les workflows, la CMDB et les intégrations.
- Définition du périmètre cible : choisir les modules JSM à déployer (helpdesk, gestion des demandes, assets) et les fonctionnalités à conserver ou abandonner.
- Cartographie des données : établir la correspondance entre tables ServiceNow et types de tickets JSM, entre champs (état, priorité, urgence, impact) et entre éléments de configuration et objets d’assets.
- Extraction : exporter les données via l’API REST de ServiceNow (tables
incident,sc_request,cmdb_ci, etc.), en paginant et en gérant les ACL. - Transformation : convertir les enregistrements au format attendu par l’import JSM, en reconstruisant les relations (ticket ↔ élément de configuration, ticket ↔ utilisateur).
- Import : injecter tickets et assets dans JSM via l’API REST Atlassian, en séquençant pour préserver les dépendances.
- Reconstruction : recréer le catalogue de services, les workflows, les règles d’automatisation, les SLAs et les permissions dans JSM.
- Test et bascule : valider l’intégrité sur un environnement de test, puis basculer en fenêtre planifiée avec ServiceNow en lecture seule.
Les risques majeurs et leurs parades
La perte des relations est le risque numéro un : dans ServiceNow, un incident référence un élément de configuration, un utilisateur et parfois un problème parent ; si ces liens ne sont pas reconstruits à l’import, l’historique devient inexploitable. La parade consiste à exporter les clés d’identification de chaque objet et à les préserver à travers un mapping rigoureux. Le deuxième risque est la régression fonctionnelle : un workflow ServiceNow complexe (approbations, scripts, flux d’escalade) ne se transpose pas tel quel ; il faut le redéfinir avec Automation for Jira et le tester scénario par scénario. Le troisième est la perte de la CMDB : les assets doivent être repris avec leurs attributs et leurs relations pour conserver l’analyse d’impact.
Bonnes pratiques pour une migration maîtrisée
- Réduire le périmètre : ne migrer que ce qui a de la valeur, archiver le reste — c’est l’occasion de simplifier réellement l’ITSM.
- Réaliser des migrations de répétition sur un environnement de test pour valider le mapping et calibrer la fenêtre de bascule.
- Documenter chaque workflow avant de le réécrire dans JSM, avec ses acteurs, conditions et notifications.
- Prévoir un plan de rollback et conserver ServiceNow en lecture seule jusqu’à validation complète.
- Former les équipes ITSM et les agents au nouvel outil avant la bascule.
Accompagner les équipes et la gouvernance
Quitter ServiceNow, c’est aussi renoncer à certains réflexes d’administrateur et à une culture d’outil. La conduite du changement doit couvrir les administrateurs, les agents du service desk et les utilisateurs finaux, avec une documentation des nouveaux processus de demande et de traitement des incidents.
Reprise de la CMDB et des relations entre enregistrements
La CMDB est l’actif le plus difficile à migrer de ServiceNow vers JSM. Dans ServiceNow, chaque élément de configuration (serveur, application, service métier) est décrit par une classe et relié à d’autres par des relations typées (dépend de, héberge, connecte à). JSM propose une gestion des assets plus simple : les objets sont importés avec leurs attributs, mais le modèle de relations est moins riche. La stratégie consiste donc à définir, avant l’import, un modèle d’assets cible : quelles classes conserver, quels attributs reprendre, comment représenter les relations essentielles à l’analyse d’impact. Tout ce qui ne peut être représenté doit être documenté, pas ignoré.
L’ordre d’import est critique : les assets d’abord, puis les utilisateurs, puis les tickets, afin que chaque incident importé puisse être rattaché à son élément de configuration et à son demandeur. Les clés d’identification de chaque enregistrement ServiceNow doivent être préservées pendant la transformation pour reconstruire ces liens, faute de quoi l’historique devient un tas de tickets sans contexte.
Réécrire les workflows et gérer la gouvernance
Les workflows ServiceNow (approbations, escalades, scripts) se réécrivent dans Automation for Jira. Chaque flux doit être documenté avant sa réécriture : acteurs, conditions de transition, notifications, délais. Les scripts côté serveur (Business Rules, script includes) n’ont pas d’équivalent direct ; leur logique doit être réimplémentée via l’automatisation ou des apps du Marketplace, ce qui impose de les recenser tôt. Enfin, la gouvernance doit être redéfinie : rôles des agents, permissions des projets, files d’attente et SLA, en profitant de la migration pour simplifier ce qui peut l’être. La bascule doit s’appuyer sur des migrations de répétition : chaque test révèle des écarts de mapping ou des relations manquantes qu’il faut corriger avant la bascule définitive. Le succès se mesure par la concordance des compteurs de tickets et d’assets entre source et cible, et par la continuité du portail utilisateur et des files d’attente dès la mise en production.
Performances Digital accompagne la migration ServiceNow vers Jira Service Management : audit du périmètre, cartographie des tables et des relations, reprise des tickets et de la CMDB, reconstruction des workflows et formation des équipes. Nous visons une simplification réelle de votre ITSM et une réduction durable des coûts, sans dégradation du service.
Migrer de ServiceNow à Jira Service Management, c’est gagner en simplicité et en maîtrise budgétaire tout en rapprochant support et développement. Demandez votre devis gratuit : nous évaluons votre périmètre ITSM, vos volumes et vos workflows, puis nous vous remettons une feuille de route chiffrée.
