BizTalk End of Life: Support Dates and Migration Options

Section 01

Separate end of sale from end of support

Microsoft's December 2025 lifecycle update said an end-of-sale date would follow. It did: on August 31, 2026, Microsoft announced that it expects sales of BizTalk Server 2020 and Host Integration Server 2020 to end on March 31, 2027. The word is "expects": treat the date as Microsoft's current plan, not a contractual commitment, and have licensing owners confirm it. Customers with valid licences can keep deploying and using the software under their licence terms after that date, so the end-of-sale date limits new purchases rather than stopping existing installations.

End of sale and end of support answer different questions. End of sale affects procurement and new licensing decisions. Mainstream support covers security and non-security updates plus Customer Service and Support; extended support changes that package. Microsoft's lifecycle page lists April 11, 2028 as the end of mainstream support and April 9, 2030 as the end of extended support. Microsoft's blog posts write the same two dates as April 12, 2028 and April 10, 2030, one day later, which appears to be a time-zone difference between the lifecycle page and the posts. Cite the specific date field in use and have licensing and support owners confirm the contractual wording.

For a 2016 estate, the support deadline is nearer and should govern sequencing. For a 2020 estate, establish whether the remaining runway reduces operational risk or merely delays the inventory. The dates describe a change in Microsoft servicing, not necessarily a workload stopping. A production decision should account for security policy, audit requirements, connected-product supportability, and incident recovery.

Section 02

Planned paid extended-mainstream support for 2028 to 2030

The same August 31, 2026 announcement describes an optional, paid extended-mainstream support offer for eligible BizTalk Server 2020 customers, planned for around April 2028 through April 2030. It is separate from the Extended Support phase in Microsoft's Fixed Lifecycle Policy. Microsoft has not published a price, final terms, or an official name, and says it will publish them before enrollment opens. Treat it as a plan, not a purchasable product.

What Microsoft has said so far:

• It is expected to have narrower coverage than original mainstream support and to add no new features.
• Microsoft expects it to exclude Business Activity Monitoring (BAM), the ESB Toolkit, the SWIFT, HL7, and RosettaNet industry accelerators, legacy enterprise adapters (such as Siebel, PeopleSoft, TIBCO, and JD Edwards), BizTalk-specific ALM tooling, and support for Visual Studio versions newer than 2022.
• Eligibility is expected to require properly licensed BizTalk Server 2020 deployments, active Software Assurance, and coverage of every licensed core in an enrolled deployment. BizTalk Server 2016 and earlier are not eligible.
• Microsoft expects to deprecate the BizTalk Server virtual-machine image in Azure Marketplace, with guidance on existing virtual machines to follow.

Microsoft's own recommendation is to treat this extra coverage as contingency time and to start migrating to Azure Logic Apps Standard or Hybrid now. If the inventory shows that an interface depends on an excluded component, put it early in the sequence, because that interface will have no vendor servicing during the paid period.

Section 03

Which BizTalk replacement is suitable?

Azure Logic Apps Standard is Microsoft's stated successor to BizTalk Server, and Microsoft's current migration guidance compares BizTalk features with Standard workflows, Azure Service Bus or RabbitMQ, connectors, and supporting Azure services. That makes it the most direct option when the target operating model can use Azure Integration Services. It is not the only valid outcome for every interface.

The comparison above is an editorial decision method based on Microsoft's published feature mapping. Test the exact connector, protocol, security boundary, and operating model that each integration needs. Microsoft describes hybrid Standard deployments for on-premises, private-cloud, public-cloud, and partially connected scenarios; that does not assure production readiness for every disconnected scenario.

Section 04

Inventory dependencies before choosing what can move

An interface inventory should include more than a list of BizTalk applications. Capture the receive and send ports, adapters, schemas, maps, pipelines, orchestrations, promoted properties and routing filters, rules, custom assemblies, certificates, partner agreements, tracking fields, schedules, dependencies, and production message samples. Include the business owner and the recovery owner for each flow. The useful unit of planning is a business outcome, such as an accepted purchase order or a reconciled claim, rather than a count of artefacts.

Microsoft's feature mapping gives a sensible first classification. XSD schemas and XSLT maps can be retained as artifacts in Logic Apps Standard or an integration account, but they still need test data and output comparison. The Logic Apps Rules Engine uses the BizTalk Business Rules Engine runtime; Microsoft's guide limits existing-policy support to XML and .NET Framework facts. Treat that scope as a gate, especially for rules that depend on other fact types.

BizTalk orchestrations and pipelines map to Standard workflows and local functions, but they are rebuilt, not transferred in one step. MessageBox subscriptions, property promotions, and filters map to separate messaging and routing constructs such as Azure Service Bus topics and subscriptions or RabbitMQ exchanges. Custom adapters and custom code require an explicit target: a connector, a custom connector, a local function, a custom service, or a retained component. Each choice changes deployment, support, and failure behavior.

Microsoft's migration guidance warns that resubmitting a Logic Apps run can process the same message again and recommends designs that assume at-least-once processing with deduplication, upserts, or exactly-once effects at the destination. That does not prove that every BizTalk transaction can preserve its prior delivery semantics. It does provide a clear acceptance test: replay a representative failure and inspect both the message history and the downstream business record.

Section 05

Set migration sequence from dependency and acceptance evidence

Start with a version and dependency register, then choose a small production-representative interface that includes the hardest relevant characteristic: a custom adapter, a partner agreement, a long-running orchestration, a mainframe connection, or a critical reconciliation. The purpose of the first move is to disprove risky assumptions about artifact reuse, operational ownership, and recovery behavior.

Use the result to group the remaining estate by dependency and business consequence. A straightforward file or API flow with a stable schema may be a reasonable early candidate. A multi-party EDI process, an orchestration with custom .NET dependencies, or an HIS-linked mainframe integration needs its own decision gate. HIS should remain a separate workstream because Microsoft has stated that HIS 2028 will be decoupled from BizTalk; replacing BizTalk does not automatically answer the host-connectivity question. Microsoft's announcement also says Azure Logic Apps Standard does not support SNA, so estates that depend on HIS 2020 SNA capabilities must plan a move to HIS 2028.

For each approved flow, require four pieces of evidence before cutover: an agreed business outcome, a tested failure and replay path, reconciled source and target results, and a named owner for day-two support. Parallel operation can be useful while those conditions are being demonstrated, but it also creates two paths whose outputs and exception handling must be reconciled. Retire a BizTalk flow only after the replacement has met its acceptance criteria and the fallback decision is explicit.

Section 06

A practical next action for an integration portfolio

Create a one-page register for every production BizTalk application: version, support date source, interface owner, protocols and adapters, artefacts, external partners, HIS dependency, target hypothesis, and the proof required before cutover. Record the March 31, 2027 expected end-of-sale date and whether any licences still need to be bought before it. That gives a defensible sequence; no single support deadline dictates every migration.

For broader architecture and operating-model choices, see the API integration modernization research hub. If the inventory shows a program that needs independent scope, delivery, and governance review, use the API integration modernization services guide.

This page is independent desk research, last checked October 7, 2026. Microsoft products are described from Microsoft documentation; they are not ranked by sponsorship, and Software Modernization Intelligence is not a delivery candidate. Read our methodology for how we assess sources and decision frameworks.