Articles

Open-Source Boomi Alternative (in Python)

Boomi customers report price increases of 50 to 100 percent at renewal since the 2025 pricing changes, on a model in which every new connection, runtime and environment adds to the bill, while still leaving the developers to drag and drop dozens of shapes to achieve what ten lines of Python code would do.

This article shows how Boomi processes become Python code on an open-source platform that is not metered, and where adding an integration adds no licenses.

By Dariusz Suchojad

11 min. read

Share this article:LinkedIn | FB | Email

Connection licensing and Boomi Messages

Boomi subscriptions are sold in editions - Base, Professional, Professional Plus, Enterprise and Enterprise Plus - which differ in the number of included connectors, and features such as parallel processing, message queuing, runtime clusters and enterprise connectors are add-ons in the lower editions.

The connectors are licensed per connection. Each unique connection component deployed to a runtime consumes one license, so the same connection deployed to two runtimes in one environment consumes two, and a copy of a connection with a new component ID counts as a separate connection. A deployment that exceeds the purchased licenses does not complete. Production and test environments draw on separate pools of licenses, and processes running on Boomi public runtime clouds are additionally metered by data volume.

The Pay-As-You-Go plan meters usage instead. It costs 99 USD a month plus 0.05 USD for each Boomi Message, and a Boomi Message is every inbound and outbound document of a process, regardless of its format or transport, including the responses of request and response interactions. Test and production messages are counted the same way, and existing subscription accounts cannot be migrated to the plan.

Vendors that migrate Boomi customers report the effect at renewal. Celigo states that the 2025 pricing changes, which introduced connector capacity and message caps, led to price increases of 50 to 100 percent at renewal in some cases, and Workato quotes former Boomi customers on prices that rose by 50 percent in 18 months.

In both models, architectural decisions become license decisions. A second runtime for high availability, a new test environment, a process split in two or a trading partner that sends many small documents each change the license count or the monthly invoice.

Zato is not metered. There are no licenses per connection, per runtime, per environment or per message, so new environments and new integrations are added as the architecture requires.

From drag-and-drop to Python

A Boomi process is built on the process canvas from steps that are dragged onto it and connected with arrows, up to 250 steps per process. Connector steps read and write data, logic steps such as Decision, Branch, Route and Try/Catch direct the documents, and in Map components the fields of a source profile are linked to the fields of a destination profile by drag and drop.

Logic that the steps do not express is written as custom scripts in JavaScript or in Groovy, in versions 2.4.13 and 1.5.8. Boomi describes the custom scripting step as a last resort - a script reads and writes the raw document streams, it cannot reference connections, profiles or maps, and ExecutionUtil is the only supported scripting API.

The logic of one integration is therefore spread across the shapes on the canvas, the property panels of each step, profiles, maps, map functions and scripts, all stored as components of the Boomi account and edited in the browser. A canvas makes the first integrations easy to draw and every later change harder to find, review and repeat. Drag-and-drop designers of this kind 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 contemporary 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. Channels, connections and security definitions are configured in the Dashboard, which also shows the audit log of every message that the integrations process.

Boomi concepts and their Zato counterparts

EDIFACT messages from trading partners, such as ORDERS, DESADV and INVOIC, are parsed into Python objects, routed by message type and serialized back byte for byte, in the same services that call the ERP, the databases and the REST APIs of the organization.

A Boomi process rewritten in Python

A typical Boomi process receives a shipment request, queries the ERP for the order, uses a Decision step on the order status, maps the shipment in a Map component to the booking format of the carrier and sends the booking to the carrier API. In Boomi, this process consists of a Web Services Server start step, connector steps for the ERP and the carrier with their connection and operation components, a Decision step, a Map component, a profile for each message format and a Return Documents step.

In Zato, the same service is one Python file:

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

# stdlib
from dataclasses import dataclass

# Zato
from zato.server.service import Model, Service

@dataclass(init=False)
class Shipment(Model):
    order_id: str
    warehouse: str
    carrier_service: str
    weight_kg: float

class BookShipment(Service):
    """ Books shipments with the carrier once the ERP confirms the order.
    """
    name = 'shipping.book-shipment'
    input = Shipment

    def handle(self) -> 'None':

        shipment = self.request.input

        # The ERP confirms the order before the carrier is booked ..
        params = {'order_id': shipment.order_id}
        order = self.rest['ERP'].get(params=params)

        if order.data['status'] != 'CONFIRMED':
            self.response.payload = {
                'is_booked': False,
                'order_status': order.data['status'],
            }
            return

        # .. the shipment becomes a booking request of the carrier ..
        booking = {
            'reference': shipment.order_id,
            'origin': shipment.warehouse,
            'service': shipment.carrier_service,
            'weight': shipment.weight_kg,
        }

        response = self.rest['Carrier'].post(booking)

        # .. and the caller receives the tracking number.
        self.response.payload = {
            'is_booked': True,
            'tracking_number': response.data['tracking_number'],
        }

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

Runtime and platform releases

Boomi states that runtime and platform updates are not optional. Each runtime release becomes available about two weeks before the platform release, and a runtime on which the release was not applied is updated automatically on the platform release date. The runtimes restart after the update, and Java updates are applied separately, so a release cycle that includes a Java update restarts a runtime twice.

