BizTalk Server Reviews

The primary use cases for BizTalk Server involve logistic warehouse management for one of the business units.

Boomi has advantages over BizTalk Server because it is more flexible, low-code, no-code, easy to implement, and has a fast go-to-market. The dependencies with other applications are low, and a lot of connectors and adapters are easily available. We are also evaluating Workato, but it has some gaps we are trying to negotiate with the OEM.

Currently, I am working mostly with WebMethods and BizTalk Server.

I am generally satisfied with BizTalk Server, but there are some gaps, as we have multiple integration tools. Thus, there is associated cost, operation cost, license cost, and CapEx, so we are trying to consolidate all the integration tools.

Regarding BizTalk Server and data mapping tools, we want to get rid of BizTalk Server, as there is unnecessary license cost, and there are some limitations, so we might go for Azure Integration Services.

BizTalk Server is completely ruled out; we will not be proceeding with it. We initially planned to move to Azure Integration Services, but there are challenges with AIS, so now we are evaluating WebMethods IO because WebMethods is now part of IBM, which is performing well in the market, although the IBM license cost is too high.

The initial investment is too high, and we want to reduce that cost.

I have used Boomi for probably two years of my complete career, and I have been using WebMethods for the last five or six years.

My last experience with Boomi was two to three years ago.

I have worked with BizTalk Server almost 10 to 15 years back, and now again for the last two years, I am working with BizTalk Server.

There is a strong push from the business to minimize the go-to-market time for customer onboarding and to expand both vertically and horizontally quickly, as we are evaluating multiple scenarios.

It is time for low-code, no-code, and a quick go-to-market should be faster. I want customer onboarding to be fast, and we require a skilled developer.

BizTalk Server's ROI is comparatively higher than Boomi and Workato, and we are currently discussing whether we will go for BizTalk Server, Boomi, or Workato.

We are evaluating Workato or Boomi now.

We might go for Azure Integration Services if we have to go for BizTalk Server.

We are now evaluating WebMethods IO because WebMethods is now part of IBM, which is performing well in the market.

I have not worked with Amazon API Gateway or Mule ESB; I am just testing them.

I am using Boomi iPaaS and WebMethods.

I did not purchase it on AWS Marketplace; those are product API systems, and in my current organization, we currently have WebMethods in our on-prem environment, and Boomi is again on AWS with an instance installed.

I am using Boomi in my previous organization, not my current one.

I did not buy it on AWS Marketplace; we directly approached the product vendor, OEM, took the license, and started using it.

I would rate BizTalk Server a five out of ten due to pricing, flexibility, and the lot of coding required.

I am not a partner of Microsoft; I am just a service provider to my business team, serving as a technical delivery manager, providing integration services.

Our usual use cases for BizTalk Server include mobile app integration with BizTalk Server, website integration with BizTalk Server, and other applications because we are from a utility company.

I utilize BizTalk Server's protocol and JDBC adapters for integrating legacy systems and modern cloud services. BizTalk Server doesn't have many cloud adapters, but IBM WebMethods has numerous adapters, such as Salesforce connector and Talend connector. This is why we are working on IBM WebMethods.

I have employed BizTalk Server's business rule engine in my operations. This feature has helped us make real-time data-driven decisions.

The BizTalk Server business rule engine was very useful for us and has helped us for the last 12 years. I definitely find the business rule engine a feature that is remotely useful.

Biztalk server doesn't have API management so that our exposed can be protected against the SQL injection, DOS attacks. However, this is available in IBM WebMethods.

The positive impact of BizTalk Server was initially limited because of scalability issues. That is the reason why management has decided to implement IBM WebMethods. We are going to decommission BizTalk Server next year.

I believe the API response could be improved in BizTalk Server. We need to increase the number of servers in BizTalk Server. We used to have two servers; later on, we increased to a third server, which has improved performance. We can make it more highly available and scale out to improve BizTalk Server. Scale out means we can increase the number of servers horizontally.

I have been working with BizTalk Server for more than 12 years.

BizTalk Server is good for small companies but not for big companies.

BizTalk Server is stable right now, however, we are working to migrate Biztalk services to IBM WebMethods platform.

We are currently using BizTalk Server on-premises.

We have not done any automation. For orchestration, we have accomplished many things. It is a good product, but we are moving to a new platform because it is an on-premise solution. We are moving to a hybrid integration cloud-based solution.

