For organisations still running critical integration workloads on BizTalk Server, the direction of travel has become increasingly clear. 

Microsoft has confirmed that BizTalk Server 2020 will be the final release of BizTalk Server, with sales expected to end on 31 March 2027. Mainstream support continues into April 2028, with Microsoft also planning additional paid support options for eligible customers through April 2030. 

That provides organisations with time, but it should not be mistaken for a reason to wait. 

There are already more immediate changes to manage. On 30 September 2026, Microsoft will retire the Service Bus Messaging Protocol (SBMP) in Azure Service Bus. For affected BizTalk Server 2020 environments using the SB-Messaging adapter, action is required to maintain connectivity. 

The immediate technical fix may be clear. The bigger consideration is what these changes signal for organisations that continue to depend on BizTalk. The question is no longer simply whether BizTalk Migration should form part of the technology roadmap. 

It is how to modernise a complex integration estate in a way that supports wider digital change without introducing unnecessary risk, disruption or cost. 

Why BizTalk Migration planning should start now 

BizTalk may increasingly be described as legacy technology, but the business processes running through it are often anything but obsolete. 

For many organisations, BizTalk has evolved over years or even decades. It can sit between core business applications, move critical data, orchestrate processes, transform messages and connect internal and external systems. 

That makes BizTalk Migration very different from simply replacing one application with another. The technology may be changing, but the integrations, dependencies and business logic still need to be understood and protected. 

Microsoft is now actively recommending that organisations begin planning migrations towards Azure Logic Apps Standard or Logic Apps Hybrid rather than treating additional support time as the long-term destination. 

For organisations with substantial estates, starting early creates the opportunity to modernise in controlled stages rather than allowing lifecycle dates to dictate the pace of a future change programme. 

Start by understanding the existing integration estate 

A successful BizTalk Migration should begin with discovery. 

Over time, integration estates naturally accumulate complexity. Applications are replaced, business processes change, temporary interfaces become permanent and documentation does not always keep pace with the technology. 

Before defining a Microsoft Azure architecture, organisations need an accurate picture of what exists today. 

This is also where an arrt Health Check can add real value. By reviewing the current integration landscape, architecture, dependencies, risks and operational maturity, the Health Check helps establish a clearer picture of the existing estate before decisions are made about what should be retained, retired, redesigned or migrated. 

That means understanding: 

• integrations and interfaces currently in use; 
• orchestrations, maps, schemas and pipelines; 
• adapters and external dependencies; 
• message volumes and performance requirements; 
• custom code and specialist functionality; 
• security, networking and connectivity; 
• operational monitoring and support requirements; 
• the business processes each integration supports. 

Microsoft’s current BizTalk Migration guidance similarly places discovery and assessment at the beginning of the process. Its Logic Apps Migration Agent follows a five stage approach covering discovery, planning, conversion, validation and deployment. 

The objective should not simply be to produce an inventory. It should be to understand the role each integration plays within the wider organisation. 

Don’t migrate what you no longer need 

One of the biggest opportunities within any integration modernisation programme is rationalisation. A mature BizTalk estate is unlikely to represent a perfect picture of today’s business requirements. 

Some integrations may still be critical. Others may support applications that are themselves approaching replacement. Some may rarely change and present very little operational risk, while others may be actively constraining digital transformation projects.  Each integration should therefore be considered individually. 

Broadly, it may make sense to: 

Retire integrations that are no longer required. 
Replace integrations where the underlying application or business process is changing. 
Retain temporarily stable workloads where immediate migration offers limited value. 
Modernise important integrations onto the target Azure platform. 
Redesign processes where reproducing the existing solution would simply carry historic limitations into the new architecture. 

This is an important distinction. 

If an organisation begins with 500 interfaces, the aim should not automatically be to finish with 500 equivalent interfaces in Microsoft Azure. 

BizTalk Migration should simplify the estate where possible, not simply relocate it. 

BizTalk Migration is not a one-to-one conversion exercise 

It is tempting to approach migration by looking for direct replacements. 

An orchestration becomes a Logic App. Messaging moves to Azure Service Bus. APIs sit behind Azure API Management. Existing maps and schemas are transferred into their nearest equivalent. 

