OmnIA Data Migrator, la migration de données BI et ETL par l’IA
OmnIA Data Migrator est la plateforme de migration de données de Harington. Elle cartographie votre patrimoine BI, ETL et Data, elle vous aide à identifier ce qui doit vraiment être migré, puis elle effectue la migration vers la cible de votre choix, preuve à l’appui pour chaque objet. Elle est opérée avec vos équipes, puis transférée chez vous.
OmnIA Data Migrator est une plateforme qui inventorie, rationalise et migre vos rapports, vos traitements ETL et votre code data, avec l’IA et sous contrôle humain.
- Ce qu’elle migreBusinessObjects, MicroStrategy, SSRS, DataStage, Talend, ODI, SAS, PL/SQL et flux EDI, vers Power BI, Microsoft Fabric, Snowflake, dbt, Strategy One ou SSIS.
- CommentL’IA écrit les programmes de migration, puis ces programmes migrent votre parc. Même entrée, même sortie : la migration est rejouable et vérifiable.
- RéférencesSaint-Gobain : centre d’excellence Data & IA, 32 000 rapports MicroStrategy analysés, 16 000 à migrer vers Snowflake. Un GIE bancaire : Migration as a Service boostée à l’IA, de DataStage vers PL/SQL et dbt.
- GarantiesVos modèles d’IA, votre cloud, vos dépôts git. Plateforme, règles, code et preuves vous sont transférés.
Pourquoi migrer maintenant ? Ce sont les éditeurs qui imposent le calendrier.
Vos outils de BI et d’intégration de données arrivent en fin de support. Passée cette date, plus aucun correctif de sécurité ne sera publié, votre dette technique va se creuser et il deviendra difficile de justifier la conformité de vos systèmes face à DORA et NIS2.
| Échéance | Outils concernés |
|---|---|
| 31/12/2026 | SAP BusinessObjects 4.3 et Data Services 4.3 |
| Décembre 2026 | Talend 7.3 et Oracle ODI 12c |
| Décembre 2026 | MicroStrategy Developer et Object Manager |
| Fin 2027 | SAP BW 7.5 et Jaspersoft 9 |
| Dès 2025 | SSRS n’est plus inclus dans SQL Server 2025 |
Dates communiquées par les éditeurs, à vérifier selon vos contrats de support.
Pour BusinessObjects, le sujet n’est pas « BO va-t-il disparaître ? » car SAP propose une montée de version, mais elle se fera sous contrainte de calendrier. Ainsi, le vrai sujet est de savoir si vous voulez monter de version dans l’urgence, ou profiter de cette échéance pour sortir du legacy.
Pourquoi les migrations BI et ETL dérapent ?
Dans la plupart des DSI, la liste exacte du parc n’existe pas. Des milliers de rapports et de traitements ETL se sont accumulés au fil des année. Certains ne sont plus utilsés, d’autres existent en plusieurs versions et le même indicateur est souvent calculé de deux façons différentes. Les experts BusinessObjects, DataStage ou MicroStrategy qui connaissaient ces règles ont souvent disparu du paysage ou ils sont difficiles à trouver.
Une migration menée sans cet inventaire déplace le problème au lieu de le résoudre. On support le coût de la migration de rapports que plus personne ne consulte, et les écarts de chiffres n’apparaissent qu’après la mise en production.
Comment fonctionne OmnIA Data Migrator ? Explorer, décider, migrer, prouver
1. Explorer : la catographie complète du parc
La plateforme lit toutes vos métadonnées (tables, traitements, modèles et rapports) et établit une carte avec :
- L’inventaire des rapports, traitements, tables et règles de gestion
- La structure : domaines, couches et dépendances
- Les doublons, c’est-à-dire les variantes d’un même objet
- Les liens orphelins, qui pointent vers des objets disparus
- Les objets isolés que plus rien n’utilise
- Les incohérences comme un indicateur calculé de deux façons différentes
- L’effort : Ce qui peut être migré automatiquement et ce qui doit faire l’objet d’un arbitrage
La plateforme rétro-documente aussi votre patrimoine. Vous récupérez ainsi une documentation à jour, écrite à partir de l’existant.
2. Décider : un périmètre fondé sur des faits
Pour chaque objet, vos équipes choisissent de migrer, convertir, refondre ou retirer. Chez Saint-Gobain, cette rationalisation a ramené un parc de 32 000 rapports à 16 000 rapports à migrer.
3. Migrer : l’IA écrit les programmes, les programmes migrent votre parc
C’est le cœur de la méthode Harington et ce qui la distingue d’une migration « par IA » classique.
À la conception
L’IA écrit le code de migration
Elle analyse le parc et sa documentation, puis écrit les adaptateurs qui lisent chaque source, les règles de correspondance et les générateurs qui écrivent pour la cible.
Un expert relit et valideAu milieu
Un modèle pivot unique
Toutes les sources sont traduites dans un même modèle, versionné et rejouable, puis converties vers la cible. C’est le tableau de correspondance entre votre legacy et vos nouvelles plateformes.
Versionné et rejouableÀ l’exécution
Une migration déterministe
Rapports, traitements et données sont produits par programme. L’IA n’intervient que sur le reste à traiter, et chaque intervention est journalisée.
Même entrée, même sortie4. Prouver : la vérification objet par objet
Pour chaque objet, la source et la cible sont comparées sur les mêmes données. Les écarts sont expliqués et un tableau de bord suit l’avancement et la qualité de la migration objet par objet. L’IA n’entre jamais dans le calcul du score de qualité. Chaque migration est enregistrée dans git et vos équipes valident chaque bascule.
Migration manuelle, quelle est la différence entre un outil de conversion et OmnIA Data Migrator ?
| Migration manuelle | Outil de conversion d’un éditeur cloud | OmnIA Data Migrator | |
|---|---|---|---|
| Inventaire du parc | Partiel, sur tableur | Absent | Radiographie complète, avec doublons et objets inutilisés |
| Périmètre | Tout est migré | Tout est converti | Décidé objet par objet : migrer, convertir, refondre, retirer |
| Production | À la main, rapport par rapport | Conversion automatique, partielle | L’IA écrit les programmes, les programmes migrent |
| Preuve | Recette par échantillon | Limitée | Source et cible comparées pour chaque objet |
| Cible | Au choix | Imposée : la plateforme de l’éditeur | Au choix |
| À la fin du projet | Une documentation à refaire | Une dépendance à l’éditeur | Plateforme, règles, code et preuves transférés chez vous |
Les technologies couvertes
Chaque type de migration a sa brique, et toutes partagent le même modèle pivot.
Vos sources
Vos cibles
- Migrator BO, de SAP BusinessObjects vers Power BI et Fabric. Il lit univers, rapports, captures et PDF, génère le modèle, les rapports et la sécurité, livre par git avec un score par rapport et rétro-documente univers et rapports.
- Strat Migrator, de MicroStrategy vers Snowflake et Strategy One. Il s’appuie sur un moteur de règles et de correspondances, mesure la couverture de chaque rapport, migre par lots de 500 rapports et rationalise le parc avant de migrer.
- DataStage Migrator, de DataStage vers PL/SQL ou dbt. Il génère les traitements cibles, retrace les flux de données et vérifie la parité entre source et cible.
- EDI Migrator, pour les flux EDI à la documentation dispersée. Des agents proposent le mapping, un agent critique le conteste et un humain arbitre. Chaque flux a son dossier de preuves et sa rétro-documentation.
- BI Studio, pour exploiter et améliorer un parc Power BI existant. Il crée un visuel à partir d’une capture d’écran, répond aux questions en langage naturel, optimise les formules DAX avec retour arrière possible et pilote la sécurité et les actualisations.
Extrait de références : Saint-Gobain et un GIE bancaire
Saint-Gobain, 32 000 rapports MicroStrategy rationalisés, puis migrés vers Snowflake
Référence client
Saint-Gobain
Migration MicroStrategy vers Snowflake | Strat Migrator
L’enjeu
Un parc de 32 000 rapports MicroStrategy sur SAP HANA, à migrer vers la nouvelle plateforme data du groupe, OneData, sur Snowflake.
Ce que nous avons fait
La mise en place d’un centre d’excellence Data & IA, qui pilote la practice data et IA du groupe. Dans ce cadre, le parc a été rationalisé en regroupant les rapports similaires (clustering), puis migré par lots avec Strat Migrator.
32 000→16 000
Rapports à migrer après rationalisation : la moitié du parc n’avait pas besoin d’être migrée.
9 000
Rapports déjà migrés vers Snowflake.
90 %
D’accélération sur la production du code des rapports, une fois le mapping établi.
Un GIE bancaire, une Migration as a Service boostée à l’IA pour DataStage
- L’enjeu : sortir d’IBM DataStage sur un large parc de traitements ETL, vers deux cibles selon les besoins.
- Ce que nous avons fait : la mise en place d’une Migration as a Service boostée à l’IA. Un service de migration à la demande qui convertit les traitements DataStage vers PL/SQL d’une part et vers dbt d’autre part.
Maîtrise, souveraineté, réversibilité : vos garanties
Gouvernée. Vos équipes décident du périmètre et signent chaque bascule. La plateforme génère et prouve, l’IA ne note jamais son propre travail. La migration suit six étapes, de l’inventaire à la bascule, avec un point de contrôle à chaque étape.
Ouverte. OmnIA Data Migrator est agnostique, vous choisissez vos modèles d’IA et votre infrastructure (Azure, Google Cloud ou vos propres serveurs), avec un déploiement en conteneurs Docker.
Transférée chez vous. Nos consultants installent la plateforme, la règlent et conduisent les premières vagues de migration. Vos équipes valident les règles, puis reprennent la plateforme. La plateforme, les règles, le code et les preuves restent dans vos dépôts git.
Premières vagues
Harington opère
Montée en compétence
Harington et vos équipes copilotent
Ensuite
Vos équipes opèrent
Plateforme, règles, code et preuves restent chez vous : vous continuez sans nous.
Combien coûte une migration avec OmnIA Data Migrator ?
La migration est menée au forfait ou en unités d’œuvre, par exemple au rapport ou au traitement migré. Le périmètre et le prix sont fixés après la cartographie.
Par où commencer
- 1Voir
Une démo guidée de la plateforme sur un cas réel.
- 2Essayer
Un pilote de 4 à 6 semaines sur un lot de votre parc : radiographie, migration et preuve.
- 3Industrialiser
La migration du reste du parc par vagues.
Pourquoi Harington
Harington est une ESN française indépendante de 450 consultants. Elle figure au classement FT1000 2026 du Financial Times, et ses sites sont certifiés ISO 9001, 27001 et 27701. Son expertise Data & IA accompagne les entreprises depuis 2017. OmnIA Data Migrator s’inscrit dans sa chaîne AI-Augmented delivery, aux côtés de Harry SDLC (développement logiciel agentique) et de Harry Sec (gestion des vulnérabilités).
Questions fréquentes sur la migration de données BI et ETL
OmnIA Data Migrator est la plateforme de migration de données de Harington. Elle cartographie un patrimoine BI, ETL et data, aide à décider ce qui doit migrer, puis le migre vers la cible choisie en prouvant chaque objet. Elle est opérée avec les équipes du client, puis lui est transférée.
En source : SAP BusinessObjects, MicroStrategy, SSRS, IBM DataStage, Talend, Oracle ODI, SAS, PL/SQL, SQL et flux EDI. En cible : Power BI, Microsoft Fabric, Snowflake, dbt, PL/SQL, SSIS et Strategy One.
Avec la brique Migrator BO, la migration commence par l’inventaire des univers et des rapports, puis la rationalisation du parc. La plateforme génère ensuite le modèle Power BI, les rapports et la sécurité, livre le tout par git et attribue un score de qualité à chaque rapport migré.
L’IA écrit les programmes de migration, qui sont relus et validés par des experts. Ce sont ensuite ces programmes qui migrent le parc, de façon déterministe : la même entrée donne toujours la même sortie. Chaque objet est vérifié en comparant la source et la cible sur les mêmes données, et l’IA n’intervient jamais dans le calcul du score.
Non. La cartographie révèle les doublons, les objets inutilisés et les incohérences. Chez Saint-Gobain, la rationalisation a ramené un parc de 32 000 rapports à 16 000 rapports à migrer.
Oui. La plateforme se déploie sur votre infrastructure (Azure, Google Cloud ou sur site), avec les modèles d’IA de votre choix. Les règles, le code et les preuves restent dans vos dépôts git, et la plateforme vous est transférée à la fin du projet.
Glossaire
- Migration de données : le transfert de données, de traitements et de rapports d’un système source vers un système cible.
- ETL (Extract, Transform, Load) : les traitements qui extraient, transforment et chargent les données, par exemple avec DataStage, Talend ou ODI.
- Rationalisation : le tri du parc avant migration pour ne garder que ce qui sert.
- Modèle pivot : le modèle commun dans lequel toutes les sources sont traduites avant d’être converties vers la cible.
- Rétro-documentation : une documentation reconstruite à partir de l’existant.
En savoir plus
Webinar le mardi 8 décembre, de 11h30 à 12h30 : l’état de l’art du développement agentique et une démo en direct de Harry SDLC, la software factory agentique de Harington, souveraine, agnostique et sous contrôle humain. Gratuit, en ligne sur Teams.
Claude Code, Cursor ou GitHub Copilot : lequel choisir en entreprise ? Comparatif des trois outils (agents, modèles, offres entreprise, données), ce que disent les études de productivité, et pourquoi le cadre compte plus que l’outil.
Qu’est-ce que le SDLC, et comment l’IA change-t-elle le cycle de développement logiciel ? Définition, différences avec un copilote de code, et les 6 phases d’un SDLC augmenté par l’IA, avec une gate de contrôle à chaque transition.