Adabas Replication: an MSU add-on, not a data volume meter.

Event Replicator for Adabas is Software AG's real time change data capture and replication engine for the Adabas database on z/OS. It pushes selected Adabas data, as changes occur, to other Adabas databases, to relational targets such as Db2, Oracle, SQL Server, MySQL, Teradata, and PostgreSQL, and to messaging systems, so that downstream analytics, reporting, and integration platforms see current data without batch extracts. It is a priced add-on to the Adabas license rather than a standalone product, and it lives inside the Adabas and Natural estate that Software AG now runs as a focused legacy and modernization business, the estates we are most often asked to baseline for audit exposure.

Software AG mainframe products are licensed on capacity, and the license record captures the environment it runs in: operating system, CPU ID, LPAR ID, system name, and capacity measured in MSU. Event Replicator is a priced add-on to Adabas, so its entitlement is tied to the rated MSU capacity of the machine or LPAR where Adabas and the replicator operate, the same capacity envelope that drives the base Adabas license. It is not metered on the number of records replicated or messages produced. That makes the entitlement a function of where Adabas runs and how big that environment is rated, which is why capacity changes and environment moves are the events that put it at risk.

Directional and pattern level. Software AG capacity terms and license record fields evolve, so confirm the current model in your own Adabas schedules before modeling a renewal.

The first cost driver is the rated MSU capacity of the LPARs where Adabas runs, since the add-on is pinned to that envelope and a hardware upgrade can lift it without any change in workload. The second is replication scope: whether the entitlement covers only the systems that genuinely need real time targets or has spread across the estate by default. The third is the bundle context, because Event Replicator is rarely negotiated alone and the wider Adabas and Natural agreement, with its base license, maintenance, and any modernization tooling, usually sets the frame the replicator line sits inside. Long lived contracts that have never been reconciled to current capacity are where the padding accumulates.

Adabas Replication exposure sits in the gap between licensed capacity, licensed scope, and the running environment. Common traps we see at pattern level:

Replication is sticky, but the licensing around it bends like any capacity deal. The five levers that pay:

For data already in Adabas, the native Event Replicator is the path of least resistance, and third party change data capture tools can read Adabas but rarely match the integration of the vendor's own engine, so a like for like swap of just the replication layer is seldom worth the disruption. The more meaningful alternative is strategic: a modernization or migration program that moves data off Adabas entirely removes the need for the add-on along with the base license. That is a multi year decision, not a renewal tactic, but a genuinely funded and sequenced exit plan changes the tone of every Adabas negotiation, because the vendor knows the estate is hard to replace quickly and values keeping it.