Some elements may migrate relatively cleanly. 

Others should not. 

Microsoft’s own migration guidance encourages organisations to take advantage of Azure native capabilities rather than reproducing the existing BizTalk architecture exactly. 

A modern digital integration architecture may combine technologies including: 

• Azure Logic Apps; 
• Azure Service Bus; 
• Azure API Management; 
• Azure Functions; 
• Integration Accounts; 
• event driven architecture; 
• modern identity and secrets management; 
• Infrastructure as Code; 
• CI/CD; 
• centralised monitoring and observability. 

The right destination depends on what each integration needs to achieve. 

That is why we see BizTalk Migration as an architecture exercise first and a conversion exercise second. 

The goal should not be to recreate BizTalk in Microsoft Azure. It should be to establish an integration platform that better supports the organisation’s future requirements. 

Build the integration architecture before migrating at scale 

A sustainable integration platform needs considerably more than workflows. 

Before moving significant production workloads, organisations should define the foundations that every future integration will use. That includes areas such as security and identity, networking, monitoring, exception handling, configuration, resilience, deployment and governance. 

For example: 

• How will integrations authenticate securely? 
• How will messages be retried or resubmitted? 
• How will operations teams identify where a transaction has failed? 
• How will environment specific configuration be managed? 
• How will deployments be automated and controlled? 
• How will integration patterns be standardised across teams? 

These questions should be answered at platform level rather than independently for every migration. 

This is also where the ARRT Integration Brain can support the modernisation approach. 

The ARRT Integration Brain provides a reusable integration architecture and set of foundations for building solutions using Microsoft Azure. Within a BizTalk Migration programme, establishing those foundations early means successive integrations can follow common patterns rather than redesigning security, deployment, monitoring and infrastructure with every workload. 

That helps move the programme from a series of individual integration projects towards a governed and scalable integration platform. 

Start small, learn and then scale 

Once the current estate has been assessed and the target architecture defined, the next step should be a representative migration. 

That does not necessarily mean choosing the easiest integration. 

An initial workload should contain enough real world complexity to prove the platform, without introducing unacceptable business risk. 

It gives the organisation an opportunity to validate: 

• the Azure architecture; 
• networking and security; 
• deployment pipelines; 
• monitoring and operational support; 
• migration tooling; 
• reusable integration patterns; 
• testing and release processes. 

The lessons from this first implementation can then improve subsequent migrations. 

Microsoft recommends an iterative or wave-based approach for larger BizTalk estates for similar reasons. Moving controlled groups of workloads allows teams to learn and adapt as the programme progresses rather than committing the whole estate to an approach before it has been fully proven. 

Prioritise migration based on business value and risk 

Once the approach has been validated, the wider estate can be grouped into migration waves. 

Priority should not be determined solely by technical complexity. 

A stronger roadmap considers factors such as: 

• business criticality; 
• frequency of change; 
• technical and operational risk; 
• application roadmaps; 
• dependencies on wider change programmes; 
• supportability; 
• migration complexity; 
• opportunities to retire legacy technology; 
• value created through modernisation. 

A stable BizTalk integration supporting a relatively static process may reasonably remain in place while another integration that is preventing a major digital transformation project progresses much earlier. 

This is one of the reasons a phased BizTalk Migration programme can be so effective. BizTalk and Azure Integration Services can coexist during the transition while workloads are progressively modernised. The objective is not simply to migrate quickly. It is to migrate in the right order. 

BizTalk Migration should support wider Digital Transformation 

BizTalk Migration rarely exists in isolation. Integration architecture sits underneath many of the digital transformation projects organisations are already undertaking. 

A change programme may focus on replacing a core application, implementing a new CRM, introducing a customer platform, moving infrastructure to the cloud, improving data capabilities or adopting AI. 

Each of those initiatives creates integration requirements. In this sense, modernising BizTalk is not simply an infrastructure exercise. It can become an important enabler of wider digital change. 

A modern digital integration platform can make it easier to connect new applications, expose services through APIs, introduce event driven processes and respond more quickly as the organisation’s technology landscape changes. 

This is why timing matters. 

