Logic Apps Is the Right Destination for Most BizTalk Workloads. Here Is Where It Is Not.

Let us start by conceding the argument, because vendors in our position are usually suspected of the opposite.

Azure Logic Apps is Microsoft’s named successor to BizTalk Server, it is a genuinely good product, and for most BizTalk workloads it is the right destination. Elastic scale, no infrastructure, 1,400-plus connectors, real DevOps tooling, infrastructure-as-code, and observability through Azure Monitor. If your estate is file drops, SFTP exchanges, mapped request/response calls, and short workflows, you should move to Logic Apps and you should not overthink it.

We say that as a BizTalk specialist with no incentive to. It is simply true for the bulk of the market.

What follows is about the remainder — the interfaces that make experienced integration architects hesitate. Three patterns, and what to do about each.

Gap one: very high-throughput messaging

Logic Apps bills per action. That model is elegant at moderate volume and becomes a design constraint at high volume.

Consider an interface moving several million messages a month where the actual work is: receive, validate, map, forward. In BizTalk that is a pipeline and a send port, and it costs whatever the server costs. Expressed as a Logic Apps workflow with four actions, it is several million times four billable actions, plus connector calls.

There is a real architecture answer, and it is not “give up on Azure.” It is to stop treating Logic Apps as the transport layer for these paths:

• Put pure transport on Service Bus or Event Hubs, which are priced for throughput.
• Do the transformation in a Function processing batches rather than single messages.
• Reserve Logic Apps for the orchestration and connectivity around that path, not the path itself.

Where this gets uncomfortable is when you have dozens of such interfaces and each one needs bespoke plumbing. At that point you are building an ESB out of primitives — which is a legitimate thing to do, and also exactly the work we productised as Art2link ESB rather than rebuild per client.

Diagnostic: any interface above roughly a million messages a month deserves an explicit throughput and cost design, not a default workflow.

Gap two: complex mapping

The Logic Apps data mapper has improved substantially and handles ordinary mapping well. Two shapes still fight it.

Very large schemas. A 3,000-element EDI or industry schema in a visual mapper is difficult to author, review, or diff. Your migration is not just a technical exercise — it is a change-control exercise, and “we cannot meaningfully code-review this map” is a governance problem that outlives the project.

Heavily conditional logic. BizTalk maps that grew inline XSLT or C# over a decade encode business rules, not field mappings. Rebuilding them visually either loses that logic or produces a map nobody can maintain.

The honest answer for both: treat the transformation as code. XSLT in an Azure Function, or a typed transformation library, version-controlled and unit-tested. This is more work upfront than dragging lines in a mapper, and for a map that carries real business rules it is the only maintainable outcome.

Diagnostic: grep your maps for inline scripting functoids and external assembly calls. Every hit is a candidate for code, not configuration. Count them before you estimate.

Gap three: long-running stateful orchestration

This is the deepest gap, because it is architectural rather than economic.

BizTalk orchestrations can wait. They can hold correlation state for days, gather related messages into convoys, enforce ordered delivery within a conversation, and resume cleanly after a host restart. Estates built around a document lifecycle — order to invoice, admission to discharge, shipment to settlement — lean on this heavily.

Azure gives you three options and each has a real cost:

• Logic Apps stateful workflows — durable with visible run history, but very long-lived runs interact awkwardly with duration limits and run-history retention, and the cost of a workflow that idles for eleven days is not zero.
• Durable Functions — the strongest technical fit for genuinely complex stateful logic. The cost is that your orchestration is now code, maintained by developers, with no visual representation for the business analyst who used to read the orchestration diagram.
• A dedicated ESB layer — worth it when you have many of these and per-instance rewriting is disproportionate.

Diagnostic: count orchestrations with correlation sets, delay shapes over one hour, or listen/receive shapes. If that count is in single digits, Durable Functions is likely fine. If it is in the dozens, you are making a platform decision, not a per-interface one.

Where Art2link ESB fits, plainly

We built Art2link ESB because these three gaps kept recurring in the same enterprise estates, and the alternatives were both unattractive: force every pattern through Logic Apps and accept the cost and complexity, or hand-build custom plumbing per client and maintain it forever.

Art2link is Azure-native middleware that sits alongside Azure Integration Services — not instead of it — and takes the high-throughput, complex-mapping, and stateful-orchestration workloads that Logic Apps handles awkwardly. In practice, most migrations we run are mostly Logic Apps with Art2link handling a minority of interfaces.

We are stating the boundary explicitly because we would rather you understood it than discovered it. If your estate has none of these three patterns, you do not need Art2link, and we will tell you so during the assessment. That is a shorter engagement for us and the right answer for you.

You can read what Art2link actually does if the patterns above describe your estate.

How to use this before you commit to an architecture

Four counts, from your own environment, before anyone draws a target architecture:

1. Messages per month, per interface. From the BizTalk tracking database, not from memory.
2. Maps containing inline scripting or external assembly calls. A count and a list.
3. Orchestrations with correlation sets or long delays. A count and a list.
4. Custom pipeline components. A count, with what each one actually does.

Those four numbers tell you what proportion of your estate is “straightforward Logic Apps” versus “needs a decision.” In most estates we assess, it is roughly 75/25 — and knowing which quarter is which is the difference between a migration that lands on schedule and one that discovers its hard problems in month seven.

If you want those numbers produced for your estate, book an assessment. Microsoft V-TSP–recognized, two decades of BizTalk in production, and no obligation.

---