Sortir de BizTalk Server et migrer vers Azure Logic Apps.

Microsoft a annoncé la fin du support standard de BizTalk Server 2020 pour janvier 2030, avec support étendu jusqu'à avril 2031. La roadmap officielle Microsoft positionne Azure Logic Apps comme successeur désigné. Les clients qui n'auraient pas migré d'ici 2030 continueraient à faire fonctionner BizTalk mais sans mises à jour de sécurité ni évolutions fonctionnelles. Le conseil typique donné aux DSI : viser la migration complète avant fin 2028 pour se ménager une année de marge face aux aléas.

La migration progressive est recommandée et techniquement faisable. Les deux plateformes coexistent facilement grâce à Azure Service Bus qui peut servir de pont de messagerie. Chaque orchestration est migrée indépendamment, testée en double run avec BizTalk pendant deux à quatre semaines, puis la version BizTalk est décommissionnée. Cette approche étale le risque et permet aux équipes de monter en compétences Azure progressivement. Attention à ne pas trop étaler la transition — une coexistence qui s'éternise devient coûteuse.

Les maps .btm BizTalk sont composées en interne de XSLT plus de fonctoïds Microsoft. Dans Logic Apps Standard, il existe un Data Mapper Visual Studio Code qui peut importer directement les maps .btm et les convertir en maps Logic Apps, en préservant la logique XSLT. Pour les fonctoïds complexes (Concat, DateTime, Looping, Database) qui n'ont pas d'équivalent direct, nous les réimplémentons en Azure Functions appelées depuis le mapper. Nous avons validé ce pattern sur les fonctoïds 107 Concat et 125 DateTime lors de notre POC.

Oui, pour les adaptateurs majeurs. Logic Apps propose plus de mille connecteurs natifs ou via Azure Service Bus, couvrant SAP (via connecteur SAP dédié), SWIFT (via connecteurs bancaires), FTP/SFTP (natif), IBM MQ et Kafka (via connecteurs Service Bus). Les adaptateurs plus exotiques (HL7 pour santé, EDI X12/EDIFACT pour B2B) sont disponibles dans Azure Integration Services. Seuls les adaptateurs très spécifiques ou sur-mesure peuvent nécessiter une réécriture en Azure Functions.

L'effort dépend surtout du nombre d'orchestrations, de la complexité des maps et du volume de flux inter-applicatifs. À titre de repère, un parc BizTalk comportant trente à cinquante orchestrations avec deux cents à trois cents maps se migre typiquement en dix à quinze mois avec un budget de un à deux millions d'euros en co-delivery nearshore, incluant tests de parité et décommissionnement de l'ancien. Pour un parc très large (cent orchestrations et plus), comptez un programme pluriannuel et un budget de deux à cinq millions d'euros.

Trois gains typiques : réduction des coûts d'infrastructure (plus de serveurs BizTalk à maintenir, plus de licences SQL Server dédiées), élasticité automatique (Logic Apps s'adapte à la charge sans intervention), et observabilité native (logs et métriques directement dans Azure Monitor). En pratique nos clients constatent une baisse des coûts TCO de quarante à soixante pour cent sur l'infrastructure d'intégration après deux à trois ans, et une forte réduction du temps d'analyse d'incident grâce à la télémétrie intégrée.

Microsoft a positionné Azure Integration Services (AIS) comme le successeur spirituel de BizTalk Server. AIS n'est pas un produit unique — c'est une famille : Azure Logic Apps pour les workflows et orchestrations (le plus proche analogue des Orchestrations BizTalk), Azure Service Bus pour le messaging, Event Grid pour les événements, API Management pour les passerelles, Data Factory pour le batch et l'ETL. Le support principal de BizTalk Server 2020 se termine en 2030, avec support étendu jusqu'en 2030 également — aucune nouvelle version majeure n'est planifiée. Pour les organisations sur BizTalk 2010 ou 2016, la décision upgrade-ou-migrer est désormais urgente. La méthodologie ATLAS encadre la migration BizTalk vers AIS avec préservation des contrats d'interface et audit de parité. Voir le parcours BizTalk vers Azure.

Cela dépend du nombre et de la complexité des orchestrations, du nombre de partenaires et d'adaptateurs, et des volumes de données. Un point compte davantage que le volume brut : la part d'orchestrations réellement encore actives. Sur la plupart des parcs BizTalk, une fraction significative des flux n'a plus d'usage, et la reprise mécanique reconstruit dans le cloud un existant que personne n'a réexaminé. L'Intake commence par cette mesure. Cadrage initial gratuit, de 30 minutes à 2 heures.

Cinq pratiques que nous appliquons systématiquement. (1) Inventaire avant tout code — chaque orchestration, chaque map, chaque adaptateur, chaque schéma, chaque règle métier, avec dépendances cartographiées et propriétaires identifiés. (2) Tests de caractérisation sur jeux de messages réels — capturer les entrées-sorties représentatives du BizTalk en production avant toute réécriture, c'est la référence de parité. (3) Logic Apps Standard, pas Consumption — pour une migration production, Standard offre l'intégration VNet, une facturation déterministe et des workflows stateful qui collent aux Orchestrations BizTalk. (4) Préserver les contrats d'interface — chaque partenaire externe attend des échanges bit-identiques ; réécrire les structures de messages est un programme séparé. (5) Coexistence pendant la transition — faire tourner BizTalk et Logic Apps en parallèle, basculer flux par flux, jamais big-bang. La méthodologie ATLAS encadre l'ensemble avec gates kill/go entre étapes et registre interne de discordances classées.