The first year for BizTalk Server is expensive. After renewal, it becomes 20%, making it cheaper.

Good

Neutral

I have experience with solutions, specifically using IBM WebMethods. At the moment, I'm happy with IBM WebMethods including API management, developer portal, Terracotta, Universal messaging server.

From an integration perspective, I have been working with other technical solutions for the last 12 months and could share my feedback with PeerSpot.

Through vendor. 

We are happy that BizTalk Server has served around 10 years, and that is acceptable. Now the direction is to move away from BizTalk Server to IBM WebMethods, which has more features compared to BizTalk Server. The company's return on investment is acceptable; we are on the positive side, but even then, we are moving away due to new features on IBM webMethods.

Biztalk server on-premise is a perpetual license and IBM WebMethods are subscription based like count of invocation of API calls, Integration calls. IBM WebMethods is expensive due to multiple solution components like API management, developer portal, Terracotta, Universal messaging server. These components provide more security and enhanced performance improvement.

Biztalk server came through bidding process for our utility website development.

We are still working on BizTalk Server. However, our direction is to move away from BizTalk Server.

For BizTalk Server's monitoring and alerting tools, we are using a BizTalk 360 monitoring tool. BizTalk 360 is a product that helps us in getting the insight of API response and number of API calls.

On a scale of one to ten, I rate BizTalk Server a six.

My customer's usual use cases for BizTalk Server are mainly for electronic data interchange, EDI. For example, they exchange documents such as orders and invoices in a structured way, sending invoices from SAP to customers using other systems. They use numerous standard formats such as EDIFACT or TRADACOMS in the UK. My main work is to implement the translations from one system to another or from one system to a standard message format.

The features of BizTalk Server I have found the most valuable include all the connectivity to systems such as SAP and others. It is sometimes a complicated system, but you can do almost everything with it.

BizTalk Server offers workflow functionality that I find very effective for process automation. They call it orchestrations where you can define logic for integrating systems.

Regarding the adapter framework in BizTalk Server, I usually work with standard features. You have a tool called BizTalk Mapper, where you can define the mappings between different formats. It's less about programming on the very low level; it's rather doing configuration on a higher level.

BizTalk Server needs improvements, especially because we use it for EDI messaging, and it would be very useful to have enhanced tracking capabilities for message tracking and archiving of messages. There is no built-in functionality for this, and you have to organize it yourself by storing files, storing messages to the file system and maintaining tables for registering the messages that went through. Other systems or vendors are offering special message tracking capabilities.

The scalability should be improved as it currently rates at six out of ten.

I have been working with BizTalk Server from the very beginning, from the first version since the year 2000.

I did not participate in the initial setup or in the deployment process as it's not my area. What I heard is that it's often not easy, and you need experts. You must have the right operating system versions and install some additional software before you can install BizTalk Server, making it somewhat complicated.

BizTalk Server's stability rates about eight or nine out of ten. It's stable if you have been able to rule out some problems.

When it comes to scalability, I do not really have a clear view as we do not have any cluster installations. I do not have any experience, but if you have to implement clustering, it's possible. Based on my knowledge, I would rate it six out of ten.

I do not have any direct experience with the technical support of BizTalk Server, as I did not have to deal with the installation or the setup.

There has been no contact with Microsoft directly for technical support. We had another consulting team who was very experienced in setting up BizTalk Server, and they did a good job.

Positive

I have been working with other technical solutions, specifically Microsoft BizTalk Server.

I do not have any pricing experience for BizTalk Server. The only thing I heard is that it's not inexpensive.

BizTalk Server has adapted to the changing needs of business over time with steady development, but there are new requirements, for example, on APIs, application programming interfaces. That functionality is somewhat missing in BizTalk Server currently. Over the years, they made progress in functionality, but BizTalk Server should be shut down or duplicated by 2028, maybe 2030. So I don't expect many improvements there.

I am a consultant, and I do the integration projects for my customers.

The customers of BizTalk Server that I work with are mostly enterprise businesses. They use this BizTalk Server solution worldwide.

Overall, I would rate BizTalk Server eight out of ten based on my experience.

The solution runs on-premise. It is a good middleware product that Microsoft has developed. It is used by the manufacturing, oil, and gas industries, as well as many other platforms. Many other products have evolved in the market, but BizTalk is still standing because of its performance. It is capable of pushing a maximum volume of data from a source system to a target system. It has a good capacity.