The runtime is a Java application that requires Java 8 or Java 11, and Boomi provides security patches only for runtimes on Java 11.

Connector retirements

Boomi publishes its product and feature retirements, with deprecations normally announced at least six months in advance:

Retired connectors remain in the account and deployed processes continue to run, but the connectors are no longer maintained or supported. Boomi directs customers to successor connectors, such as Amazon S3 REST and Oracle E-Business Suite V2, and each process that uses a deprecated or retired connector is moved to its successor and tested again.

The retirement of the Boomi SOAP client

The Web Services SOAP Client connector is the connector with which Boomi processes call SOAP services, and the March 2026 release notes direct customers to the Web Services Server connector instead.

The Web Services Server connector listens for and accepts REST, SOAP and HTTP requests that other systems send to Boomi. It does not call SOAP services. For outgoing requests, the same documentation lists only the Web Services SOAP Client connector and the generic HTTP Client connector, so after the retirement a process that calls a SOAP service builds its SOAP envelopes and headers itself and sends them through the HTTP Client.

In Zato, SOAP is part of the platform in both directions - services receive and call SOAP services, with WS-Security, WS-Addressing, MTOM attachments and ebXML messaging configured in the Dashboard.

Converting Boomi processes with AI

Every Boomi component - a process, a map, a profile, a script or a connection - is defined in XML, and the Component object of the Boomi Platform API returns that XML for each component of the account. AI assistants translate it into Python services. An AI assistant reads the components of a process and writes one Python service, with the steps and maps expressed as Python code, the profiles as data models and the Groovy and JavaScript scripts rewritten in Python. 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 Boomi runtime. The same message is processed by the Boomi process and by the Python service, and the outputs are compared before the Python service receives live traffic.

The migration sequence

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

1. Inventory the processes. For each deployed process, record its connections and operations, profiles, maps, scripts, schedules, listeners and trading partners.
2. Define the connections. Every connection component becomes an outgoing connection in Zato, and every listener and API Service becomes a channel, created in the Dashboard and promoted to the other environments with GitOps.
3. Convert the processes with AI. An AI assistant translates the process, map, profile and script components into Python services and data models, and your developers review each service.
4. Move the trading partner exchanges. EDIFACT documents from B2B/EDI Management are parsed, routed and serialized by Python services in Zato.
5. Test with production messages. Messages from the production Boomi runtimes are sent to the new services, and their outputs are compared with the outputs of the Boomi processes.
6. Switch the endpoints. Each calling system, trading partner, file location and queue is pointed to the Zato channel in turn.
7. Retire the Boomi runtimes. When the last process carries no more traffic, its deployments are removed and the Boomi runtimes are shut down.

Where Zato runs

Zato runs on your own infrastructure - on physical or virtual servers, in Docker and in any cloud. It connects to the SQL databases, SAP, Salesforce, REST, SOAP, file transfer and message queue systems that Boomi processes connect today.

Upgrades are applied when your organization schedules them. Integrations are written in Python and administered in the Dashboard, where channels, connections, security definitions and scheduled jobs are created and every message is visible in the audit log, and environments are managed with GitOps, a modern practice in which every environment is built from your own Git repository. Enterprise support is available 24x7x365 from the team that builds Zato.

Boomi and Zato compared

Frequently asked questions

How are Boomi connectors licensed?

Each unique connection component deployed to a runtime consumes one connection license, production and test environments have separate pools of licenses, and a deployment that exceeds the purchased licenses does not complete. On the Pay-As-You-Go plan, every inbound and outbound document of a process, including each response, is billed as a Boomi Message.

How much have Boomi prices risen at renewal?

Celigo reports price increases of 50 to 100 percent at renewal in some cases after the 2025 pricing changes, which introduced connector capacity and message caps, and Workato quotes former Boomi customers on prices that rose by 50 percent in 18 months.

Can AI convert Boomi processes to Python?

Yes. The Boomi Platform API returns the XML of each process, map, profile and script, and an AI assistant translates them into Zato services and data models. 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 Boomi runtime before it takes over the traffic.

Can Boomi runtime updates be postponed?

No. Boomi states that runtime and platform updates are not optional. A runtime release that was not applied in the two weeks before the platform release is applied automatically, and the runtimes restart after the update.

Which Boomi connectors are being retired?

The Web Services SOAP Client and Marketo connectors are scheduled for retirement in November 2026, after the LDAP, MQTT, SFTP V2, Amazon S3 and Oracle E-Business connectors were retired in 2025 and 2026. The Database, Disk, FTP, JMS, SAP and SFTP connectors and the Atom Queue are in Legacy status and receive critical security fixes only.

What happens to Boomi processes that call SOAP services?

The Web Services Server connector that Boomi names in place of the SOAP client receives requests but does not call SOAP services. Processes that call SOAP services are rebuilt on the generic HTTP Client connector, or moved to a platform that calls SOAP services natively, such as Zato.

Does Zato process EDIFACT messages?

Yes. Zato parses EDIFACT interchanges into Python objects, routes messages by type and serializes them back byte for byte, as shown in the EDIFACT tutorial.

Can Zato and Boomi run at the same time?

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

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.