Articles

Open-Source webMethods Alternative (in Python)

Standard support for webMethods 10.15 ends in October 2027, and from webMethods 11.1 the products are licensed by metered transactions.

This article describes webMethods under IBM, maps webMethods concepts to an open-source platform in Python and presents a sequence for moving Flow services to it.

By Dariusz Suchojad

10 min. read

Share this article:LinkedIn | FB | Email

webMethods Integration Server runs the integrations of many banks, manufacturers, logistics companies and public administrations. Its integrations are Flow services, built in webMethods Designer, together with Java services for the logic that Flow does not express. They are organized in packages, connect to databases and applications through adapters, exchange messages through Universal Messaging and reach trading partners through Trading Networks, while API Gateway exposes and secures the APIs.

webMethods under IBM

IBM completed its acquisition of webMethods from Software AG on July 1, 2024. The support of webMethods customers moved to the IBM support site on April 14, 2025, and Empower, the Software AG customer portal, was deactivated for webMethods customers on the same date.

The product line has been renamed and reorganized since then. The SaaS platform once called webMethods Hybrid Integration is now sold as IBM Integration SaaS, the self-managed product is IBM webMethods Integration, and the current release of the self-managed product is webMethods 12.1.

The webMethods 10.x lifecycle

IBM publishes the support dates of webMethods 10.x in the webMethods 10.x product support lifecycle:

Ongoing extended support covers usage questions and known defects only. The extended support periods exclude fixes for third-party software packaged with API Gateway, such as Elasticsearch and Kibana, and where the JVMs, operating systems or databases under a release are no longer supported by their own vendors, IBM limits its support to commercially reasonable efforts.

What the move to webMethods 11.1 and later involves

An upgrade from 10.x is a side-by-side upgrade. The new release is installed next to the old one, the databases are migrated with Database Component Configurator, and migration utilities carry the configurations, data and assets of each product to the new installation. API Gateway 10.5 is upgraded in two steps, first to 10.15 and then to 11.1.

The tools change with the runtime. In 11.1, Designer moves to Eclipse 4.25 and Java 17, and Universal Messaging supports only Java 17 for its server, client and tools.

The licensing changes as well. IBM states that from webMethods 11.1 there are no product license keys. Integration Server, Trading Networks, API Gateway and ActiveTransfer are metered products, metering is part of a transaction-based contract, and on an upgrade to 11.1 the transaction duration for services, flows and workflows is set to 60 seconds. Customers who convert a core-based or perpetual contract to a transaction-based one receive new, metered license keys for their 10.x installations.

From Designer to Python

A Flow service is built in Designer from flow steps - INVOKE calls a service, MAP links, adds and drops variables in the pipeline, BRANCH, LOOP and REPEAT direct the execution, and TRY, CATCH and FINALLY handle failures. The data of a service travels in the pipeline from step to step, and each mapping is drawn as links between the fields of the pipeline. Logic that the flow language does not express is written as Java services, and the message structures are defined as document types.

The logic of one integration is therefore spread across flow steps, the property panels of each step, pipeline links, Java services and document types, in packages that are deployed to Integration Server. webMethods belongs to the generation of integration products built on Java application servers and graphical designers.

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. Channels, connections and security definitions are configured in the Dashboard, which also shows the audit log of every message that the integrations process.

webMethods 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 Flow service rewritten in Python

A typical Flow service receives an order, uses a BRANCH step on the payment type to charge card payments through a payment provider, maps the order in a MAP step to the sales order format of the ERP and invokes the ERP. In webMethods, this service consists of a flow with INVOKE, BRANCH and MAP steps, document types for the order and the sales order, pipeline links in every MAP step and a REST resource that exposes the flow.

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 Order(Model):
    order_id: str
    customer_id: str
    payment_type: str
    amount: float
    currency: str

class ProcessOrder(Service):
    """ Charges card payments and sends orders to the ERP.
    """
    name = 'orders.process-order'
    input = Order

    def handle(self) -> 'None':

        order = self.request.input

        # Card payments are charged before the order reaches the ERP ..
        if order.payment_type == 'CARD':

            payment = {
                'reference': order.order_id,
                'amount': order.amount,
                'currency': order.currency,
            }

            self.rest['Payments'].post(payment)

        # .. the order becomes a sales order of the ERP ..
        sales_order = {
            'reference': order.order_id,
            'customer': order.customer_id,
            'payment': order.payment_type,
        }

        response = self.rest['ERP'].post(sales_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 Flow services with AI

Flow services, document types and their pipeline mappings are stored as XML files in the packages of Integration Server, and Java services as Java source files. AI assistants translate them into Python services. An AI assistant reads a package and writes one Python service per Flow service, with the MAP steps expressed as Python code and the document types 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 Integration Server. The same message is processed by the Flow service and by the Python service, and the outputs are compared before the Python service receives live traffic.

The migration sequence

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

1. Inventory the packages. For each package, record its Flow services, Java services, document types, adapter connections, REST and SOAP resources, scheduled tasks and Trading Networks processing rules.
2. Define the connections. Every adapter connection and outbound endpoint becomes an outgoing connection in Zato, and every REST and SOAP resource becomes a channel, defined for each environment in YAML.
3. Convert the services with AI. An AI assistant translates the Flow services, Java services and document types into Python services and data models, and your developers review each service.
4. Move the trading partner exchanges. EDIFACT documents from Trading Networks are parsed, routed and serialized by Python services in Zato.
5. Test with production messages. Messages from the production Integration Server are sent to the new services, and their outputs are compared with the outputs of webMethods.
6. Switch the endpoints. Each calling system, trading partner, file location and queue is pointed to the Zato channel in turn.
7. Retire the Integration Servers. When the last package carries no more traffic, the Integration Servers and their 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. It connects to the SQL databases, SAP, Salesforce, REST, SOAP, file transfer and message queue systems that webMethods integrations connect today.

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

webMethods and Zato compared

Frequently asked questions

When does support for webMethods 10.15 end?

Standard support for webMethods 10.15 ends on October 31, 2027. Initial extended support ends on October 31, 2028, and ongoing extended support, for usage questions and known defects only, on October 31, 2030.

What changes in licensing with webMethods 11.1?

From webMethods 11.1 there are no product license keys. Integration Server, Trading Networks, API Gateway and ActiveTransfer are metered products, and on an upgrade to 11.1 the transaction duration for services, flows and workflows is set to 60 seconds.

Can AI convert Flow services to Python?

Yes. An AI assistant translates Flow services, Java services and document types into Zato services and data models, 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 Integration Server before it takes over the traffic.

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 webMethods run at the same time?

Yes. During a migration both platforms run side by side, and endpoints are moved to Zato one package 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.