There are several reasons why a move from on-premise machines to Azure Infrastructure as a Service (IaaS) makes sense. This article describes top reasons why BizTalk servers could (and could not) be moved. Note that there are some differences based on the BizTalk Server version. The upcoming 2016 version has added support for High Availability (and more) in Azure. This is explicitly mentioned where applicable.

The illustration below shows the relationship between various offerings in Azure. This article is focused on IaaS, and should not be confused with BizTalk Services and other PaaS solutions.

Reasons why you could move

The following scenarios describe why a move is possible, supported and in some cases recommended. A relevant scenario being on this list does not implicate that a move is automatically recommended. There are usually other factors to consider, some may even be on the list of showstoppers later in this article.

"I need Development, Test and QA environments - and I need them now"

This is probably the most used scenario for running BizTalk in Azure these days. Creating new pre-production environments only takes a few minutes. All supported versions of BizTalk (see more details below) are available in the VM gallery. When BizTalk developers have an MSDN subscription, this can all be done without paying anything except the actual subscription. These subscriptions include monthly Azure credits, which is currently up to $150 - based on the subscription level. These credits can be used to run VMs, and developers can easily track remaining credits. By choosing a sensible VM size, and shutting them down when not using them, this is more than enough to last the entire month. In addition, developers can access their VMs from anywhere, and run different versions of BizTalk. This is very useful when supporting several customers, for instance. The VMs can obviously be scaled as required, and removed when no longer necessary. The standard BizTalk VMs in the gallery also includes SQL Server and Visual Studio, which minimizes installation and setup time.

"I don't want to invest in expensive on-premise infrastructure or up-front licenses"

One of many benefits of cloud computing is outsourcing the infrastructure. This can be a huge investment of time and cost. A BizTalk Server Enterprise edition license is currently $10835 per core (Microsoft BizTalk Server Pricing). Making all the required investments up front is an important disadvantage of on-premise computing. The pricing model in Azure where you pay for what you use lowers the bar for many businesses. The time factor may be equally important. The process of ordering infrastructure and servers, installing, configuring and tuning them can take a long time. In Azure, this can all be solved by a PowerShell script, and ready for use within a fraction of the time. The automatic scaling options also open the door for reducing cost, as the processing power is not fixed.

"I have already paid for BizTalk and SQL Server licenses"

License Mobility through Software Assurance gives Microsoft Volume Licensing customers the flexibility to deploy eligible server applications with active Software Assurance on Azure. With this Software Assurance benefit, there is no need to purchase new licenses and no associated mobility fees. Read more about this here. If BizTalk and SQL Server licenses are already paid for, just create new Windows Server images in Azure, and use the pre-paid licenses for the rest. The customer is then only charged by the minute for Windows Server.

"I just need Standard edition for B2B scenarios"

Simple B2B integration without High Availability requirements is a common scenario for BizTalk. In such cases, running the servers in Azure can make sense. Processing capacity can be altered based on needs without purchasing new servers or upgrading existing ones. To save cost, servers can be shut down when not in use. This can be beneficial if BizTalk is only used at specific time periods, for instance.

"I have high throughput requirements and high CPU load"

High-end hardware only being available on-premise is a myth. There are now multiple VM sizes and options available. The illustration below shows one of the fastest options available for a BizTalk VM. If this will not suffice in peak periods, autoscaling can be used to allocate extra processing power.

"I require 24/7 High Availability with guaranteed SLAs"

One of the news in BizTalk Server 2016 is support for High Availability in Azure IaaS. Previously, HA was achieved by setting up a Windows Server Failover Cluster (WSFC), typically with an active-passive configuration for SQL Server. This was, however, only supported on-premise. BizTalk now supports AlwaysOn Availability Groups for the first time, both on-premise and in Azure. This opens the door for many businesses that require 24/7 availability. Note that SQL Server 2016 is also required for this functionality.

Reasons why you should reconsider moving

The following scenarios describe why a move might not be the best choice, and certain prerequisites should be in place first.

"I don't have a cloud strategy yet"