The AS2 communication protocol is one of the most advanced processes. It enables a handshake with the source and target systems using certificates. It is the most secure way of communicating between two systems. It is an advantage. We can do a lot of message routing. If we want to handle large data, we can put the data into different patterns to process it. We can do it through sequential convoy or parallel convoy orchestration.

BizTalk comes with SQL Server. We can load temporary data in the database and use the batch process from BizTalk. It is an added advantage. Creating agreements is a manual job, but it's quite easy in BizTalk. Even a fresh college graduate can configure AS2 certificates and partner profiles and communicate with other systems. It is easy.

BizTalk is deployed on-premise. Deployment methodologies are vast in the cloud area. Whereas, if we want to update even a single thing on BizTalk, we need to take the DLL, put it in the system, and restart the host. Updating things in BizTalk is a headache. Sometimes, if we don't refresh and restart the host, the change will not reflect. These are minor loopholes that I've been seeing in the tool.

BizTalk has some demerits. When we do large-scale integrations, the host goes down for no reason. The tool does not show a proper error. We need to get through the Windows app console and find out the actual error, why the host got terminated, and why the processes stopped running. Such issues happen for no reason. We have communicated the issue to Microsoft. The vendor says that there are some issues that they will take care of in the next BizTalk package. Sometimes, improvements happen from Microsoft’s side.

Five of our customers are using the solution. Each project needs a maximum of ten BizTalk developers.

There are only a few engineers who have good knowledge about the solution. Not all the support persons will be knowledgeable about BizTalk. Sometimes, I get my query resolved with a call; other times, I have to do a lot of follow-up for certain issues.

Neutral

We must follow the documentation based on the organization set up for the deployment. To set up the product, we need the support of the infrastructure, network, and IT teams. We can set it up as developers, but we also need the servers. So, we depend on the network and IT personnel to set the environment. The installation is moderately easy since it comes with SQL Server. We need to go through many steps to install BizTalk in our system.

A business from a small-scale industry will not see a return on investment from the tool. However, a company from a large-scale industry can opt for the product and set up an in-house system on-premise. Small and medium-sized businesses looking to pay less for the processes must opt for cloud solutions because cloud environments provide pay-as-you-go services. So, if we process 10,000 transactions daily, we only have to pay for 10,000.

The solution is expensive.

Since cloud solutions are on the rise, people are trying to move out of on-premise systems to systems hosted in the cloud that do not need physical servers. I am also doing a lot of migrations from BizTalk to Azure. However, there are a lot of limitations to the cloud. We pay as we go, so the cost of cloud solutions is huge. Cloud solutions enable organizations to handle data easily and provide various subscription options. It all depends on the project's architecture and design.

When I started my career with BizTalk, people told me the vendor would sunset BizTalk Server, but it didn't happen. Higher versions are still being released. The product will not face the sunset. A lot of companies are working on BizTalk Server for large-scale integrations.

I recommend the tool if an organization wants to process large data through an on-premise system. To perform well, we must undergo a lot of training to learn about the orchestration process. If someone plans to buy the product, I suggest they do a thorough R&D since the cost is quite high since it comes with SQL Server.

They must do some R&D to understand why they want to use BizTalk. They must understand whether it will be an organization-wide process for the middleware system, such as SR data, finance data, and internal billings. If they want to do a lot of processes, they can use BizTalk. If they want it only for finance or HR data, I suggest using a cloud-based product. People must evaluate tools based on the volume of data and how many processes they will take care of.

The Business Rules Engine works well. The latency depends on how many applications we are running. If an EDI is processed by the tool, the orchestration will consume memory. It will be faster based on how many EDIs are processed. The memory will be at stake if we process one lakh EDIs simultaneously. The tool will release the transaction based on our concurrency.

The AS2 communication is pretty fast. If we load more than the specified limit on the BizTalk Server, it will be dead until we terminate the instances. If someone wants to use the solution, they must have basic programming knowledge like C#, .NET, and SQL because they need to design the C# function during orchestration. If a person has basic programming knowledge, they can kick start the training. There are a lot of modules available. They can take three months of training. After the training, they can start working on projects from the fourth month onwards.

Overall, I rate the tool an eight out of ten.

BizTalk Server is used to connect between two systems. If you have one system as the source and another as the destination, it acts as a bridge. You can do transformations – the source system can send in a different format, and you can convert that schema into the destination schema. You can do transformation, and you can use orchestrations. There are a number of features in BizTalk.

