BizTalk BRE migration to Azure

Azure Logic Apps Standard includes the Logic Apps Rules Engine, so the old advice to rewrite every BizTalk policy is too broad. The first migration question is which fact types each policy uses, followed by how the policy is called and versioned.

What can move

Microsoft documents a migration path for BizTalk rules that use XML facts and .NET Framework facts. Export the policy and its vocabulary from BizTalk, create a Rules Engine project in Visual Studio Code, and import the exported artifacts. Treat that import as source material for a new project rather than proof that runtime behaviour is identical.

What blocks a straight export

Database facts are not supported in the documented migration path. A policy that reads directly from a database therefore needs a different boundary: fetch the required values before the rules action, represent them as supported facts, or redesign the rule. Identify this before estimating the policy as a mechanical move.

The deployment model changes

Rules are built as a Rules Engine project and deployed for use by Standard workflows. This makes policy source and deployment part of the application delivery path. Record the vocabulary, policy version and calling workflow together so that a rule update cannot silently drift away from the integration that depends on it.

How to prove equivalence

Export one policy at a time. Build a fixed set of representative XML and .NET facts, including boundary values and the cases where no rule should fire. Run those facts through BizTalk BRE and the Logic Apps Rules Engine, then compare the resulting business decisions—not only whether execution succeeded.

Cutover rule

Keep the BizTalk policy available until the new workflow has passed the agreed examples and operational errors are visible. A successful import shortens the rewrite; it does not remove regression testing, deployment control or the need to redesign unsupported facts.