I’ve been asked a version of this question a lot lately: “Should we just use AI to do the migration?” And the honest answer is — it depends on what you’re actually asking AI to do.
AI can convert a BizTalk orchestration to a Logic App workflow in minutes. I’ve seen the tools do it. It’s genuinely impressive. But if the original orchestration was badly designed for the cloud, you’ve just automated the reproduction of technical debt. Faster is not better if the direction is wrong.
The real opportunity AI unlocks in BizTalk migration isn’t translation speed — it’s making redesign viable. And that changes the calculus on a decision most teams think they’ve already made.
Why the Migrate vs Redesign Question Still Matters
BizTalk end of support is a forcing function. Mainstream support ended in 2028, extended support has a hard stop, and for most organisations this isn’t a nice-to-have modernisation. It’s landed on someone’s desk with a delivery deadline attached.
In that context, lift-and-shift is completely rational. You know what the integration does. You have tests, even if they’re informal. Converting what exists feels safer than redesigning it. And until recently, redesign meant months of extra effort that most programmes simply couldn’t absorb.
AI changes that. If AI can meaningfully cut the effort of both paths — conversion and redesign — then the question of which path to take is genuinely open again. And the answer matters, because the path you choose determines your operating cost, your change velocity, and how supportable your platform is for the next decade.
What Gets Lost in a Direct Conversion
BizTalk was designed around a specific set of architectural assumptions:
- A centralised message box that acts as the persistence and routing layer for all messages
- Long-running orchestrations that hold state across hours or days within the BizTalk runtime
- Synchronous pipelines with receive and send ports tightly coupled to transport adapters
- Centralised administration through a single BizTalk group with shared configuration
Azure Integration Services is built on completely different assumptions. Logic Apps Standard runs stateless workflows that externalise state to Azure Storage. Service Bus provides durable messaging but it’s not a message box — it doesn’t route between subscribers automatically. APIM handles protocol mediation independently of your integration workflows. There’s no centralised runtime. Instead you have a distributed composition of services, each with its own scaling behaviour, failure mode, and operational surface.
When you convert artefact-by-artefact, you import the coupling and state assumptions of the BizTalk design into the AIS model. The result is integrations that technically work but carry hidden costs:
- Higher latency — you’ve reproduced synchronous blocking patterns that BizTalk only tolerated because its message box was local
- Harder observability — the correlation between steps that BizTalk tracked through orchestration instance state is now scattered across Logic App run history, Service Bus message properties, and Application Insights with nothing connecting them automatically
- Fragile retry logic — BizTalk’s suspend and resume model doesn’t map to Logic Apps retry policies, and converted workflows often omit or misplace error handling
- Deployments that resist change — structural coupling from the original design is baked into your Logic App workflows, making future modifications riskier than they need to be
This isn’t a failure of the conversion tools. It’s a structural consequence of translating implementation without revisiting intent.
The Shift That Unlocks Real Value
Here’s the thing. AI is most powerful when it’s working from intent rather than implementation.
An integration specification — what this flow does, what guarantees it needs to provide, what systems it connects, what failure looks like — is something AI can use to design a cloud-native solution from scratch. That’s fundamentally different from asking AI to translate a BizTalk file.
| Prompt | What is AI doing | What you get |
| “Convert this BizTalk orchestration to Logic Apps” | Translating platform syntax | A cloud-hosted BizTalk pattern |
| “Here is the integration specification for this flow. Design a cloud-native implementation using Logic Apps Standard and Service Bus.” | Designing from requirements | A pattern built for AIS characteristics |
The first approach preserves what exists.
The second exploits what AIS actually does well: event-driven triggering, stateless workflow execution, durable messaging with competing consumers, scalable outbound fanout, and per-message retry with dead-letter visibility.
Working from specification rather than artefact also forces a useful conversation. What’s the actual SLA for this flow? What happens when the downstream system is unavailable for four hours? Does this flow genuinely need ordered delivery, or is that a BizTalk artefact with no real business requirement behind it?
These questions get skipped in lift-and-shift. They surface naturally when you’re describing the flow to an AI from scratch.
There are many pros, cons, pitfalls and considerations on this topic which I may delve more into on a future article but for now Ill leave you with a small decision matrix which allows you to think about a single interface and your attitude towards different dimensions affecting the lift and shift vs re-design approach and it can give you a simple view on which is best for your scenario.
My hope is that AI is going to allow more integrations to be redesigned to take advantage of the cloud and fewer square pegs being put in round holes.
Decision Matrix
Below is a design matrix which can help you to decide if an integration should be lifted and shifted with minimal change or if you should consider a redesign.