We can use it for multiple purposes, mainly for messaging – to transfer messages from one location to another. We have various supports, send ports, receive ports, and other use cases as well. If you have conditions, you can use the Business Rules Engine (BRE). For tracking purposes, you can use Business Activity Monitoring (BAM).

There are so many databases involved because BizTalk stores all messages in the MessageBox DB, along with your Management DB and Tracking DB. In the Admin Portal, you can track messages. 

If there are any failures due to network issues, okay, you can go to that step and resume the instance. From that step, it will continue. If the destination system is up, then it will go and create the record. You have so many adapters as well: File adapter, HTTP, basic web HTTP, SFTP, FTP adapter... the list goes on.

The most valuable feature is its reliability and stability. The first version of BizTalk was released in 2000, and many companies still use it. It was stable until 2013 when we had support. 

In the 2016 version, they gave the option to connect to Azure Logic Apps and adapters. And in the 2020 version, we have direct connectivity with Azure AD. We have so many virtual tools... There are competitors now, such as MuleSoft, which is owned by Salesforce. However, as a Microsoft admin, I have a strong preference for BizTalk.

It is easy for a beginner to learn BizTalk. I was trained in .NET technology, then I gradually learned BizTalk on my own. You can install VMware and get the community version of BizTalk to practice and do POCs [Proofs of Concept]. The development environment lets you use the admin console and test everything, so it's easy to see if BizTalk is a good fit. If you want to learn BizTalk for the first time, you can definitely do it.

Some room for improvement means... it's legacy. It's an on-premises system, requiring physical servers for deployment. This is different from Azure; you don't need any servers with Azure. If you have a subscription, you can do whatever you want. There are unit restrictions based on the environment (like non-production vs. production) in BizTalk. You need physical servers and databases. In Azure, those are not required – it's all in the cloud.

Now, we have the option of integrating accounts and the On-Premises Data Gateway to connect on-premises BizTalk with Azure. But the trend is moving towards Azure. Not everyone wants a hybrid model. Companies are still going with hybrid scenarios, but they want both BizTalk and Azure.

See, whatever you can do in BizTalk, you cannot do the same things the same way in Azure. One example is tracking. In BizTalk, especially for production environments, messages are easily stored within the MessageBox database. Support can assist in retrieving them directly. It's not as easy to track in Azure – everyone can potentially access it, and even reprocessing is different.  Logic Apps have a preview mode. If a Logic App is stuck at a particular action, you can resubmit from there. 

Microsoft is still making improvements – I don't know when they'll have general availability for these features. However, tracking and message storage are more complex in Azure. We have to use Azure Blob storage for archiving, whereas in BizTalk, it's a built-in feature of the MessageBox DB. If you need to debug at any point, you can do so easily in BizTalk.

This is one aspect influenced by the on-premises nature of BizTalk. Since everything is moving to the cloud, Microsoft will also end support for BizTalk Server 2030 – there won't be any further support. I don't think they'll release any new versions. 2020 was the last, and it's been four years. After the end of support, I think companies currently using BizTalk will move to Azure or another cloud-based integration technology.

I started my career with BizTalk and worked for eight years exclusively on BizTalk. Then, last February, I switched companies. I'm currently with Shell, working on Logic Apps now.

We still do some migration from BizTalk Server 2016. I do some analysis in BizTalk and convert that, sending it to Azure.

We got support; Microsoft is still providing support for BizTalk. I have a few friends working at Microsoft on the support team. So, the support is there.

Even in the tech community, people are writing blog posts about BizTalk. If we can't find an answer there, then we'll go to Microsoft and raise a ticket. 

I started my career with Accenture. In 2018, there were many BizTalk projects, and hundreds of people were using it. In my last company, we had a Salesforce to back-office migration project, and BizTalk was used as the integration layer. There were only five to six people working on BizTalk there.

Compared to Azure, the initial setup is a little bit difficult. And it's not all done in one go like Azure. You might have integrations with third-party systems, which you can do in BizTalk, too. 

We have to configure those in Azure DevOps, which is similar to how we manage pipelines and releases. But for the initial installation, you have to do that manually. 

First, you install Visual Studio, then SQL Server, then BizTalk. Those three are mandatory because all development is done within Visual Studio.

It was not cheap. It's affordable, but compared to Azure, it's more costly because you have to buy licenses upfront. 

With Azure, you have options: consumption-based or a standard monthly price from Microsoft. Consumption-based means you're charged based on usage.