Organisations that understand their existing integration estate before major transformation begins are generally in a stronger position than those forced to unpick dependencies in the middle of an already complex programme. 

Can AI accelerate BizTalk Migration? 

Microsoft’s Azure Logic Apps Migration Agent introduces another interesting dimension. 

Currently available in preview, the tool uses specialised GitHub Copilot agents to analyse integration projects, discover artefacts and dependencies, plan migration approaches and assist with converting supported workloads into Azure Logic Apps Standard. 

This has the potential to accelerate parts of the migration lifecycle significantly. But automation does not remove the need for architecture. AI can help identify artefacts, analyse dependencies and generate components. 

It cannot independently decide whether an integration still provides business value, whether an existing process should be redesigned, which workloads should migrate first or what level of operational risk is acceptable. 

Those remain business and architectural decisions. The opportunity is therefore not AI instead of integration expertise. 

It is AI combined with experienced integration architecture to reduce repetitive migration effort while retaining control over the decisions that matter. 

An eight-step BizTalk Migration roadmap 

For organisations considering what to do next, we recommend a practical sequence. 

1. Address immediate technical risks 
Identify whether changes such as the September 2026 SBMP retirement affect the current estate and take the necessary action. 

2. Discover the estate
Build an accurate picture of existing integrations, dependencies, business processes and operational requirements. 

3. Rationalise 
Decide what should be retained, retired, replaced, modernised or redesigned. 

4. Define the target integration architecture 
Establish how Logic Apps, Service Bus, API Management and the wider Microsoft Azure platform will work together. 

5. Build the platform foundations 
Put security, governance, monitoring, resilience, configuration and deployment capabilities in place. 

6. Prove the approach 
Select a representative workload and use it to test both the technology and operating model. 

7. Migrate in controlled waves 
Prioritise workloads using business value, risk, dependencies and complexity rather than technical convenience alone. 

8. Continually improve 
Use each migration wave to refine the architecture, remove unnecessary complexity and strengthen the platform. 

The deadline is not 2030 

BizTalk Server 2020 has a support runway that extends into 2030 for eligible organisations, but treating that date as the point at which action becomes necessary would miss the bigger opportunity. 

Complex integration estates take time to understand. Architecture takes time to establish. Migration programmes need to fit around wider business priorities, regulatory requirements and other digital transformation projects. 

The strongest position is therefore not to rush away from BizTalk, but to use the available time deliberately. 
The September 2026 SBMP retirement is an immediate reminder that the Microsoft integration landscape is already changing. 
The broader direction is equally clear. 

For organisations running BizTalk, now is the opportunity to understand the existing estate, define the future integration architecture and establish a practical roadmap for digital change. 

At arrt, we have spent many years designing, supporting and modernising Microsoft integration environments. Our approach is to understand what exists today, establish where the organisation needs to get to and create a controlled route between the two. 

If BizTalk Migration is beginning to form part of your technology or digital transformation roadmap, talk to us about what your next step should look like. 

BizTalk Migration FAQs 

Is BizTalk Server being discontinued? 

BizTalk Server 2020 is Microsoft’s final release of BizTalk Server. Microsoft expects sales to end on 31 March 2027, while support arrangements provide existing customers with additional time to plan their migration. 

What replaces BizTalk Server in Microsoft Azure? 

Microsoft is directing customers towards Azure Logic Apps Standard or Logic Apps Hybrid. A wider Azure integration architecture may also use services including Azure Service Bus, API Management and Azure Functions depending on the requirement. 

Should every BizTalk integration be migrated? 

Not necessarily. Discovery and rationalisation should identify integrations that can be retired, replaced or redesigned as well as those that genuinely need to migrate. 

Does BizTalk Migration need to happen all at once? 

For larger estates, a phased or wave based approach generally reduces risk and allows organisations to refine the platform as they learn. 

Can AI automate a BizTalk Migration? 

AI assisted tools can accelerate discovery, analysis, planning and conversion, but architectural and business decisions still require appropriate expertise and governance. Microsoft’s Logic Apps Migration Agent is currently available in preview. 

Would you like some advice on this topic please contact us at https://arrt.uk.com/contact/