Sortir de BizTalk Server et migrer vers Azure Logic Apps.

Selon le cycle de vie Microsoft : support mainstream jusqu'au 11 avril 2028, support étendu jusqu'au 10 avril 2030, fin de vente le 31 mars 2027 ; BizTalk Server 2020 est la dernière version. La roadmap officielle Microsoft positionne Azure Logic Apps comme successeur désigné. Les clients qui n'auraient pas migré d'ici avril 2030 continueraient à faire fonctionner BizTalk mais sans mises à jour de sécurité ni évolutions fonctionnelles. Le conseil typique donné aux DSI : viser une migration complète avant 2029, pour garder une année de marge avant la fin du support étendu.

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 une durée définie au cadrage selon le profil de risque, 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. Microsoft fournit l'extension VS Code « Azure Logic Apps Migration Agent » (préversion, assistée par GitHub Copilot), qui lit les projets BizTalk 2016 et 2020 (.btproj, .odx, .xsd, .btm, .btp, bindings) et génère des artefacts Logic Apps Standard à revoir. 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 les maps Logic Apps. Nous avons validé ce pattern sur les fonctoïds FID 107 (Concat) et FID 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.

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). Ces gains se traduisent par une baisse du coût total de possession de l'infrastructure d'intégration, qui se mesure sur plusieurs années, et par une 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 mainstream de BizTalk Server 2020 court jusqu'au 11 avril 2028, le support étendu jusqu'au 10 avril 2030, et la fin de vente est fixée au 31 mars 2027 ; BizTalk Server 2020 est la dernière version. 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é. Nous mesurons cela dès l'Intake ATLAS, avant tout chiffrage. L'Intake produit l'inventaire du parc, mesure sa complexité et identifie les risques. Le premier échange de cadrage est gratuit (30 minutes à 2 heures). Voir les modèles de delivery pour les formats contractuels.

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.