In late 2025, Microsoft confirmed the BizTalk Server product lifecycle timeline. Mainstream support for BizTalk Server 2020 ends in April 2028. Extended support - available at additional cost, runs to April 2030. After that, full end-of-life: no security patches, no bug fixes, no vendor support.

For many IT leaders, that headline is somewhere between uncomfortable and alarming. BizTalk is not peripheral infrastructure. For organisations that adopted it during its peak years, it is mission-critical middleware - the orchestration layer connecting CRM, ERP, portals, third-party systems, and automated business processes that run every day.

The question is no longer whether to migrate. It is how and given the timeline, when to start.

Why BizTalk Migration is Different From Most Platform Modernisation Projects

Most enterprise technology migrations follow a recognisable pattern: assess what you have, design the target state, execute, validate, go live. Complexity scales with system size, but the model is consistent.

BizTalk migration breaks that pattern in several important ways.

First, BizTalk orchestrations are not a uniform type of artefact. They represent business logic - sometimes complex, stateful, domain-specific logic - built around BizTalk's MessageBox architecture, its publish-subscribe model, and its specific handling of transactions and correlation sets. That logic does not map one-to-one to Azure Logic Apps. Each orchestration requires individual analysis: what is it doing, what systems does it connect, how does it handle failures, and how should that be expressed in a cloud-native event-driven architecture?

Second, BizTalk integrations are almost always underdocumented. Organisations that have run BizTalk for a decade typically have orchestrations built by multiple teams across multiple eras, without a centralised inventory, without consistent error handling patterns, and sometimes without any documentation at all. Before migration begins, discovery needs to happen - and in a mature BizTalk estate, discovery is a substantial piece of work.

Third, BizTalk integrations are live. Every orchestration you are migrating is processing real transactions for real business processes. You cannot take it offline while you rebuild it. The migration has to happen in parallel, with the existing BizTalk integration and its Logic Apps replacement running simultaneously until the new one is confirmed correct.

The Timeline Problem: Why April 2028 is Closer than it Looks

April 2028 sounds like reasonable runway. It is not, once you account for actual programme duration.

Consider a mid-to-large BizTalk estate: 80 to 150 active orchestrations, a mix of simple data transfers and complex multi-step processes, connected to five to ten external systems. A migration at that scale - done properly, with discovery, rationalisation, wave-based development, parallel validation, and structured decommissioning - typically takes 12 to 18 months to deliver safely.

Add procurement, vendor selection, and programme initiation time, and the window to start while still hitting mainstream support end date is already closing. Organisations that begin planning in 2027 are working against themselves from day one.

There is also a specialist skills consideration. As BizTalk approaches end-of-life, the pool of architects and developers with deep BizTalk knowledge will contract. Organisations that move early will have access to the best talent. Those that delay will face both a tighter timeline and a thinner supply of the expertise they need.

What Azure Logic Apps actually gives you that BizTalk does not

Azure Logic Apps is not a cloud-hosted version of BizTalk. It is a fundamentally different integration architecture and understanding the difference matters, because the migration is an opportunity to improve how integrations work, not just preserve what you have.

The most significant shift is from BizTalk's centralised MessageBox model to a decoupled event-driven approach built around Azure Service Bus. In BizTalk, all messages route through a central SQL Server database - which is both its consistency strength and its scalability bottleneck. In Azure, Service Bus provides messaging as a fully managed, elastically scalable cloud service with no infrastructure overhead.

The other transformative change is observability. BizTalk's monitoring is functional but limited, and diagnosing failures in a complex environment typically requires specialist expertise. Azure Logic Apps with Application Insights and Log Analytics provides real-time visibility into every workflow execution - inputs, outputs, errors, durations - without specialist tooling. For operational teams managing integration health, this change is substantial.

A well-designed Logic Apps migration does not just replicate BizTalk logic in a new runtime. It redesigns integrations to take advantage of asynchronous patterns, decoupled messaging, and native observability, producing a more resilient and more transparent estate than what it replaces.

The Delivery Model Decision that Determines Programme Success

The single most important structural decision in a large BizTalk migration is not a technology choice, it is a delivery model choice. Specifically: how do you develop Logic Apps integrations without blocking the programme on other dependent workstreams, particularly if the target platform (such as a new cloud CRM) is being migrated simultaneously?

The approach used in well-executed large migrations is to establish a cloud development environment early, a synchronised mirror of the on-premises data model maintained in near-real-time, so that Logic Apps can be developed and tested against real data from the first sprint, before the target platform migration is complete. This decouples the integration workstream from the platform workstream, allowing both to proceed in parallel and compressing the overall programme timeline materially.

Within the integration workstream, a wave-based delivery model is essential. Orchestrations catalogued and prioritised by business criticality, delivered in waves - highest risk first. Side-by-side parallel validation - running Logic Apps and BizTalk in parallel against live production data, confirming identical outcomes before retiring the BizTalk endpoint - is non-negotiable for any integration carrying real business transactions.

What to Do This Year

If you are running BizTalk Server 2020 or 2016 and have not begun migration planning, the practical actions for this year are:

Conduct a full BizTalk estate inventory - catalogue every orchestration, its trigger, its connected systems, its business owner. You cannot plan a migration without knowing precisely what you are migrating.

Assess complexity and prioritise. Identify the orchestrations carrying the highest business risk and the most complex logic. These will drive your timeline and resourcing model.

Start the architecture conversation now. Decisions about Logic Apps Standard vs Consumption, Service Bus topology, and monitoring design should be made before development starts, not during it.

Evaluate delivery partners early. Architects who understand both BizTalk's patterns and Azure Integration Services are a finite resource. The organisations that secure the right partner earliest will have the most controlled migration experience.

The end-of-life timeline is fixed. The complexity of a large integration estate migration is not something that can be compressed past a certain point. Starting now is not early - it is on time.

VE3 has delivered large-scale BizTalk to Azure Logic Apps migrations as part of complex Dynamics 365 cloud migration programmes. If you are assessing your BizTalk migration options, we can help you scope the work, model the timeline, and design the right delivery approach for your estate. Contact Us