I want to tell you about my journey migrating BizTalk Server to Azure beginning with the business case.
The authors of the the book “Migrating to BizTalk Server 2020” walked though the option of moving to Azure services or Azure Integration Services. I reviewed this book in my last blog and prompts me to revisit the reasons why I began migrating to Azure. Notwithstanding, this has not been easy and now that we are 75% complete it is a good time to review our original business case.
The Starting Point
To begin with, a third party maintains and pays for our BizTalk Server infrastructure. Therefore, we want to subsume that responsibility. Consider the following;
- Azure Integration Service Proof of Concept (POC)
- What are the options for moving responsibilities to us.
- Could we operate a BizTalk infrastructure ourselves?
- The case for BizTalk or Azure?
- What would our Azure Integration Services look like?
- The Cost model?
- What can we do in Azure without integration accounts?
Please bear in mind that what follows I wrote this in 2019 and is now anachronistic.
Azure Integration Service Proof of Concept(POC)
Firstly, the potential for Azure Integration Services to provide an alternative to our current provision of integration with BizTalk has only recently been a real option. Before this could be reasonably be considered a potential option, it was important to validate that we could deliver a comparable outcome through Azure as we do with BizTalk.
Thus, 3 POC’s successfully validated that this is the case;
- Customer Stream – Receiving orders, transform and process into our ERP
- Supplier Stream – Sending a purchase order from our ERP to a supplier
- Batch Extract Stream – Sending an invoice from our ERP
The outcomes of the POC are:
- Firstly, Azure Logic Apps replicate BizTalk integrations.
- Secondly, the team has the skills to complete the implementation successfully.
- Thirdly,we can transition an existing integrations without disruption to Bidfood and the trading partners.
- Fourthly, using BizTalk Schemas, Maps and Trading Partner Agreements makes migration quicker.
- Fifthly, Azure Service Topics & Azure Storage to provide points of persistence and a publish subscribe model to replace the same in BizTalk Server.
- Sixthly, migration of solutions occurs without touching any third-party applications.
- Finally, Transport protocols and message formats do not need to change.
Options for moving responsibilities to us
- Status quo
- Establish an on-premise BizTalk infrastructure and migrate operations to this.
- Operate BizTalk as a cloud hosted platform.
- Migrate off BizTalk to Azure Integration Services.
Status quo – Third party continues to operate the BizTalk infrastructure and absorb the costs
- Pros – No disruption
- Cons –
- Third party continues to take responsibility for the platform.
- $ a tough ask.
- DR not supported by Microsoft & we could lose in-flight data
- Microsoft future support for platform is unclear. No CU’s or FP’s for along time. No vNext details. BizTalk 2019 was promised 6 months ago. It will probably be BizTalk 2020. Subsequently BizTalk 2020 is now available.
- Finding people with the BizTalk Server skill set will be more and more difficult.
- No connector for Azure Storage in BizTalk 2016.
Establish an on-premise BizTalk infrastructure and migrate operations to this.
- Pros –
- Third party is no longer responsible for the platform.
- Microsoft supported DR can be achieved
- Cons –
- Microsoft future support for platform is unclear. See in 1.
- Finding people with the right skill set will be more and more difficult. See in 1
- We don’t have the networking skills in the team to operate an on-premise infrastructure.
Operate BizTalk as a cloud hosted platform
- Pros –
- Third party is no longer responsible for the platform.
- No lock in. Can leave any time.
- Cons –
- Microsoft future support for platform is unclear. See in 1.
- Finding people with the right skill set will be more and more difficult. See in 1
- DR and High Availability is much harder to achieve than on-premises.
- We don’t have the networking skills in the team to operate the Azure infrastructure. VNet, firewalls and load balancers.
Migrate off BizTalk to Azure Integration Services.
- Pros –
- Third party are not responsible for the platform.
- Networking and Server management abstracted away
- Don’t have to pay for servers.
- Microsoft release cadence is monthly and adding new features all of the time.
- Use Visual Studio Code for development instead of Visual Studio.
- Cons –
- No experience in setting up DR.
- Integration Account is not pay as you go. Thus, this might make this option too expensive .
Could we operate a BizTalk infrastructure ourselves?
| On-prem | Cloud |
|---|---|
 |  |
| Standard SQL Servers ( 1 Active and 1 Passive) | Enterprise SQL Servers (SQL always On) |
| Standard BizTalk Server | Enterprise BizTalk Servers |
| BizTalk 360 Server | BizTalk 360 Server |
| Hyper V with failover clustering for high Availability | VNet |
| -more- | Azure Active Directory |
| Migrating and validate 200+ interfaces, moving one by one. | Migrating and validate 200+ interfaces, moving one by one. |
The case for Migrating BizTalk or Azure
| BizTalk | Azure |
|---|---|
| BizTalk is fit for purpose, mature and robust. It is absolutely not broken. Given the high volume of transactions through this channel and the importance of maintaining stability, we would not take a decision to move off this reliable workhorse lightly. | Azure is clearly the future path that Microsoft is taking for integration technologies. In contrast the roadmap for BizTalk is not clear. It may be years away before this has an impact on us. |
| Everything we have needed to do to date we have been able to deliver. | Development platform alignment across all teams. BizTalk team responsibilities could be subsumed into other teams because cloud development is the same for all. |
| Capacity /scalability is not an issue. Without any increase in platform costs we can scale up for future platforms | |
| SDLC cycle is weekly | SDLC cycle is daily |
 |  |
Reference Articles;
The Cost model
Firstly we estimate the OPEX cost at using the Azure calculator . Critically, the major proportion of the OPEX cost is standard integration accounts for Production and Test (AU$32,900 p.a.). Nevertheless this is not too dissimilar to the cost of a BizTalk Server.
However, it is hard to estimate the migration cost because the cone of uncertainty is large. However, if I estimate the each interface will take between 0.333 and 1 day, I think the migration could take between 67-200 days. On the other hand, compare this to a BizTalk migration from one server to another which ased on past experience this takes about 90 days.
What can we do in Azure without integration accounts?
- Tactical solutions using Azure Logic Apps that do not use integration accounts can be created at low cost. Notwithstanding, this sentence was written when only consumption Logic Apps were available. Now standard Logic Apps offer new possibilities.
- Additionally other Azure components that we might use are
- Azure data Sync
- Azure data factory
