La migration data platform entre dans une nouvelle ère. En octobre 2026, Snowflake, Databricks, Microsoft, EDB et MariaDB ont tous présenté des outils de migration plus automatisés, souvent assistés par l’IA. La conversion du code SQL devient donc plus rapide. Pourtant, une migration reste avant tout un projet base de données. Chez Axians, nous accompagnons nos clients sur ces sujets. Voici ce que ces annonces changent concrètement.
Migration data platform : pourquoi les éditeurs accélèrent
Migrer un entrepôt ou une base vers une data platform a toujours été un chantier lourd. D’abord, il faut inventorier des milliers d’objets : tables, vues, procédures stockées, jobs ETL. Ensuite, il faut traduire un dialecte SQL vers un autre. Enfin, il faut prouver que les résultats restent identiques. Or chaque étape mobilise des experts pendant des semaines.
Pour les éditeurs, c’est aussi un frein commercial. En effet, un client qui redoute la migration reste sur sa plateforme actuelle. C’est pourquoi ils investissent fortement dans l’outillage. Leur message est simple : rejoindre leur plateforme doit devenir facile.
Snowflake AIM : une application dédiée à la migration
Le 20 octobre 2026, Snowflake a lancé l’application Snowflake AIM en préversion publique (blog Snowflake). Elle guide l’utilisateur en six étapes : connexion, initialisation, extraction, conversion, évaluation et migration. Par ailleurs, elle combine un moteur de conversion déterministe et une boucle de correction par IA. Pour une migration data platform vers Snowflake, l’approche devient donc beaucoup plus guidée.
Voici les points qui parlent le plus aux équipes base de données :
- une connexion directe à SQL Server, Oracle, Teradata, Redshift et PostgreSQL ;
- la conversion des packages SSIS et des workflows Informatica vers dbt ou vers des procédures stockées ;
- une validation des données sur trois niveaux : schéma, agrégats, puis comparaison ligne à ligne en option.
Fait notable, Snowflake précise que l’outil vise les migrations les plus courantes. Selon l’éditeur, les partenaires peuvent ainsi se concentrer sur la conduite du changement et sur les patrimoines complexes.
Databricks et Microsoft Fabric industrialisent aussi la conversion
Databricks suit la même voie. Le 15 octobre 2026, son convertisseur de code agentique a atteint la disponibilité générale pour le SQL (notes de version Databricks). Il traduit notamment du T-SQL ou du SQL Oracle, Snowflake, BigQuery et Teradata vers Databricks SQL. De plus, il valide le résultat et corrige les erreurs avant d’écrire les fichiers. Lakebridge, son outil gratuit de migration, complète ce dispositif (page Databricks).
De son côté, Microsoft propose le Migration Assistant de Fabric Data Warehouse (documentation Microsoft). Il prend en charge SQL Server, les pools SQL dédiés Azure Synapse et, en préversion, les métadonnées Teradata. Copilot aide ensuite à corriger les scripts en échec. Toutefois, Microsoft rappelle que la compatibilité T-SQL n’est pas totale. Par exemple, il faut remplacer les comptes SQL par des comptes Microsoft Entra ID. De même, les colonnes IDENTITY se comportent différemment.
Pour la base SQL de Fabric, un second assistant importe le schéma depuis un fichier DACPAC. Attention, ce fichier ne doit pas dépasser 20 Mo (documentation Microsoft).
EDB PostgresAI et MariaDB : la migration côté bases
Le mouvement touche aussi les bases transactionnelles. Le 15 octobre 2026, EDB a publié Hybrid Manager 2026.10.1, brique centrale d’EDB PostgresAI (notes de version EDB). Son Migration Portal suggère désormais une correction par IA quand un objet DDL échoue à l’évaluation. L’utilisateur accepte, modifie ou rejette ensuite la proposition. Deux nouveaux correctifs automatiques traitent aussi des cas Oracle classiques. C’est le cas du mot-clé JOIN utilisé comme nom de colonne.
MariaDB n’est pas en reste. Le 12 octobre 2026, MariaDB Migrator 1.5.0 a atteint la disponibilité générale (notes de version MariaDB). Cet outil automatise les migrations de MySQL 8.0 et 8.4 vers MariaDB. Il propose quatre modes, dont une réplication par binlog pour réduire l’interruption. Surtout, un mode « Assess & Plan » produit un rapport et un plan sans écrire sur la cible.
Enfin, Oracle simplifie lui aussi les montées de version. Annoncée le 23 octobre, la version 19.33 de l’Oracle Database Appliance automatise le passage de 19c à Oracle AI Database 26ai (blog Oracle).
Ce que l’IA ne fait pas à votre place
Ces outils représentent un vrai progrès. Néanmoins, ils traitent surtout le code. Or les difficultés d’une migration data platform se cachent souvent ailleurs :
- Le choix de la cible : Snowflake, Microsoft Fabric, ClickHouse ou StarRocks ne répondent pas aux mêmes usages. Ainsi, un moteur OLAP temps réel ne remplace pas toujours un entrepôt gouverné ;
- La sécurité : rôles, masquage et authentification changent souvent de modèle, comme le montre l’exemple de Fabric ;
- La performance : un code converti fonctionne, mais il n’exploite pas toujours la nouvelle architecture ;
- La coexistence : la bascule impose souvent une période de double run, avec du CDC entre l’ancien et le nouveau système ;
- L’exploitation : une mise à jour peut avoir des effets de bord. Par exemple, EDB prévient que la mise à jour vers Hybrid Manager 2026.10 redémarre tous les clusters Postgres gérés.
Autrement dit, l’IA accélère la traduction. En revanche, elle ne décide ni de l’architecture, ni du calendrier, ni du risque acceptable. Pour la phase de coexistence, notre article sur l’ingestion temps réel détaille les mécanismes de CDC.
Réussir votre migration data platform en cinq étapes
Avant de lancer les outils, une migration data platform se prépare. Nous conseillons de suivre cinq étapes :
- Inventorier le patrimoine : objets, volumes, dépendances et usages réels. Les modes d’évaluation des outils aident beaucoup à ce stade.
- Choisir la cible selon les usages, et non selon l’outil de migration le plus pratique.
- Lancer un pilote sur un périmètre représentatif, avec quelques procédures stockées complexes.
- Valider les données à plusieurs niveaux, puis comparer les performances.
- Préparer l’exploitation : supervision, sauvegardes, maîtrise des coûts et montée en compétence.
Par ailleurs, la place de Postgres dans ces plateformes mérite votre attention. Nous l’expliquons dans notre article Postgres data platform.
Axians vous accompagne dans votre migration data platform
Les outils de migration n’ont jamais été aussi puissants. Snowflake, Databricks, Microsoft, EDB et MariaDB automatisent désormais une grande partie de la conversion. Cependant, la réussite dépend toujours d’une bonne connaissance des bases sources et de la cible.
C’est justement le cœur de notre métier. Les équipes Axians accompagnent leurs clients à chaque étape. D’abord en conseil, pour cadrer l’architecture et choisir la plateforme. Ensuite en build, pour migrer vers Snowflake, Microsoft Fabric, ClickHouse, StarRocks ou EDB PostgresAI. Nous proposons aussi un service managé pour exploiter vos plateformes au quotidien. Enfin, nos formations aident vos équipes à prendre la main. Vous préparez une migration data platform ? Parlons-en.