We’re still talking about BizTalk migration into Azure, and the question we’re answering today is: why not lift and shift? Previously, if you had an on-premises BizTalk installation, either on physical servers or on VMs that are on your own hardware, you faced obsolescence issues because we know that you’re out of support on the current versions. The latest version has a drop-dead date of 2028. You have data center costs, including the need to maintain servers with electricity, security, and other necessities. There’s also the inflexibility of having physical hardware, making it hard to scale quickly, leading to fixed capacity issues.
So, we’ve got all those problems with on-prem, and what we’ve been discussing is that going cloud-native is the solution to these problems. Many people ask me, why not lift and shift and put my BizTalk applications on infrastructure as a service (IaaS) in Azure, using cloud VMs and cloud databases? If you do that, you can migrate your applications without having to change them, which buys you some time and allows you to close your existing data center. But it doesn’t solve everything because you still face end-of-life issues and you’re still on a technology that will be deprecated. There are also numerous networking issues.
BizTalk relies heavily on MSDTC, requiring a lot of network ports and creating an isolated network with the databases. There are many networking tasks to address for SQL performance. If you have high workloads, controlling block-level SQL performance is easier on your own hardware compared to the cloud. Additionally, high availability strategies for SQL can be challenging. While clustering works well with BizTalk, some always-on SQL features are harder to implement. You still need to maintain your servers, including patching operating systems, so even though you’ve eliminated your data center, you haven’t resolved many product-related issues. Some customers have used this approach as a transition state to close their data center quickly, but it’s only a partial solution. Eventually, you will still need to migrate to cloud-native, effectively doubling your costs.
The best approach might be to consider going cloud-native from the start, avoiding the need to go through the process twice. This could be the most cost-effective option. Talk to me; I can help you find the right solution for your situation. Ultimately, going cloud-native is your destination, and it’s just a matter of whether you take the intermediate step.
