Exit BizTalk Server and migrate to Azure Logic Apps.

Per the Microsoft lifecycle: mainstream support until April 11, 2028, extended support until April 10, 2030, end of sale on March 31, 2027; BizTalk Server 2020 is the last version. The official Microsoft roadmap positions Azure Logic Apps as the designated successor. Customers who have not migrated by April 2030 would continue to operate BizTalk but without security updates or functional evolutions. The typical advice given to IT departments: aim for a complete migration before 2029, to keep a year of buffer before the end of extended support.

Progressive migration is recommended and technically feasible. The two platforms coexist easily thanks to Azure Service Bus which can serve as a messaging bridge. Each orchestration is migrated independently, tested in dual run with BizTalk for a duration set at scoping based on the risk profile, then the BizTalk version is decommissioned. This approach spreads risk and allows teams to ramp up Azure skills progressively. Be careful not to spread the transition too thin — a coexistence that drags on becomes expensive.

BizTalk .btm maps are internally composed of XSLT plus Microsoft functoids. Microsoft provides the 'Azure Logic Apps Migration Agent' VS Code extension (preview, built on GitHub Copilot), which parses BizTalk 2016 and 2020 projects (.btproj, .odx, .xsd, .btm, .btp, bindings) and generates Logic Apps Standard artifacts to review. For complex functoids (Concat, DateTime, Looping, Database) that have no direct equivalent, we reimplement them in Azure Functions called from the Logic Apps maps. We validated this pattern on functoids FID 107 (Concat) and FID 125 (DateTime) during our POC.

Yes, for the major adapters. Logic Apps offers more than a thousand native connectors or via Azure Service Bus, covering SAP (via dedicated SAP connector), SWIFT (via banking connectors), FTP/SFTP (native), IBM MQ and Kafka (via Service Bus connectors). More exotic adapters (HL7 for healthcare, EDI X12/EDIFACT for B2B) are available in Azure Integration Services. Only very specific or custom adapters may require a rewrite in Azure Functions.

Three typical gains: reduced infrastructure costs (no more BizTalk servers to maintain, no more dedicated SQL Server licenses), automatic elasticity (Logic Apps adapts to load without intervention), and native observability (logs and metrics directly in Azure Monitor). These gains translate into a lower total cost of ownership for the integration infrastructure, measurable over several years, and shorter incident analysis thanks to integrated telemetry.

Microsoft has positioned Azure Integration Services (AIS) as the spiritual successor to BizTalk Server. AIS is not a single product — it's a family: Azure Logic Apps for workflows and orchestrations (the closest BizTalk Orchestration analog), Azure Service Bus for messaging, Event Grid for events, API Management for gateways, and Data Factory for batch and ETL flows. Microsoft mainstream support for BizTalk Server 2020 runs until April 11, 2028, extended support until April 10, 2030, and end of sale is set for March 31, 2027; BizTalk Server 2020 is the last version. For organizations on BizTalk 2010 or 2016, the upgrade-or-migrate decision is now urgent. The ATLAS methodology handles BizTalk-to-AIS migration with interface-contract preservation and parity audit. See BizTalk to Azure journey.

It depends on the number and complexity of orchestrations, the number of partners and adapters, and data volumes. One factor matters more than raw volume: the share of orchestrations still genuinely active. On most BizTalk estates, a significant fraction of flows no longer serve any purpose, and a mechanical rebuild recreates in the cloud an estate nobody re-examined. We measure this during the ATLAS Intake, before any quote. The Intake produces the estate inventory, measures its complexity and identifies the risks. The first scoping call is free (30 minutes to 2 hours). See the delivery models for contractual formats.

Five practices we apply systematically. (1) Inventory before any code — every orchestration, every map, every adapter, every schema, every business rule, with dependencies mapped and owners identified. (2) Characterization tests on real message sets — capture representative inputs and outputs from the running BizTalk before any rewrite, this becomes the parity baseline. (3) Logic Apps Standard, not Consumption — for production-grade migration, Standard offers VNet integration, deterministic billing, and stateful workflows that match BizTalk Orchestrations. (4) Preserve interface contracts — every external partner expects bit-identical exchanges; rewriting message structures is a separate program. (5) Coexistence during transition — run BizTalk and Logic Apps in parallel, switch flow by flow, never big-bang. The ATLAS methodology frames the whole thing with kill/go gates between steps and a internal classified discrepancy registry.