Overall, BizTalk is more expensive than Azure. And it's also more time-consuming if you compare it to Azure. 

In Azure, deployment is much faster. Azure still requires some setup in GitHub for CI/CD and Terraform scripts for deployment. 

BizTalk has multiple deployment methods – MSA packages, direct deployment, or Azure DevOps. So, BizTalk installation takes more time than Azure.

Overall, I would rate this product a ten out of ten because I started my career with BizTalk and still love it.

All companies now prefer cloud solutions like Azure over BizTalk. So, we have to upgrade our skills to match the market trends.

If someone had asked me this three years ago, I would have analyzed the requirements and explained how BizTalk might fit. But now, everyone is preferring cloud solutions.

If someone is starting a brand new project, I don't think anyone will prefer BizTalk at this point because Microsoft support ends in 2030. That's why people are choosing Azure over BizTalk.

Recently, I migrated BizTalk applications into the Azure integration site, including Logic Apps, repair management, and some files. I implemented all of the DevOps setups, so I'm aware of BizTalk pipelines and development.

If you're a client, you can use BizTalk as middleware. For instance, you can treat SalesForce as a destination if you want to communicate IDOCs to SalesForce subjects. In that case, BizTalk will be the middleware and will do the data transformation in the mapping or orchestration. If you want to use any policies or data transformations, you can implement it in the mapping level and implement some policies. 

We can apply some mapping and policies in BizTalk, like BAM policies or BRE policies. We can do all kinds of data resolution. The SalesForce objects will accept the same kind of format, and we can develop and do the data transformation in the same way. We can do the mapping and convert the data from the data center into XML.

I used the 2016 version of BizTalk. The solution is deployed on-premises.

The number of users is limited. We're able to restrict users. We created a security group and gave access to four to five members, so only those people can use the particular server.

The most valuable feature of BizTalk Server is that it will turn XML into flexible transactions.

We can implement complex mapping and integration across the account. We can split pipeline concepts based on requirements and process everything. It's based on the demand. Whatever it is, we can implement it in the XML Disassembler or .class file decoding. We can split, unzip, and encode pipeline concepts.

If you're working on Edifecs transactions, you need to create the business profiles and agreements based on how it will work and transform. It will process the transactions based on this identifier and the digital profiles.

When I'm working on development side data, we don't use any DevOps. We implement Orchestrator, and it's BTDF.

BizTalk Server isn't flexible for Canonical Schema. If there's only one schema sample and it doesn't match the case, the mapping will fail. When something has failed, the message doesn't specify what the problem is.

The deployment could be simplified. For the DLL and schema upgrades, it puts everything into individual folders, which we cannot maintain. We can do the application deployment in one shot. There's no dependency on other applications. If you have any references to other applications and if something goes wrong, the other application will not work.

In the 2007 version of BizTalk, the Orchestration Debugger showed exactly what was failing. If there's a mapping issue, we can't see what it is. It simply mentions that a file has failed because of a certain change. It would be helpful if it showed mapping. 

When we use a web service, we cannot identify exactly where the messages are flowing into the particular server and whether the certificate is expired. The support guide isn't updated properly for certificates. They're updated in the private repository. If this happens, we can't send particular services.

I used BizTalk Server for development about four and a half years ago. Recently, I used some BizTalk admin tools for migration purposes.

It's stable for limited transactions. If you're processing more than 10 GB of data, BizTalk Server will take a lot of time. It can process one file of 1 GB of data in 4.5 hours. 

It's easy to process 2,000 files with less than 3 MB or 5 MB of data. If you process ten 1GB files, it will take more than two days.

The solution is scalable.

I'm also using Azure Logic Apps. Most of the features are similar. There are extra features, and we can easily transform the data in a secure way using API management.

In Logic Apps, we can use the integration map to integrate our code. There are pipelines, so if you want to do any kind of data consumption, you can implement it in the same way in Logic Apps and Data Factory. There are two ways that we can implement it, but we prefer using the updated version of Logic Apps.

I have recently migrated a lot of projects through Logic Apps.

Setup is very easy. If you have already installed SQL Server and Visual Studio, then BizTalk will take those libraries and install it automatically.

Initial setup took between two and three hours. We needed to install Visual Studios and SQL Server, which takes a lot of time. BizTalk can be installed very quickly compared to Visual Studio and SQL Server.

The cost will depend on the client's requirements. If the client has very small business transactions, then we can reduce the cost. If the client wants it to be more secure, then the cost will be very high based on the transactions, requirements, and security policies.

