Migration legacy → cloud data platform : Teradata, Exadata, SAS vers Snowflake, BigQuery, Databricks

Sortir d'un Teradata vieux de 15 ans, d'un Exadata onéreux, ou d'un legacy SAS qui maintient en vie des centaines de jobs critiques — c'est l'un des projets les plus risqués et les plus stratégiques d'une DSI. Mal cadré, il dure 3 ans, double de budget, et finit par cohabiter avec le legacy qu'il devait remplacer. Bien cadré, il libère 30 à 60 % de la facture data, accélère l'innovation et rend l'écosystème moderne. Voici la méthodologie qui structure ces programmes.

Pourquoi migrer

Les drivers récurrents :

• Coûts : licences legacy (Teradata, Exadata) très élevées, support qui s'envole, hardware en fin de vie.
• Élasticité : besoin de pics (Black Friday, clôtures, IA générative) que le legacy ne sert pas.
• Talents : difficulté croissante à recruter sur Teradata, PL/SQL, SAS legacy.
• Innovation : impossibilité de brancher l'écosystème moderne (dbt, ML, streaming, lakehouse, IA).
• Conformité : besoin de gouvernance moderne (catalog, lineage, access policies).

Choix de la cible

Cible	Profil typique	Forces
Snowflake	Analytics, BI, partage de données	Simplicité d'exploitation, time-to-value, écosystème
BigQuery	Analytics + IA Google Cloud	Serverless, ML intégré, intégration GCP
Databricks	Lakehouse, data engineering, ML	Spark, Delta/Iceberg, MLOps, multi-cloud
Microsoft Fabric	Stack Microsoft / Power BI dominante	Intégration Azure / 365, OneLake
Multi-platform	Grands comptes avec besoins hétérogènes	Best-of-breed, complexité accrue

Le choix dépend de la stratégie cloud globale, des compétences internes, du périmètre (BI seul vs lakehouse + ML), de la maturité gouvernance. Voir aussi Iceberg vs Delta vs Hudi pour l'angle format.

Méthodologie en 7 phases

Phase 1 : assessment

• Inventaire complet : tables, vues, jobs, scripts, dashboards, modèles ML, usages.
• Mesure de la consommation réelle (utilisateurs actifs, requêtes par dataset, dashboards utilisés).
• Cartographie des dépendances applicatives (qui consomme quoi).
• Identification des données mortes (souvent 20-40 % des datasets ne sont plus consultés).

Phase 2 : business case

• Coûts actuels vs coûts cibles à l'horizon 3 et 5 ans.
• Bénéfices qualitatifs (time-to-market, talents, écosystème).
• Risques pondérés (durée projet, perte de données, indisponibilité).
• Modèles de financement : full one-shot, gradual, hybrid.

Phase 3 : architecture cible

• Choix de la plateforme cible et des patterns (warehouse vs lakehouse, multi-engine).
• Couche transformation (dbt, Spark, SQL stored procs converties).
• Couche gouvernance (catalog, lineage, access).
• Ingestion moderne (Fivetran, Airbyte, CDC).
• Coexistence legacy / cible pendant la migration (CDC ou batch sync).

Phase 4 : stratégie de migration

Stratégie	Description	Quand l'utiliser
Lift & shift	Reproduire à l'identique	Mauvaise idée 9 fois sur 10 (on déplace la dette)
Replatform	Migrer + adaptation minimale	Cas simples, time-to-market critique
Refactor	Migration + redesign (modélisation, dbt)	Recommandé pour la majorité
Rebuild	Réécrire from scratch	Domaines à forte dette, nouveau modèle métier

Phase 5 : exécution par vagues

• Découper en domaines fonctionnels (Finance, Supply, Marketing, etc.).
• Pour chaque vague : migrer données, transformations, dashboards, jobs, ML.
• Tests parallèles : exécuter legacy et cible en parallèle, comparer les résultats.
• Cutover par domaine.

Phase 6 : décommissionnement

