Articles

Open-Source BizTalk Alternative (in Python)

BizTalk Server 2020 is the final version of Microsoft BizTalk Server, and its support ends in April 2030.

This article describes the remaining BizTalk Server lifecycle, maps BizTalk concepts to an open-source platform in Python and presents a sequence for moving BizTalk applications to it.

By Dariusz Suchojad

11 min. read

Share this article:LinkedIn | FB | Email

A BizTalk application receives messages through receive locations, publishes them to the MessageBox database and delivers them through send ports to the systems that subscribe to them. Along the way, pipelines decode and validate the messages, maps transform them from one XML schema to another, and orchestrations drawn in Visual Studio coordinate the steps of a business process. BizTalk Server runs on Windows Server with SQL Server, and for more than 25 years it has carried the integrations of banks, manufacturers, retailers, hospitals and public administrations.

The end of BizTalk Server

On December 17, 2025, Microsoft announced that BizTalk Server 2020 is the final version of the product. No further version will be released, and Microsoft names Azure Logic Apps as the successor of BizTalk Server.

The remaining dates are fixed in the Microsoft lifecycle policy:

Microsoft expects sales of BizTalk Server 2020 to end on March 31, 2027. Between April 2028 and April 2030, Microsoft plans an optional, paid extended-mainstream support offering for BizTalk Server 2020, described as temporary migration coverage. It is expected to exclude Business Activity Monitoring, the ESB Toolkit, the industry accelerators, the legacy enterprise adapters, the BizTalk application lifecycle tooling and Visual Studio versions after Visual Studio 2022.

For BizTalk Server 2016, support ends on January 11, 2027, and Microsoft recommends a direct move to Logic Apps rather than an upgrade to BizTalk Server 2020. After April 10, 2030, BizTalk Server 2020 receives no security updates and no technical assistance. The applications continue to run, on a product that is no longer serviced.

What the move to Logic Apps involves

Microsoft states that BizTalk Server and Azure Logic Apps have different architectures. In Microsoft's migration guidance, orchestrations are refactored into workflows, routing through the MessageBox is redesigned on Azure Service Bus, RabbitMQ or Kafka, and Business Activity Monitoring is redesigned as well. The move to the Microsoft successor therefore rebuilds every orchestration as a workflow, in another visual designer.

Logic Apps Standard is billed for reserved vCPU and memory whether or not the workflows use them, every call to a managed connector is metered, and integration accounts for B2B processing are billed separately.

Because each orchestration is rebuilt in any case, the choice of the target platform is open, and the integrations can be rebuilt in Python, on an open-source platform, on your own infrastructure.

From drag-and-drop to Python

A single BizTalk integration consists of several kinds of artifacts. An XML schema for each message, a map that connects the schemas with functoids, pipelines with components in C#, an orchestration drawn as shapes in the Visual Studio designer, and a binding file for each environment, all of them deployed together as an MSI package. The logic of one business process is spread across graphical designers and files of different formats.

BizTalk Server is built on the .NET Framework, and its development tools follow the Visual Studio releases. Support for Visual Studio 2022 arrived in Cumulative Update 7, which requires a full new BizTalk installation and configuration from empty databases, followed by a rebuild of every project. Graphical designers on the .NET Framework belong to an earlier generation of integration software.

In Zato, an integration is a Python service. Python is the most widely used programming language - first in the TIOBE index for October 2026, and used extensively by 58 percent of the developers who answered the 2026 Stack Overflow Developer Survey. Python is also the language of data, machine learning and AI agents, the next generation of integration.

An integration in Python is one file that any Python developer reads, reviewed like any other code, versioned in Git and written fluently by AI assistants. It is developed in the IDE of your choice and tested with the built-in testing framework.

BizTalk concepts and their Zato counterparts

A BizTalk orchestration rewritten in Python

A typical BizTalk orchestration receives a purchase order, transforms it with a map into the sales order format of the ERP, sends it to the ERP through a send port and publishes the order to the MessageBox for the other systems that subscribe to it. In BizTalk, this process requires two schemas, a map, an orchestration, a receive location, a send port and a binding file.

In Zato, the same process is one Python file:

# -*- coding: utf-8 -*-

# stdlib
from dataclasses import dataclass

