Les limites de SSIS : porter les packages dans le cloud déplace la dette, pas le problème

SSIS a fait tourner l’entrepôt SQL Server pendant vingt ans et il a le parc qui va avec. La question en 2026 n’est pas de savoir s’il faut le quitter mais comment, et la réponse par défaut, une VM ou un Azure-SSIS Integration Runtime qui exécute les packages tels quels, déplace le parc sans toucher à aucune des trois choses qui le rendent coûteux.

Trois problèmes qu’une VM ne résout pas

• La dette de packages. Des centaines de packages, un par table, construits par de nombreuses mains, ouverts un à la fois. Voir l’article sur la dette de packages.
• Le déploiement. Du XML qui se merge mal, des mappings d’environnement SSISDB maintenus à la main, et des releases dont on ne sait qu’à la première exécution planifiée si elles fonctionnent. Voir l’article sur le déploiement et le CI/CD.
• La frontière de la plateforme. Conçu pour aller de SQL Server à SQL Server ; tout le reste est un connecteur, un serveur plus gros ou une réécriture. Voir l’article sur SSIS au-delà de SQL Server.

Le lift and shift emmène les trois dans le cloud intacts. Une VM est une infrastructure que vous gérez ; l’Azure-SSIS Integration Runtime est un cluster managé à l’intérieur de Data Factory avec un tarif horaire. Les packages sont les mêmes packages sur l’un comme sur l’autre. La destination de Microsoft elle-même, Fabric Data Factory, est un nouveau canvas, ce qui revient à reconstruire le parc à la main.

Ne recréez pas le problème dans le cloud

Une migration est le seul moment où tout le parc est de toute façon sur la table. Le consacrer à réhéberger des chargements construits à la main, c’est arriver dans le cloud avec un package par table, une difficulté de merge et une conception qui s’arrête toujours à une seule plateforme. Le consacrer à un modèle donne autre chose :

• Une migration plus rapide. Les sources sont mappées à partir de leurs clés métier, et non traduites package par package. Les anciens packages continuent de tourner jusqu’à ce que chaque source soit mappée, donc il n’y a pas de bascule brutale.
• Moins de problèmes ensuite. Pas d’historisation écrite à la main, pas de package que seul son auteur comprend, pas de table de mappings d’environnement. Les chargements générés ont tous la même structure.
• Une solution pérenne. Le même modèle génère pour SQL Server, Azure SQL et Fabric, et pour Snowflake, Databricks ou BigQuery si cette décision est un jour prise. Le prochain changement de plateforme est un changement de cible.

Ce qui change avec Datavault Builder

Datavault Builder décrit l’entrepôt dans un modèle visuel et en génère les chargements de staging, de vault et de livraison, avec le déploiement, le rollback, la documentation et le lineage, nativement sur SQL Server, Azure SQL et Fabric.

• Les packages sont retirés, pas réhébergés. Chaque source mappée est un package qui n’a plus besoin d’un serveur, ni on premises ni dans Azure.
• Les releases sont générées, rollback inclus. Une comparaison de deux états, les différences que vous choisissez, et les dépendances proposées pour chacune. Pas de .ispac, pas de mappings SSISDB.
• Les chargements s’exécutent dans le moteur. Du SQL delta ensembliste dans SQL Server ou Fabric. Pas de machine ETL, pas de buffer de data flow, pas de licence supplémentaire.
• Les sources se connectent directement. En batch, en delta et en CDC depuis des bases, des fichiers, des API REST, des sources NoSQL et Python, avec des flux comme Kafka traités en micro batches.
• La plateforme reste votre choix. Modernisez l’ETL sur SQL Server maintenant, déplacez la cible vers Fabric quand vous serez prêt, et gardez la porte ouverte vers n’importe quel autre entrepôt.

Par où commencer

Dressez deux listes : les packages qui ne font que charger une table vers le staging ou l’entrepôt, et les packages dont la cible est la plateforme qui déménage. La première est ce qu’un modèle devrait générer. La seconde est ce que le portage emmènerait tel quel. Commencez là où les deux se recoupent. Si les packages tournent déjà sur un Azure-SSIS Integration Runtime, ajoutez ses heures de nœuds par mois à côté de la seconde liste. C’est le prix de la conservation de la dette.