Migrating from BizTalk
If you run BizTalk Server, you already think the way Art2link ESB works: messages are published to a central exchange, subscriptions decide who gets them, ports deliver them. The migration is not a re-education, it is the same architecture with the operational weight removed. This section is the map from one to the other.
BizTalk Server 2020 is the final version of the product, Microsoft has announced no successor. Mainstream support ends April 11, 2028; paid extended support ends April 9, 2030. Those dates feel comfortable until you put a multi-year migration of a living integration estate in front of them: every flow you run has to be inventoried, rebuilt, tested against real partners, and cut over, while the business keeps changing it.
The usual prescription is to decompose each BizTalk flow into a different shape, serverless functions, workflow designers, queues wired together per flow. That can work, but it discards the thing BizTalk shops actually liked: one place where messages land, one subscription model that decides where they go, one place to look when something fails. Art2link ESB keeps that shape and moves it onto managed Azure services in your own tenant.
BizTalk’s core loop, receive ports publish into the MessageBox, subscriptions select, send ports deliver, survives intact. In Art2link ESB the exchange is the bus, a purpose-built engine of the platform rather than a set of SQL Server tables; receive ports publish messages with a message type, send ports subscribe with subscription expressions over promoted values, and pipelines and maps shape the payload at the edges.
Because the model is the same, your mental inventory transfers: “which subscriptions pick this message up?” is still the first debugging question, Tracking is still where you watch a message move, and an Application is still the unit that owns an integration’s artifacts.
| Carries over | Changes |
|---|---|
| Applications as the unit of ownership; ports, pipelines, maps, promotions, subscriptions as the working vocabulary. | Everything is configuration, not a Visual Studio solution, artifacts are created and saved in the portal; there is no GAC, no MSI, no redeploy cycle. Code exists only where it earns its place: XSLT 3.0 maps, C# pipeline components and custom functions, saved in the platform and live on save. |
| Publish-subscribe through one exchange; promoted values drive routing. | A message type is a name, not a schema, XSD does not define your types; schemas are optional validation you attach where you want it. |
| Per-environment configuration travels with the application. | Bindings files become snapshots with password-encrypted secrets, and environment-specific values live in Constants. |
| Ports start and stop without redeploying. | Ports are started and stopped, configuration takes effect immediately, and changes are reversible in place. |
| Running on infrastructure you control. | The platform deploys from the Microsoft Marketplace into your own tenant on managed services, no servers to patch, no host instances to babysit. |
Artifact translation maps every BizTalk artifact, schemas, maps, pipelines, adapters, bindings, BAM, BRE, to its Art2link counterpart and what changes in the move. Orchestrations triages the hard part: most orchestrations turn out to be messaging in a trench coat, some become the countdown-loop pattern, and the genuinely stateful ones map to Correlation, which is under active development. The migration playbook is the process itself: inventory, classify, run side by side, cut over flow by flow.