# Zato
from zato.common.typing_ import list_
from zato.server.service import Model, Service

@dataclass(init=False)
class OrderLine(Model):
    sku: str
    quantity: int

@dataclass(init=False)
class PurchaseOrder(Model):
    po_number: str
    customer_id: str
    lines: list_[OrderLine]

class ProcessPurchaseOrder(Service):
    """ Sends purchase orders to the ERP and publishes them to subscribers.
    """
    name = 'orders.process-purchase-order'
    input = PurchaseOrder

    def handle(self) -> 'None':

        order = self.request.input

        # The order becomes a sales order of the ERP ..
        lines = []
        for line in order.lines:
            lines.append({'item': line.sku, 'quantity': line.quantity})

        sales_order = {
            'reference': order.po_number,
            'customer': order.customer_id,
            'lines': lines,
        }

        # .. the ERP receives it ..
        response = self.rest['ERP'].post(sales_order)

        # .. every subscriber to new orders receives the order as well ..
        self.publish('orders.created', order)

        # .. and the caller receives the reply of the ERP.
        self.response.payload = response.data

The tutorial builds a complete integration of this kind, from an empty environment to a working API.

Converting BizTalk applications with AI

Orchestrations, maps, schemas, pipelines and binding files are XML and C# files, and AI assistants translate them into Python services. An AI assistant reads the artifacts of a BizTalk application and writes one Python service per orchestration, with the maps expressed as Python code and the schemas as data models. With the Zato documentation connected to it over MCP, the assistant uses the real APIs of the platform.

Each converted service is then reviewed by your developers and tested with messages from the production BizTalk application. The same message is processed by BizTalk and by the Python service, and the outputs are compared before the Python service receives live traffic.

The migration sequence

A migration from BizTalk Server proceeds one application at a time, with both platforms running side by side for as long as it takes:

1. Inventory the applications. For each BizTalk application, record its receive locations, send ports, orchestrations, maps, schemas, pipelines, business rules and bindings.
2. Define the connections. Every send port and adapter configuration becomes an outgoing connection in Zato, and every receive location becomes a channel, defined for each environment in YAML.
3. Convert the applications with AI. An AI assistant translates the orchestrations, maps and pipeline components into Python services, and your developers review each service.
4. Move the business rules. Each Business Rules Engine policy becomes a ruleset of the rule engine, which services evaluate at runtime.
5. Test with production messages. Messages from the production BizTalk applications are sent to the new services, and their outputs are compared with the outputs of BizTalk.
6. Switch the endpoints. Each sending system, file location and queue is pointed to the Zato channel in turn.
7. Retire the BizTalk group. When the last application carries no more traffic, the BizTalk servers and their SQL Server databases are shut down.

Where Zato runs

Zato runs on your own infrastructure - on physical or virtual servers, in Docker, in Kubernetes and in any cloud, including Azure. It connects to the Microsoft systems that BizTalk applications use, among them SQL Server, Dynamics 365, Microsoft 365 and Azure Service Bus.

Integrations are Python code and YAML configuration in your own Git repository. Enterprise support is available 24x7x365 from the team that builds Zato.

BizTalk Server and Zato compared

Frequently asked questions

When does support for BizTalk Server end?

Support for BizTalk Server 2016 ends on January 11, 2027. Mainstream support for BizTalk Server 2020 ends on April 11, 2028, and extended support on April 9, 2030. BizTalk Server 2020 is the final version.

Can AI convert BizTalk orchestrations and maps to Python?

Yes. An AI assistant translates orchestrations, maps and pipeline components into Zato services, and with the Zato documentation connected to it over MCP, it uses the real APIs of the platform. Your developers review each service and test it with messages from the production application before it takes over the traffic.

Can Zato and BizTalk Server run at the same time?

Yes. During a migration both platforms run side by side, and endpoints are moved to Zato one application at a time.

Does Zato connect to SQL Server and the other Microsoft systems?

Yes. Zato has connections for SQL Server, Dynamics 365, Microsoft 365, SharePoint, Teams and Azure Service Bus, described in the Microsoft integrations documentation.

Is Zato open source?

Yes. The source code of Zato is on GitHub.

How do I get started?

Start the tutorial or schedule a demo.

Dariusz Suchojad is founder of Zato Source.