• Couper les flux source vers le legacy.
• Archiver les données froides.
• Éteindre le legacy (souvent l'étape qui débloque vraiment les économies).

Phase 7 : modernisation continue

• Mettre en place gouvernance moderne (data catalog, data observability, data contracts).
• FinOps en continu (FinOps de la donnée).
• Roadmap analytics engineering (dbt).

Outils d'aide à la migration

Catégorie	Outils
Transpilation SQL	SQLMesh, datafold, native scripts éditeurs Snowflake/Databricks/BigQuery
Conversion stored proc	Outils éditeurs + revue manuelle
Conversion SAS	WPS, Refactor automatique → Python/SQL, partenaires spécialisés
Ingestion	Fivetran, Airbyte, CDC (Debezium)
Tests de parité	datafold, Great Expectations, comparaisons checksum
Migration assistée IA	Outils émergents (Snowflake Cortex, GitHub Copilot, partenaires spécialisés)

L'IA générative aide à traduire PL/SQL → SQL Snowflake / Spark SQL avec un gain de productivité significatif, mais ne dispense pas d'une revue stricte (sémantique, performance).

Pièges les plus fréquents

• Lift & shift : on garde la dette legacy sur la nouvelle plateforme, économies décevantes.
• Ne pas couper le legacy : double facture sur 2-3 ans.
• Sous-estimer la conversion des jobs (SAS, PL/SQL, stored procs ETL).
• Ignorer les dashboards : on migre les données, les dashboards Power BI / Tableau cassent silencieusement.
• Aucune gouvernance mise en place dans la nouvelle plateforme → on recrée le bazar plus rapidement.
• Pilotage trop technique : le métier doit valider chaque domaine cutover.
• Tests insuffisants : reconciliation incomplète, données fausses en prod.
• Skip l'observability : impossible de prouver que la cible fonctionne aussi bien que la source.

ROI réel

Levier	Gain typique
Licences legacy	-50 à -80 %
Infrastructure (datacenter, support)	-30 à -60 %
Coûts compute (post-FinOps)	Variable, souvent -10 à -30 % vs estimation initiale si FinOps mature
Time-to-market projet data	-30 à -60 %
Innovation (ML, IA, lakehouse)	Difficilement chiffrable mais structurant

ROI complet typiquement atteint en 18 à 36 mois sur les programmes bien menés.

Profils mobilisés

• Architecte data : pilote la cible et la stratégie.
• Data Engineer cloud : exécute la migration des pipelines.
• Data Engineer legacy : connaît l'existant (Teradata, SAS, PL/SQL).
• Analytics Engineer : pose la couche dbt moderne.
• Data Steward / Owner métier : valide la parité fonctionnelle.
• Chef de projet / programme : pilote les vagues et coordonne.
• FinOps engineer data : structure la maîtrise des coûts dès le départ.

Indicateurs TJM marché :

Profil	TJM EUR/jour
Data Engineer migration (3-5 ans)	600–750 €/jr
Senior migration (10+ ans, multi-plateformes)	750–950 €/jr
Architecte programme migration	950–1200 €/jr

Voir TJM consultant IT.

Conclusion : un programme, pas un projet

Migrer un legacy data, ce n'est pas un projet technique de 6 mois — c'est un programme de 18 à 36 mois qui combine assessment, redesign, exécution disciplinée par vagues, gouvernance moderne et FinOps. Les organisations qui réussissent traitent la migration comme une opportunité de modernisation, pas comme un copier-coller cloud. Celles qui échouent transportent leur dette d'un environnement à l'autre — avec une nouvelle facture, mais les mêmes problèmes.

Pour aller plus loin :

• Iceberg vs Delta vs Hudi : open table formats
• FinOps de la donnée
• Data Mesh en pratique
• dbt & analytics engineering
• Data catalog moderne & lineage

ForTeam IT positionne des architectes data, data engineers cloud, analytics engineers et chefs de programme sur des migrations Teradata, Exadata, SAS vers Snowflake, BigQuery, Databricks. Si c'est votre terrain, vous êtes au bon endroit.

Rejoindre ForTeam IT