Start with the behaviour, not the product name

BizTalk Server still carries orchestrations, maps, pipelines, adapters and the MessageBox. Azure Integration Services is not a new name for that product. Logic Apps, Service Bus, API Management and Event Grid each cover part of the estate, and Azure Functions covers a step that is really code. This note is a sequence for planning the move. It is not an estimate of duration, which depends on custom code, adapters and behaviour that was never written down.

What Microsoft has published about BizTalk Server 2020

BizTalk Server 2020 follows Microsoft's Fixed Lifecycle Policy. The dates below are taken from the BizTalk Server 2020 lifecycle page on Microsoft Learn. That page states that support dates are shown in Pacific Time (Redmond). We read it on 30 October 2026.

  • Start date listed as 1 February 2020, 8:00:00 AM Pacific Time.
  • Mainstream end date listed as 12 April 2028, 6:59:59 AM Pacific Time.
  • Extended end date listed as 10 April 2030, 6:59:59 AM Pacific Time.

The same page notes that mainstream support was extended from 9 January 2024 to 11 April 2028. Microsoft's lifecycle announcement describes that extension as time to obtain security updates, request non-security updates and receive incident support, and it encourages customers to consider cloud solutions in Azure. The table and the note are not the same sentence. The table's mainstream end is 12 April 2028 at the time shown; the note says 11 April 2028. When a date goes into a programme plan, quote the lifecycle page and record the day you read it.

Those dates apply to BizTalk Server 2020: Branch, Developer, Enterprise and Standard. Look up any earlier version before you borrow them. This note gives no end-of-sale date, because Microsoft's pages do not describe sales the same way. Check licensing with Microsoft or your partner. A support date is a planning input, not a cutover order. The dates above are what the lifecycle page said on 30 October 2026, so open it again before you lock a milestone.

Inventory the estate before you pick a service

The BizTalk Administration Console is not the inventory. A useful backlog records what the business does, not only which artefact is deployed.

  • The business exchange: who sends, who receives, and what a wrong or missing message costs.
  • Orchestrations, including the waits, branches and any compensation inside them.
  • Schemas, maps and custom functoids. An exported map is not the whole behaviour if a functoid holds logic.
  • Receive and send pipelines, including custom pipeline components, which are code you will have to rewrite.
  • Adapters and the system behind each one: a file drop, FTP or SFTP, SOAP or WCF, SQL, or a line-of-business application.
  • Trading partners and agreements, especially EDI. Those flows have a different target shape from an internal application interface.
  • What operators do today with suspended messages, failed batches and resubmits. That runbook is part of the system.
  • Rules that live in the Business Rules Engine rather than in an orchestration shape.

Then classify each flow by how well it is understood, how severe a duplicate or a loss would be, and whether it has to keep running while you build the replacement. That classification is the migration plan. A list of application names is not.

Where the responsibilities tend to move

There is no single Azure service that replaces BizTalk. Microsoft's guide to choosing Azure integration services lists migration from BizTalk Server among the situations for Logic Apps, alongside Service Bus, API Management, Event Grid and, where the step is code, Azure Functions. The mapping below is by responsibility. Check the current connector list before you assume a particular adapter is covered. A missing connector is design work, not a surprise for the last week.

  • Orchestration: Logic Apps. A Consumption workflow is one workflow on a multitenant resource, billed per execution. A Standard resource can hold several workflows, runs single-tenant, in an App Service Environment or on infrastructure you host, and can use a virtual network. The Logic Apps overview is the source for that split. Neither model is BizTalk with a new badge.
  • Work that must wait for a consumer: Service Bus queues and topics. The MessageBox is not Service Bus. You still set lock duration, sessions, duplicate detection and dead-letter behaviour. At-least-once delivery means the receiver must tolerate a repeat.
  • An API other teams call: API Management, with a contract, a version and an authentication scheme you can explain.
  • A signal several systems should react to: Event Grid. If the business cannot lose the message, design retention and retry on purpose. Do not treat it as a work queue by default.
  • A transform that is really code: Azure Functions, or a short C# script on Standard. Custom functoids and pipeline components belong here, rewritten and tested. Logic Apps vs Azure Functions is that choice on its own.
  • Schemas, maps and EDI: an integration account holds partners, agreements, schemas and maps. Logic Apps can exchange AS2, EDIFACT, X12 and RosettaNet. An internal map that depends on code may be clearer as a Function.
  • A system on a private network: Consumption workflows commonly use the on-premises data gateway. Standard can use virtual network integration. Confirm the connector for the hosting model you picked.
  • Tracking: Application Insights and Log Analytics help only if you log a correlation id operations already understands. Decide how a failure is seen, replayed and closed. The suspended-message queue does not come back on its own.

The Business Rules Engine has no Azure switch. Some rules become workflow conditions, some belong in the application that owns the decision, and some become a small tested service. Write that choice down.

A sequence that keeps the business running

  • Agree the inventory, including the runbook, and which flows are in the first release.
  • Pick a pilot that teaches hosting, logging and cutover. A file exchange with a clear success check is often kinder than the busiest orchestration, and still real enough that a failure would be noticed.
  • Fix the contract first: message shape, who owns the data, what a retry must not duplicate, and who is called overnight.
  • Run the new path beside the old one only where a second execution cannot create a second business transaction.
  • Cut over one flow, watch a real business cycle, then take the next.
  • Retire receive locations, hosts and databases only when nothing still sends to them.

What this guide will not pretend

There is no typical duration here, no percentage of maps that convert, and no saving. Those figures would be inventions. Read Microsoft's current pages for connector coverage, limits and pricing when you estimate. For a second opinion on a set of orchestrations, see enterprise integration, cloud modernisation and Azure cloud engineering.

Sources

Lifecycle dates were checked on 30 October 2026. If you are reading this later, open the lifecycle page again before you commit a milestone.