La migration d’un datawarehouse SQL Server vers Snowflake est le projet que 75% des organisations data planifient ou ont déjà lancé en 2026. Et selon McKinsey, 75% de ces migrations dépassent leur budget. Ce n’est pas une fatalité — c’est la conséquence d’erreurs évitables qu’on peut anticiper avec la bonne méthodologie.
Pourquoi Snowflake et pas Fabric ?
Avant de parler méthode, clarifions le choix de la cible. Snowflake et Fabric sont deux excellentes plateformes, mais elles répondent à des besoins différents. Snowflake est le choix privilégié quand l’organisation veut une indépendance vis-à-vis d’un cloud provider unique (Snowflake tourne sur AWS, Azure et GCP), quand les volumes de données sont importants avec des besoins d’élasticité fine du compute, ou quand l’équipe data préfère travailler en SQL pur avec DBT.
Fabric est le choix naturel pour les organisations déjà profondément intégrées dans l’écosystème Microsoft (Azure AD, Power BI, Teams). Le modèle de licence par capacité est aussi plus simple à budgéter pour certaines DSI.
Si vous hésitez encore, l’audit de votre patrimoine existant vous donnera les éléments objectifs pour trancher.
Scanner automatisé, cartographie complète des objets
Classifier : migrer, conserver ou décommissionner
Convertisseur propriétaire T-SQL → Snowflake SQL
Run parallèle ancien / nouveau, diff automatisé
Cutover par vagues + hyper-care dédié
Phase 1 : L’inventaire exhaustif
Toute migration commence par un inventaire de ce qui existe. Et c’est précisément là que la plupart des projets dérapent. L’inventaire manuel (« on fait le tour des équipes pour lister ce qu’elles utilisent ») est toujours incomplet, toujours biaisé, et toujours trop long.
L’approche par rétro-ingénierie est fondamentalement différente. On analyse le code source — les fichiers DTSX des packages SSIS, les scripts T-SQL des procédures stockées, les définitions des jobs SQL Server Agent — pour reconstituer la cartographie complète de l’environnement. Le scanner ne « demande » rien à personne : il lit le code et en déduit les faits.
Ce qu’il produit : le nombre exact de packages, les dépendances entre eux, les tables sources et destinations, les transformations appliquées, les variables d’environnement, et un score de dette technique pour chaque composant.
Phase 2 : Le tri stratégique
L’inventaire révèle presque toujours des surprises. Dans notre expérience, 15 à 25% du patrimoine SSIS est obsolète — des packages qui tournent encore mais dont les résultats ne sont plus consommés par personne. Les décommissionner avant la migration réduit immédiatement le périmètre et le budget.
Les composants restants sont classés en trois catégories : convertibles automatiquement (les cas standards — data flows avec des sources, transformations et destinations classiques), convertibles avec reprise manuelle (les cas complexes — T-SQL dynamique, curseurs, Script Tasks en C#), et à ré-architecter (les cas où la logique elle-même doit changer pour tirer parti de Snowflake).
Phase 3 : La conversion
La conversion automatisée est le levier qui change l’économie du projet. Plutôt que de faire réécrire chaque package à la main par un consultant, le convertisseur parse le DTSX, extrait la logique métier, et génère le code équivalent en modèles DBT et en SQL Snowflake.
Le taux de conversion automatique varie selon la complexité du patrimoine. Sur les projets que nous avons réalisés, il se situe entre 60% et 80%. Les 20 à 40% restants nécessitent une intervention manuelle — mais le convertisseur fournit un squelette commenté qui accélère considérablement le travail.
Point clé : la conversion n’est pas un lift-and-shift. Un bon convertisseur ne reproduit pas la logique SSIS à l’identique — il la traduit en idiomes DBT natifs (modèles incrémentaux, tests intégrés, documentation auto-générée). Le résultat est du code cloud-native, pas du code legacy déguisé.
Phase 4 : La validation parallèle
C’est la phase la plus sous-estimée et pourtant la plus critique. Le principe : faire tourner l’ancien et le nouveau système en parallèle pendant 2 à 4 semaines et comparer les résultats ligne à ligne.
Chaque écart est classé en trois catégories : bug de conversion (le code généré a un problème), différence de comportement attendue (Snowflake gère certaines opérations différemment de SQL Server — arrondis, gestion des NULL, collation), ou bug préexistant dans le legacy (le système historique avait une erreur que personne n’avait détectée).
Ce dernier cas est plus fréquent qu’on ne le croit. Sur un projet récent, nous avons découvert 2 erreurs de calcul présentes dans le legacy depuis des années. La migration les a révélées parce que les tests automatisés DBT vérifiaient des invariants que personne n’avait jamais formalisés.
Phase 5 : La bascule et l’hyper-care
La bascule se fait par vagues — jamais en big bang. Chaque lot (typiquement 20 à 50 composants) est basculé en production après validation. L’ancien système reste actif en read-only pendant 2 semaines (hyper-care) pour permettre un rollback immédiat en cas de problème.
Le transfert de compétences aux équipes internes est réalisé pendant cette phase. L’avantage de DBT est que le code est du SQL standard versionné sous Git — n’importe quel analyste SQL peut le lire et le modifier, contrairement aux packages SSIS qui nécessitent Visual Studio et une expertise spécifique.
Ordres de grandeur
Pour calibrer vos attentes, voici les ordres de grandeur que nous observons en pratique. Un patrimoine de 100 à 200 packages SSIS de complexité moyenne se migre en 6 à 10 semaines. Un patrimoine de 200 à 500 packages en 10 à 16 semaines. Au-delà, la durée dépend fortement de la complexité des procédures stockées et du volume de logique métier non documentée.
En termes de budget, la conversion automatisée réduit le coût de 2 à 3 fois par rapport à une réécriture manuelle. L’audit préalable réduit le périmètre de 15 à 25%. Combinées, ces deux approches rendent le forfait possible — le client connaît le budget total avant de commencer.
Vous préparez une migration ? Demandez un audit gratuit pour obtenir une estimation ferme basée sur votre patrimoine réel, pas sur des moyennes du marché.