Migration de Maximo 7.6 vers MAS 9 : ce qui change pour les données
Mis à jour le · VAGANET EAM
En bref. Passer de Maximo 7.6 à MAS 9 ne veut pas forcément dire recharger ses données : la voie standard met à niveau la base existante. Le chantier de données porte alors sur les utilisateurs, les personnalisations, les intégrations et les pièces jointes. Une vraie reprise de données ne s'impose qu'en cas de réimplémentation, de consolidation ou de changement de système.
IBM Maximo Application Suite (MAS) remplace Maximo 7.6 par une plateforme conteneurisée sur Red Hat OpenShift, dont Maximo Manage est l'application centrale. Pour les équipes chargées des données, la question clé est simple : que devient notre base, et que faut-il reprendre ?
Deux chemins : mise à niveau ou réimplémentation
| Mise à niveau de la base | Réimplémentation | |
|---|---|---|
| Principe | La base Maximo 7.6.1 est mise à niveau lors du déploiement de Manage | Manage neuf, données reprises depuis 7.6 ou un autre système |
| Données | Conservées, historique compris | Sélectionnées, nettoyées, rechargées |
| Effort données | Faible à modéré | Important (mapping, nettoyage, répétitions) |
| Quand | Modèle de données toujours adapté | Modèle à revoir, consolidation, données dégradées |
Dans les deux cas, partez d'un état des lieux de la base : volumétrie par objet, attributs ajoutés, personnalisations, intégrations actives et qualité des données de référence.
Préparer la base avant une mise à niveau
- vérifier le niveau de correctif de 7.6.1 requis par la version de Manage visée (consultez la matrice de compatibilité publiée par IBM) ;
- purger ce qui n'a plus d'usage : journaux, messages d'intégration en erreur, transactions anciennes ;
- recenser les objets et attributs ajoutés, les classes Java et les scripts d'automatisation ;
- répéter la mise à niveau sur une copie de la production et mesurer sa durée.
Utilisateurs et sécurité
Dans MAS, l'identité est portée par la suite et synchronisée vers Manage. Les utilisateurs de 7.6 doivent être rattachés à des utilisateurs MAS, alimentés par la console d'administration, par l'API d'administration ou par un annuaire LDAP ou SAML. Les groupes de sécurité de Manage restent, mais l'attribution des droits d'accès aux applications de la suite est un nouveau point à cadrer. C'est souvent le lot le plus sous-estimé d'une migration.
Personnalisations et intégrations
- Classes Java : possibles mais intégrées à l'image de Manage, ce qui pèse sur chaque mise à jour ; les remplacer par des scripts d'automatisation quand c'est possible.
- Intégrations MIF : object structures, enterprise services et points de terminaison sont conservés, mais les URL, certificats et méthodes d'authentification changent. Les appelants externes passent en général à la clé d'API (voir le guide de l'API REST).
- Rapports : à recenser et à retester dans le nouvel environnement.
Pièces jointes (doclinks)
Dans 7.6, les pièces jointes résident en général sur un partage de fichiers du serveur. Dans MAS, elles passent sur un stockage accessible aux conteneurs (volume persistant ou stockage objet). Il faut copier les fichiers et vérifier que les chemins enregistrés dans Maximo pointent vers le nouvel emplacement. Testez l'ouverture d'un échantillon de pièces jointes par type d'objet après la copie.
Quand une reprise de données s'impose
En réimplémentation, le chantier devient une reprise classique : extraction depuis 7.6 (par l'API, des requêtes SQL ou des exports), mapping vers le nouveau modèle, nettoyage, puis chargement dans l'ordre des dépendances. Les guides chantier de reprise de données et data init et ordre de chargement détaillent la démarche. Avantage de la source Maximo : les object structures sont les mêmes de part et d'autre, ce qui simplifie le mapping des objets standard.
Checklist de migration côté données
- Choix du chemin : mise à niveau ou réimplémentation, argumenté par l'état des lieux.
- Base purgée et répétition de mise à niveau chronométrée.
- Utilisateurs rattachés à MAS, synchronisation testée.
- Personnalisations recensées, Java remplacé quand c'est possible.
- Intégrations reconfigurées (URL, certificats, clés d'API).
- Pièces jointes copiées et vérifiées.
- Réconciliation des volumes avant et après, objet par objet.
Questions fréquentes
Faut-il recharger toutes les données pour passer de Maximo 7.6 à MAS 9 ?
Non, pas dans le cas général. Le chemin standard d'IBM met à niveau la base Maximo 7.6.1 existante vers Manage, qui conserve les données. Une reprise de données complète s'impose surtout en cas de réimplémentation (nouveau modèle de données), de consolidation de plusieurs instances ou de changement de GMAO.
Qu'est-ce qui change pour les utilisateurs dans MAS 9 ?
L'identité est gérée par la suite MAS et synchronisée vers Manage. Les utilisateurs doivent exister côté MAS (console d'administration, API ou annuaire LDAP ou SAML), avec leurs droits applicatifs. Prévoyez un lot dédié et testez la synchronisation avant la bascule.
Les personnalisations Java survivent-elles à la migration vers MAS ?
Les classes Java personnalisées restent possibles, mais elles doivent être intégrées à l'image de Manage, ce qui alourdit chaque mise à jour. La plupart des projets en profitent pour remplacer ce qui peut l'être par des scripts d'automatisation et de la configuration.
Quand faire une réimplémentation plutôt qu'une mise à niveau ?
Quand le modèle de données 7.6 ne correspond plus à l'organisation (sites, hiérarchies, classifications), quand les données sont trop dégradées pour être conservées, ou quand plusieurs instances doivent fusionner. On repart alors d'un Manage neuf et on reprend les données utiles.
Charger vos données Maximo sans erreur silencieuse
MAS9 vérifie vos fichiers face à la configuration de chaque environnement, charge en reprise sans doublon après une coupure, puis relit Maximo pour prouver que chaque ligne est arrivée.
Découvrir MAS9