Every BizTalk Artifact, and What It Becomes in Azure

The first real question in any BizTalk migration is not “which Azure service?” It is “what is this thing I am holding, and what does it become?”

BizTalk is a single product that does six jobs: transport, transformation, routing, orchestration, rules, and tracking. Azure splits those jobs across separate services. So a migration is not a port — it is a decomposition. Below is the mapping we use when we inventory an estate, including the honest gaps.

Transport: receive locations and send ports

BizTalk	Azure target	Notes
FILE receive/send	Logic Apps + Azure Blob Storage or Azure Files	Trigger on blob creation; watch polling intervals and the “already processed” pattern
FTP / SFTP	Logic Apps SFTP connector	Managed connector; check throughput limits against your file sizes
HTTP / SOAP receive	API Management → Logic Apps	APIM gives you the policy layer BizTalk isolation hosts never had
WCF-SQL	Logic Apps SQL connector, or Functions for anything nontrivial	The polling/notification patterns rarely survive intact
MSMQ	Azure Service Bus queues	The closest conceptual match in the whole migration
MQSeries	Service Bus + a bridge, or Logic Apps IBM MQ connector	Frequently the longest-lead item in a migration
AS2 / EDI receive	Logic Apps with Integration Account, or a dedicated EDI layer	See our EDI migration piece for the trading-partner mechanics
POP3 / SMTP	Logic Apps Office 365 / SMTP connectors	Usually the easiest wins in the estate

Transport is the part that maps cleanly. If your inventory is mostly file drops and SFTP, your migration is genuinely more tractable than average, and you should start here to build team confidence.

Transformation: schemas and maps

XSD schemas transfer directly. This is the single biggest piece of good news in the whole exercise — your schemas are your contract with the outside world, and they come with you.

BizTalk maps (.btm) carry into the Logic Apps data mapper with rework that scales with how much custom logic you buried in them. Three tiers, in our experience:

• Straight field-to-field mapping with basic functoids: mostly mechanical.
• Maps with looping, conditional records, and cumulative functoids: hand-rebuilt, but tractable.
• Maps containing inline C# or XSLT calling custom assemblies: these are code, not configuration. Treat them as code and move them to Azure Functions.

That third tier is where estimates blow up. A single map with 400 lines of inline XSLT is not “one map” — it is a small application. Count those separately during inventory.

Routing: the messagebox

This is the artifact with no Azure equivalent, and the one that most often breaks a mental model.

BizTalk’s messagebox is a SQL-backed publish/subscribe engine. You do not route messages in BizTalk — you publish them, and subscribers with matching filter expressions pick them up. Content-based routing, convoys, and ordered delivery all rest on this.

There is no messagebox in Azure. What you have instead:

• Service Bus topics with subscription filters — the closest match for content-based routing on message properties.
• Event Grid — for high-volume, event-shaped fan-out where you do not need queuing semantics.
• Explicit routing inside a Logic Apps workflow — a switch or condition, which is simpler to read but couples the routing decision to the workflow.

The design decision is whether to preserve the publish/subscribe pattern (Service Bus topics, more moving parts, keeps producers ignorant of consumers) or collapse it into explicit routing (simpler, but every new consumer means editing a workflow). Estates with many subscribers per message type should preserve it. Estates where “pub/sub” was really just one-to-one plumbing should collapse it and enjoy the simplification.

Orchestration

Short, stateless orchestrations become Logic Apps workflows, and this is where Microsoft’s tooling helps most.

Long-running, stateful orchestrations are a different animal. If an orchestration waits days for a correlated response, holds accumulated state, or implements a convoy, you are choosing between:

• Logic Apps stateful workflows — durable, with run history; watch the limits on run duration and the cost of very long-lived runs.
• Azure Durable Functions — the strongest fit for genuinely complex stateful logic, at the price of writing code rather than configuring a workflow.
• A dedicated ESB layer — which is the case for Art2link ESB in estates where dozens of these exist and rewriting each as code is not proportionate.

A practical rule: if the orchestration has more than a handful of shapes and any correlation logic, do not let a conversion tool decide its architecture for you.

Rules: the Business Rules Engine

The BRE has no Azure equivalent. None. Nothing in Azure Integration Services is a forward-chaining rules engine with a policy versioning model.

Your options, in descending order of how often we see them chosen:

1. Move the rules into code — Azure Functions, with the ruleset expressed as testable logic. Best when the rules are stable and owned by engineering.
2. Move them into a configuration store — Azure App Configuration or a table, read at runtime. Best when values change often but the logic does not.
3. A third-party rules engine — genuinely warranted when business users author the rules and that authoring workflow must survive.

The mistake is discovering the BRE dependency in month four. Grep for Microsoft.RuleEngine during inventory, not during build.

Pipelines and custom pipeline components

Standard pipeline stages — disassemble, validate, party resolution — have rough Logic Apps or connector equivalents.

Custom pipeline components do not. These are .NET classes doing flat-file quirk handling, encryption, header stripping, or one-off validation, and they are usually undocumented. They become Azure Functions. Budget for them individually: each one encodes a real-world quirk that someone discovered the hard way, and deleting it will break something in production three weeks later.

Tracking and BAM

BizTalk’s tracking database and BAM become Azure Monitor, Application Insights, and Log Analytics, with one significant caveat: BizTalk gave you message body tracking almost for free, and Azure does not. If your support team routinely opens the HAT to read the body of a failed message from last Tuesday, that capability needs to be deliberately designed in — with a retention and PII policy attached, because now you are choosing to store payloads rather than inheriting it as a default.

This is a workflow change for your operations team, and it is worth socialising early. It is the number one “the new platform is worse” complaint we hear, and it is entirely preventable.

The four artifacts with no clean equivalent

Worth listing plainly, because these are the items that turn a six-month estimate into a twelve-month project:

1. The messagebox — a pattern to redesign, not a component to port.
2. The Business Rules Engine — becomes code or configuration.
3. Custom pipeline components — become Functions, one by one.
4. Message body tracking — becomes a deliberate design decision with a cost.

Everything else on this page has a defensible target. These four require a decision, and the quality of those four decisions largely determines whether the migration is remembered as a success.

How this feeds a real plan

An inventory that produces counts against this mapping — 34 receive locations, 12 maps of which 3 contain inline XSLT, 8 orchestrations of which 2 are stateful, 4 custom pipeline components, 1 BRE policy — is a plan you can sequence, staff, and defend to a steering committee.

An inventory that produces “we have BizTalk” is not.

If you want yours produced against exactly this mapping, book an assessment. We inventory the estate, classify every artifact, flag the high-risk items, and hand back a staged roadmap. Two decades of doing this in production means we know which of these items bite.

---