Tamino licensing: a sunset XML database still drawing maintenance.

Tamino, the Tamino XML Server, is a Software AG native XML database released in the late 1990s and one of the first commercially available databases built to store and query XML directly rather than as a layer bolted onto a relational engine. It held documents in their native XML form and queried them with XML query languages, and was positioned for content management, document centric applications, and the integration use cases that were emerging as XML became a lingua franca for data exchange. Tamino has effectively reached end of life: active development wound down more than a decade ago and it is no longer positioned for new deployments. Where it still runs today it is typically a legacy estate, an application that depends on it and has not yet been migrated, which makes Tamino a maintenance and exit conversation rather than a growth one.

Tamino was historically licensed on processor capacity, commonly per CPU, with optional add on components such as data gateways licensed separately, plus annual maintenance on the licensed entitlement. As a legacy product the live commercial question is rarely a new license; it is the sustaining maintenance and support stream on an entitlement that may have been in place for many years. That shifts the variables that matter away from a forward consumption metric and onto the entitlement baseline, the maintenance percentage applied to it, and what support tier is genuinely still available, because there is no meaningful future expansion on a product that is not being developed. What you are really negotiating is the cost of keeping a frozen product supported, not the cost of growing into it.

Directional and pattern level. Confirm the current entitlement baseline, the maintenance percentage, and what support tier remains available before deciding whether to renew or retire.

The first driver is the maintenance stream, which on a legacy product is the entire live cost and which compounds year over year if it is never challenged. The second is the bundle, because Tamino is often folded inside a wider Software AG agreement where its individual cost is invisible and therefore never tested against actual usage. The third is the support tier, since a product with no roadmap rarely justifies a premium support rate, yet the entitlement may still be billed as though full development support applied. The fourth is inertia itself, the most expensive driver of all on sunset software, where the maintenance simply renews each year because no one has built the case to retire it or the migration to replace it. None of these is a usage metric; all of them are governance failures that quietly keep a frozen product on the books.

Tamino exposure is mostly paying for a sunset product as though it were strategic. Common traps we see at pattern level:

Because Tamino is a legacy product with no roadmap, the levers are about usage truth, the maintenance line, and a credible exit. The five that pay:

For a native XML store the modern alternatives are abundant: mainstream relational databases now handle XML and JSON natively, document databases cover the document centric use cases Tamino once owned, and many former Tamino workloads are better served by a general purpose engine the estate already runs. That makes replacement genuinely credible, more so than for sticky transactional databases, because the data model is portable and the volumes are often modest. The friction is in the application: queries written against XML query languages, integrations built around Tamino specific behavior, and the testing burden of proving the migrated application behaves identically. The practical approach on a sunset product is to establish usage truth and challenge the maintenance first, which often recovers real money immediately, then scope a costed exit so that retirement, not perpetual maintenance, is the default path. Where an application is being modernized anyway, Tamino should leave with it.