Azure EDI: moving X12, EDIFACT and AS2 off BizTalk.

Azure handles EDI natively, but not without configuration. Azure Logic Apps provides X12, EDIFACT and AS2 encode and decode operations, and those operations require an integration account — a separate Azure resource that stores your partners, agreements, schemas and maps. The integration account must sit in the same Azure subscription and region as the logic app. Standard logic apps use a built-in X12 connector, but the account still has to be linked. So the protocol handling is native; the trading-partner configuration, reconciliation and operational tooling around it is what a migration actually builds.

Schemas transfer more cleanly than most teams expect. X12 and EDIFACT schemas are standards-based, so the definitions themselves carry across to an Azure integration account largely intact. Maps are the harder half: BizTalk maps built purely with standard functoids convert well, while anything using custom XSLT or scripting functoids needs review and, in places, a rewrite. Across the EDI estates we have migrated, 50–70% of artifacts carry forward rather than being rebuilt from scratch. The assessment tells you which side of that range your estate falls on before you commit to a plan.

The AS2 identity your partners know — the AS2-From and AS2-To identifiers — can be preserved, which is what keeps the migration invisible to them. What changes is the endpoint URL and the certificates behind it. Partner certificates are loaded into your Azure key store and referenced by the AS2 agreement, and MDN settings (synchronous or asynchronous, signed or unsigned) are configured per partner to match what is in the existing agreement. The endpoint change is the one item that does require a coordinated note to each partner.

In most cases the only change a partner sees is the endpoint they post to, and even that can often be held constant by keeping the existing address in front of the new platform during transition. Envelope identifiers, acknowledgement behaviour and control-number continuity are preserved deliberately, because a partner who notices your migration is a partner who opens a ticket. The mechanics of holding that continuity — control numbers, acknowledgement timing and the order the waves run in — are covered in detail in our article on moving EDI off BizTalk without breaking trading-partner relationships.

By partners and transaction sets, not by message volume. Ten partners exchanging one document type each is a materially smaller programme than two partners exchanging fifteen, even if the second pair moves far more traffic. The assessment inventories every partner, every transaction set, every map and every acknowledgement path, then groups them into cutover waves ordered by business consequence. That inventory is what turns an open-ended modernisation into a schedule.

The shape of the cost changes more than the total. BizTalk cost is dominated by BizTalk Server and SQL Server licensing plus the Windows estate underneath, paid whether or not messages flow. On Azure the licensing disappears and is replaced by consumption — logic app executions, storage, and a fixed monthly integration-account tier that is priced by capability rather than usage. Estates with steady high volume and estates with bursty low volume land in very different places, so we model your actual partner traffic during the assessment rather than quoting a generic saving.

Yes, and we recommend it. Both platforms run in parallel, processing the same inbound traffic, while we compare output message-for-message and reconcile acknowledgements before a single partner is switched. Partners then move in waves rather than all at once, so a problem found in wave one affects two partners rather than two hundred. There is no big-bang cutover and no production outage; the old platform stays available until the last wave is proven.