BizTalk to Azure Migration – Comparison on Architectures

Welcome to our deep dive into BizTalk to Azure Migration! Today, we’ll explore the architectural differences between these two platforms, focusing on how you can transition from the traditional BizTalk architecture to the more dynamic and scalable Azure environment. As we dissect a simplified BizTalk setup, we’ll uncover the limitations imposed by its structure and how Azure offers a more flexible and scalable alternative. Join us as we discuss key components such as adapters, message boxes, and Logic Apps, and illustrate how Azure can transform the way you manage and scale your enterprise applications.

Whether you’re looking to understand the technical nuances or seeking strategies for effective migration, this session will provide valuable insights into making the most of cloud technologies for your business.

Let’s get started!

Today, we are going to talk about BizTalk to Azure Migration, specifically focusing on a comparison of the architectures involved. If we look at a simplified BizTalk architecture, I don’t want you writing in and telling me I’ve got this wrong, because this is a simplified version. You’ve got a receive side, and on the receive side, you’ve got an adapter that picks up the message, a pipeline that processes it, potentially a map that transforms it, and then we publish into a message box. The message box then allows you to subscribe, so you can have a send side, which is the mirror image. Once you’ve picked up a message from the message box, you can then do a transform, a map on that. You’ve got a pipeline to transform the message or process the message again, and an adapter to actually send it. But you may want to just do some processing or some orchestration. So again, you can have a subscription description to that message that fires up the orchestration engine and processes some workflow. Some key things to bear in mind about the BizTalk architecture is that it forces you into this architectural pattern.


You don’t have a choice. You have to publish into the message box; you have to subscribe. There is no other option. Everything goes via the message box, which means that it’s potentially a single point of failure, but it’s also a single point of contention for performance reasons. There is a limited amount of horizontal and vertical scaling that you can do because the orchestration engine, the adapters, send and receive, they run on Windows services on the physical Windows box. Those boxes can only handle a certain amount of services running until they run out of CPU or memory. So there are limits. You can add more boxes, but then in the middle, the message box is a single database, and then there’s contention on that. So there are limits to that, and you can set up multiple groups and such. But there are limits to how much you can scale. And particularly, once you’ve already bought your hardware and set up your system, it then becomes much harder to scale. You can’t scale easily after the fact. Whereas if you’re in the cloud world, in Azure, if you were to do this same architecture, typically, Logic Apps have connectors.


And so, where you use adapters in this tool, you might want to use a Logic App. Pick up from a file system with the file adapter, use a file connector on a Logic App. It’s a similar thing. And if you wanted to use publish and subscribe as a pattern, you could publish, for example, onto a service bus topic. But you could also publish onto an event grid or put the message on an event hub. It depends. You’ve got a lot more options. And similarly, a Logic App could subscribe to that service bus topic. But then again, so could an Azure function, or an Azure function could be publishing too. And similarly, if you wanted to do orchestration, typically, you’d use Logic Apps for that as well. But what happens if actually you’re going to receive a message and then go and do some orchestration of it? Well, you don’t actually have to go via that. You can just go straight there because there’s no need to go via a service bus topic. You can do that if the architecture suits it.


So in the Azure world, we’ve got much more flexible architectural patterns. You’re not locked into anything. If I want to receive a message and then go straight through and send it, I can do that. I don’t have to go via any messaging infrastructure, but I can if I want to. If I want to do multiple subscribers to the same message and such, I can definitely do that. But I’ve got a richer set of offerings to do that with. And the other difference is that each part of this is independently scalable. I can put my Azure functions on one hosting plan. I can put the Logic Apps on another hosting plan. I can make one or more service bus namespaces and put the workload through that. There is a lot more you can do to scale out, and it’s a lot easier if you need to scale out and you’ve already deployed. It’s a lot more flexible to create more cloud infrastructure to scale certain parts of that independently. So in the Azure world, if you want to replicate a BizTalk application, and we will be talking a lot more about this, you can lift this pattern into this set of tools on Azure, and you’ve got a really quick way to actually migrate from BizTalk on-prem, on-tin into the cloud.


But then if you want to think about it and refine, you’ve got a lot more flexibility in how the architecture hangs together. So, quick introduction, comparison of the architectures. Rigid, fixed, but we all know how it works. Flexible, cloud-based, scalable Azure. That’s the future.

Chat to us about your Integration journey

Get in touch
BizTalk Migration Funding








    Share this post