We have never seen a BizTalk migration fail on a Tuesday morning with a spectacular outage. That is not how these projects die.
They stall. Month seven, 70% of interfaces moved, the remaining 30% turn out to contain most of the actual complexity, the team that was going to help got reassigned, and BizTalk is now running in parallel indefinitely — meaning you are paying for two platforms and getting the operational risk of both.
Five patterns account for most of it.
1. The big-bang cutover
The plan says: build the Azure platform, test it, then move everything over a weekend.
The plan is wrong for a reason that is structural rather than tactical. An integration layer’s behaviour is defined by its counterparties — trading partners, downstream systems, upstream schedulers — and you cannot test counterparty behaviour in a lab. You can test your handling of a well-formed 850 purchase order. You cannot test what your largest partner’s ERP does when your acknowledgement arrives 40 milliseconds later than it used to.
The alternative is unglamorous and it works: run both platforms simultaneously, move interfaces in waves, and keep BizTalk authoritative until each interface has proven itself on Azure with real traffic. Wave one is your three lowest-volume, lowest-consequence interfaces. Wave two is everything that looks like wave one. The hard interfaces go last, by which point the team has built real judgment about the new platform.
The cost of parallel run is real — two platforms, duplicated monitoring, reconciliation effort. It is dramatically cheaper than a failed cutover on a payments or claims interface.
2. No equivalent of the suspended-message queue
Here is the failure mode that catches teams with strong Azure skills and no BizTalk background.
When a message fails in BizTalk, it suspends. It sits in a queue, resumable, visible, with its body intact. This is such a fundamental part of how BizTalk operations work that nobody thinks to specify it as a requirement — it is furniture.
Logic Apps does not suspend messages. A failed run is a failed run. Unless someone deliberately designs the dead-letter path, your first production failure is also your first discovery that you cannot resubmit it.
Logic Apps does not suspend messages. A failed run is a failed run. Depending on how the workflow was built, the message content may be visible in run history, may be partially visible, or may be effectively gone. And run history has a retention window.
Which means: unless someone deliberately designs the dead-letter path, your first production failure in the new platform is also your first discovery that you cannot resubmit it.
What “deliberately designed” looks like: Service Bus dead-letter queues where the transport supports it, an explicit catch-and-persist step writing the failed payload plus context to durable storage, and — critically — a resubmit mechanism that your support team can actually operate without a developer. That last part is the one people skip, and it is the one that determines whether operations trusts the new platform.
3. Undocumented tolerance for bad data
Every BizTalk estate that has been in production for a decade contains accommodations. A partner who sends dates as MMDDYY in one segment and YYYYMMDD in another. A trailing-pipe quirk in a flat file. A custom pipeline component whose only job is to strip a byte-order mark that one upstream system has emitted since 2014.
None of this is in the documentation. Some of it is in a code comment. Most of it exists only as a shape in a map or a line in a custom component that looks like a mistake.
Rebuild from the schema alone and the new platform will be correct — and it will reject traffic that BizTalk accepted for a decade. Your partner’s position, entirely reasonably, will be that nothing changed on their end.
Two defences. First, during inventory, ask the engineers who maintain each high-volume interface a specific question: “if we rebuilt this from the schema, what would break?” The answers are gold and they are perishable. Second, run the parallel period long enough to see real traffic variance — including month-end and quarter-end, when the weird messages come out.
4. Throughput math done last
Someone eventually asks what this costs to run. If that happens after the architecture is set, the answer can be genuinely bad.
BizTalk’s cost model is fixed: you bought the licence and the hardware, and 10,000 messages a day costs the same as 100,000. Azure’s is consumption-based, and at high message volumes with connector-heavy workflows and per-action billing, a naive one-workflow-per-message design can produce numbers that stop the project.
The fix is not to abandon Logic Apps. It is to do the arithmetic during design and let it drive the pattern: batch where the business allows batching, use Service Bus rather than a workflow action for pure transport, put genuinely high-throughput paths on something priced for throughput, and reserve Logic Apps for the orchestration and connectivity work where it is strongest.
Do this in week three, with real message-volume data from your own tracking database. Not in month six.
5. No rollback path
Ask the question directly: it is Thursday, wave three went live Monday, and your second-largest trading partner reports that acknowledgements have been intermittently wrong all week. What do you do?
If the answer involves reconfiguring the partner, or a change window, or “we would have to redeploy the BizTalk ports,” then you do not have a rollback path — you have a hope.
A real rollback path means the BizTalk artifacts for a migrated interface stay deployed and disabled rather than deleted, the routing switch is a configuration change you can make in minutes, and someone has actually rehearsed it. Once per wave. On a Wednesday, not during an incident.
Teams resist this because keeping BizTalk artifacts alive feels like it undermines the migration’s momentum. It does the opposite: a cheap, tested rollback is what lets you move waves aggressively, because the downside of being wrong is fifteen minutes instead of a week.
The pattern behind the pattern
Notice what these five have in common. None of them is an Azure problem. Every one is a failure to know what BizTalk was actually doing.
None of them is an Azure problem. Every one is a failure to know what BizTalk was actually doing.
That is the structural risk in most BizTalk migration engagements: the team is strong on the destination and thin on the origin. They can build an excellent Logic Apps architecture and still ship one that silently drops the accommodations, safety nets, and volume characteristics that made the old platform survivable.
Cerebrum City has run BizTalk in enterprise production for two decades — for Humana, Deloitte, JetBlue, and U-Haul among others — and is Microsoft V-TSP–recognized for it. The value of that is not nostalgia for the messagebox. It is that we recognise these five patterns before they cost you a quarter.
If you want your migration plan pressure-tested against them, book an assessment or call (678) 203-0800.
Jorge Pastorini · Cerebrum City
Cerebrum City is a Microsoft V‑TSP–recognized BizTalk specialist in Atlanta, Georgia, with two decades running BizTalk Server in enterprise production for clients including Humana, Deloitte, JetBlue, and U‑Haul.
Want this mapped against your BizTalk estate?
We inventory your ports, orchestrations, maps, and adapters, flag the interfaces most likely to break, and hand back a staged Azure roadmap. No obligation.