If the business does not have a clear cloud strategy, anchored by management, moving BizTalk servers to Azure is not the first thing one does. Utilizing cloud computing is a business decision, not purely technical one. Strategies may be a usage of public, private and hybrid clouds. Several companies have already adopted a "Cloud First" strategy, and "Cloud Only" strategies are increasing in popularity. Cloud strategy is a huge topic, and will not be discussed further in this article. Without such a strategy, it may not be wise to go beyond having development environments and POCs in the cloud.

"I mostly use BizTalk to integrate with on-premise applications and systems"

Despite the rapid growth of cloud computing, several companies still mostly integrate on-premise applications and systems. If BizTalk is primarily used for such purposes, only moving BizTalk to the cloud does not make a lot of sense. That would only add latency, complexity and unnecessary components. Keeping the integration engine close to end systems is a wise strategy. An increasing amount of 3rd party applications are becoming cloud-based, however, so these "no cloud" scenarios will probably be rarer in the future. Integration is moving away from deprecated adapters like SOAP and SAP, into modern adapters like WCF-* and LogicApps (the latter is available in BizTalk Server 2016 only). Expect to see more SaaS integrations. Until then, avoid BizTalk being the first system moved to the cloud.

"I have specific legal and/or company restrictions"

Depending on the country of residence, the handling of data is usually restricted by legal requirements and government legislation. In addition, several companies have internal policies and rules in this regard. Although Microsoft currently has 34 Azure data centers, a lot of companies still have to move data out of their own country when utilizing cloud computing. This adds additional legislation to the picture. The legal and regulatory landscape around cloud computing is by no means static. There are new laws being proposed that could change the responsibilities of both cloud computing tenants and providers. This is a huge and complex subject, which also varies between countries. For these reasons, this is merely meant as an introduction. Use caution when moving data, servers and other company assets to the cloud.

"If it ain't broke, don't fix it"

There may be some hype associated with cloud computing, and what it can do. Let it be clear: Bad code on-premise will still be bad code in the cloud. Do not move to the cloud because it is something everyone else is doing, or because it is new and exciting. As mentioned previously, this must be a conscious decision anchored by management. Do things for the right reasons and in the right order.

Reasons why you should stay on-premise

The following scenarios describe why a move should be avoided, and in some cases they are showstoppers. Although it may be technically possible to move, it is not recommended.

"I need to use BizTalk Server 2010 or older"

Only BizTalk Server 2013 and newer versions are currently supported in Azure. If an older version is required, keep it on-premise. The illustration below shows the editions available in the gallery.

"I require > 99.95% uptime"

For all virtual machines that have two or more instances deployed in the same availability set, Microsoft guarantees connectivity to at least one instance at least 99.95% of the time. Note that this could mean up to approximately 4.5 hours downtime each year. If this SLA is not acceptable, avoid running BizTalk in Azure.

"I just want to save money"

This subject may be disputed, and several conflicting calculations have been presented by various stakeholders. It is definitely possible to save money by moving to the cloud, but running BizTalk 24/7 is by no means cheap. Using the Azure Pricing Calculator, this can be calculated fairly easily. Use this tool to get an estimate for an environment that meets the requirements. Remember to add all required components (BizTalk servers, SQL servers, networking, traffic etc.), and all required environments (Production, QA, Test). A typical setup can easily have a cost of several thousand dollars a month. It can be argued that the servers can be shut down when not in use (to save cost), but shutting down BizTalk environments during the weekend is not a very common scenario. On the flip side, if BizTalk is only meant to be used a short period of time (maybe as a POC), it will most likely be cost-efficient to run it in Azure.


As this article has described, there are several factors that need to be considered before making the move to Azure. Although there are many compelling reasons for moving, it is important to take the possible showstoppers into account. The main takeaway is to take all known factors into consideration and make the best decision possible for the business.

See Also

Another important place to find an extensive amount of BizTalk related articles is the TechNet Wiki itself. The best entry point is BizTalk Server Resources on the TechNet Wiki