The solution is worth the cost.

I would rate this solution as seven out of ten. 

I have learned a lot from working on BizTalk server. There are new features we can implement in that time. For transactions, they can simplify all of the values for schema-free use. If they want to pick one field from the schema, they can write an excerpt in the expression shape and the orchestration. There's an advantage with using BizTalk. Basically, BizTalk is an XML to XML transaction, so it's better to use BizTalk server.

My advice is to understand the client's expectations. Do they want a more secure way of using third party services? Based on their requirements, we can determine whether they should use BizTalk or upgrade to Azure. If someone wants to use BizTalk, they need to buy VMs and install Visual Studio, SQL Servers, and BizTalk Server. They also need to buy all of the licenses.

They will need Microsoft support initially for deployment, Azure, and maybe even DevOps tools. If they install BizTalk Server in a different way, they will want to deploy the DLLs and SSLs to PowerShell scripts in DevOps. DevOps lays out the activities they're using. If there are heavy transactions in the SQL Server, they have to upgrade their sequencer hosts and DVs.

I would recommend Azure instead of BizTalk.

For Azure integrations, there are also API capabilities. Right now, my organization is using Azure, so they're using SFTP folders, but it's intermittent service. All of these activities have moved to the cloud. It's a more secure way of data transactions through the use of tokens. It can be restricted, and you can convert it into API and bond policies. It's more secure.

The primary use case for BizTalk Server is within the shipping industry environment. Our organization relies heavily on electronic data interchange for government invoices and related system data.

The platform's most valuable feature is code integration.

The product could be improved in monitoring, managing, and support functionalities. Specifically, enhancements in monitoring and logging capabilities and better support for administrative tasks would be beneficial.

We have been using BizTalk Server for 3 years.

The product is stable. It has been in operation for more than 24 years.

We have 60 BizTalk Server users in our organization.

We have contacted the technical support services.

Positive

The switch to BizTalk Server was driven by the company's preference for using Microsoft products exclusively.

The initial setup of the BizTalk Server can be described as complex and challenging. It involves tightly coupled configurations, particularly when transitioning to multi-load balancing environments and multiple architectures.

I am not familiar with the platform's pricing details. However, based on the knowledge, it is relatively cheaper than Azure Identity Services and cloud services in general.

It is a legacy system with reliability and extensive features in one package. It is easy to integrate with third-party solutions. We have some 22 built-in adapters with Microsoft, which you can use to connect to older or newer versions.

It takes around six months to understand everything about the BizTalk server. When we restart our integration, we have to understand the core concepts of integration. The concepts are more theoretical than practical.

I rate the product an eight out of ten. It is reliable, especially when load balancing or processing millions of messages daily. We can handle a large number of messages without any issues, ensuring that everything runs smoothly.

BizTalk is middleware. It integrates different systems, like ERP and CRM solutions. For some systems, BizTalk has built-in adapters, while for others, we either develop custom adapters or use third-party ones to establish connections.

Compared to the current solutions I use, like Azure Logic Apps and other cloud services, BizTalk was far better and more reliable. 

Right now, we face data loss due to timeouts and other restrictions when using Azure Logic Apps and similar features. For instance, in Logic Apps, we can't use very large SQL queries. If a query doesn't execute within two minutes, it automatically times out – the default Logic App timeout is five minutes. 

However, we didn't have these kinds of limitations with BizTalk Server. Additionally, BizTalk Server offers superior speed and faster processing.

It is easy for a beginner to learn to use BizTalk Server for the first time. It is low-code and relies on configuration instead of extensive coding, so it's considered low-code.

I'm not sure if BizTalk will survive much longer. Microsoft already offers a cloud-based alternative – Azure Logic Apps. With the shift towards cloud computing, most companies will likely choose Logic Apps if they need Microsoft technologies for a BizTalk replacement. There are other competing technologies out there as well.

If Microsoft wants BizTalk to remain competitive, they need to address the cost factor. Other technologies are less expensive compared to BizTalk. 

Additionally, BizTalk lacks native cloud support. BizTalk doesn't offer in-built support for cloud. We need to use third-party adapters to connect it to cloud services.

I started using BizTalk in 2010 and worked with it until around 2016 or 2017. 

Since then, I've had projects where BizTalk wasn't heavily used – we had an existing application that needed minor changes in XSLT. However, the core functionality of BizTalk hasn't been in use for the last four or five years.

