Blog

BizTalk migration options and how to choose the right one

16.9.2026

Integration

By now, one thing should be clear:

After the BizTalk lifecycle announcement, the question is no longer if you will move away from BizTalk, but how and when.

What often blocks organizations at this stage is not a lack of technology, but a lack of structure. Many teams know they need to modernize, yet struggle to compare options in an objective manner.

This article lays out the main migration options we see in practice and introduces a decision matrix to help you choose a path that fits your organization.

First of all: There is no “BizTalk replacement”

A critical mindset shift is required.

BizTalk is/was a single, all-in-one integration product.

Modern integration is a platform, composed of multiple services and patterns.

As a result:

  • There is no one-size-fits-all replacement
  • Different integration types may follow different paths
  • Migration is usually incremental, not a big bang

With that in mind, let’s look at the realistic options.

The four migration options we see most often

Option 1 — Keep BizTalk and do nothing (short-term only)

What this means

  • BizTalk continues to run unchanged
  • No migration work starts yet
  • Focus remains on operational stability

When it can make sense

  • Very low change rate
  • Heavy regulatory constraints
  • BizTalk is supporting systems already planned for retirement

Risks

  • No learning curve started
  • Knowledge erosion continue
  • Options narrow over time

As such, this option only works as a temporary holding pattern, not an actual strategy.

Option 2 — Coexistence (Side-by-side modernization)

What this means

  • BizTalk remains operational
  • A new integration platform is introduced next to it
  • New integrations are built on the new platform
  • Existing BizTalk flows migrate gradually

When it makes sense

  • Large or complex landscapes
  • Business continuity is critical
  • You want to spread risk and cost over time

Trade-off

  • Temporary complexity
  • Requires clear governance to avoid duplication

This is the most common and most controlled approach we see.

Option 3 — Domain-by-domain migration

What this means

  • Integrations are grouped by domain (e.g. Finance, Supply Chain, Sales)
  • One domain migrates at a time
  • BizTalk is gradually decommissioned

When it makes sense

  • Clear domain ownership and boundaries
  • Reasonable integration boundaries
  • Business units can move independently

Trade-off

  • Requires good domain modeling
  • Some shared services need special attention

This option balances structure with progress.

Option 4 — Full replacement (Big Bang)

What this means

  • BizTalk is replaced in a single program
  • Fixed timeline
  • Strong executive mandate
  • New integrations are built on the new platform

When it makes sense

  • Smaller integration landscape
  • Strong funding and sponsorship
  • Low tolerance for long coexistence

Risks

  • High pressure
  • Limited flexibility
  • Very unforgiving if scope is underestimate

This option works, but only in very specific conditions.

The decision matrix

The table below summarizes how to think about these options.

BizTalk migration decision matrix

Common mistakes at this stage

Before moving on, a few patterns to avoid:

  • Choosing a technology before choosing a strategy
  • Treating all integrations as equal
  • Underestimating coexistence governance
  • Assuming “lift-and-shift” is faster (it rarely is)
  • Waiting for a perfect future state before starting

Progress beats perfection.

What you should have after this article

At this point, you should be able to answer:

  • Which options are clearly wrong for us?
  • Which one or two options are realistically viable?
  • What constraints (regulatory, organizational, budgetary) shape our choice?

If you cannot answer those questions yet, that’s normal — but it means the next step is necessary.

What comes next

In the next article, we will zoom in on:

  • What an enterprise integration platform on Azure actually looks like
  • Why “Logic Apps only” is not a strategy
  • How platform thinking changes migration decisions

This is where the conversation shifts from options to architecture and decisions in technology need to be made.

Choosing a migration path is not about being fast.

It’s about being deliberate, while you still have options.

Pieter Vandenheede

Pieter Vandenheede

Pieter is a seasoned IT architect and entrepreneur with 20+ years of experience turning complex business challenges into streamlined, scalable solutions. Specializing in Microsoft Azure integration and architecture, he designs and delivers platforms that connect systems, optimize processes, and drive results.