We aren't actively developing in BizTalk, but the migration from BizTalk requires a good understanding of its concepts for a smooth transition.

Initially, there were cloud options, but those weren't widely adopted, so they were removed. Now, we typically install BizTalk Server on a virtual machine within an on-premises setup.

BizTalk was stable. However, it's becoming somewhat obsolete due to the rise of open-source alternatives. As a result, most companies are migrating away from BizTalk due to cost and its limited cloud support.

Nowadays, very few people actively use BizTalk for new development. Most are involved in migration projects, converting BizTalk logic to technologies like MuleSoft, Azure, and other competitors. Now, everything is going to cloud, this is where BizTalk guy with experience to understand the existing logic and convert it to other technologies is required.

Currently, I work with ADA Logix, Function Apps, and BizTalk at another company. We've to migrate from BizTalk, so a basic understanding is necessary to transition the application into ADA or Logic Apps.

When BizTalk Server was new to us, we would copy the MSI and bindings manually from one server to another. But later, when we adopted CI/CD practices, deployment became much easier. With CI/CD, it was a one-click process. Setting up the CI/CD pipeline requires configuring server environment variables. But, after that initial setup, it's easy to use and deploy.

BizTalk Server is not freeware. There's a significant licensing cost involved. Be sure you will actually utilize its features fully. In my previous organization, we weren't taking advantage of BizTalk's capabilities, yet we were paying for it. 

If you're not using BizTalk's full feature set, it's a waste of money. We eventually realized this and were able to achieve the same type of manipulations using .NET code without BizTalk. They later removed BizTalk completely. So, my advice is to carefully consider whether you'll truly benefit from BizTalk's features before investing in it.

If I disregard cost and the lack of native cloud support, I'd rate it a seven out of ten. It's reliable when configured properly. However, compared to the technology I'm currently using (Azure Logic Apps), I face issues with timeouts and resource constraints. For that reason, I'd rate my current experience lower.

BizTalk Server is used for system integration. Individuals convert different messages into different formats, which are transmitted through BizTalk. The solution is also used for some really brief orchestrations as well. Sophisticated workflows are really slow if they are managed with BizTalk.

BizTalk's integration with Visual Studio is the most valuable feature of this product. It makes everything easier than if you are using external tools, or if those tools are not integrated with the developer suites. 

BizTalk Server needs to improve its performance. I'm not sure that we have the right infrastructure for this installation, but my previous experience when we were testing BizTalk and comparing it with web methods demonstrated that a huge flow of small messages actually frustrates BizTalk. 

The solution has to use external memory, which requires effort in the opening and closing of messages and connecting them. The bottleneck is something that is implemented internally, but this bottleneck is showing up when you are transmitting a lot of messages.

BizTalk is in the past, Microsoft is not going to evolve it any further or add any new features. 

I have been using BizTalk Server for 20 years. I was part of the team who implemented the solution in our country.

BizTalk Server is quite stable. I have not experienced any crashes or anything that would prevent operations.

This solution is not very scalable. As the number of messages increase, you can expect some UAs. Also, if you use excessive conversion among different formats like EDI, you should expect some issues.

I have never contacted technical support from Microsoft. Everything can be resolved by using their documentation.

The initial setup of BizTalk Server is easy. Microsoft provides good documentation that covers everything. In total, it takes one to two days to deploy this solution.

Many solutions are moving to open source, and because of this, I would say that BizTalk Server is becoming obsolete and will become eliminated in the near future.

A solution like Kafka would be better if you are implementing integration systems that process messages between the data warehouses or the data lakes.

My advice to anyone considering implementing BizTalk into their organization would be to consider something newer because BizTalk is losing its value. It has been replaced with Azure Functions or Azure Applications.

Overall, I would rate BizTalk Server a five out of ten. It is not modern, however, it is alive and kicking.

We use the product for verification with the bank. 

The tool's most valuable feature is its integration with the banks. Its messaging and routing capabilities are good. 

The product's deployment can be quicker 

I have been using the product for a year. 

I rate the tool's stability an eight out of ten. 

BizTalk Server's scalability features made it easy for us to handle increased volumes of verifications. I rate its scalability a six out of ten. My company has ten users who use it once a week. 

I rate the tool's ease of deployment a seven out of ten. It didn't take long to complete. 

I recommend the product since it has helped us with verification and messaging. I rate it a seven out of ten.