Home/Journal/OpenText SMAX Licensing Explained
Other ITSM Platforms · Explainer

OpenText SMAX Licensing Explained

OpenText SMAX is licensed in a way that rewards buyers who read the model and penalises those who do not. The concurrent licensing option is its most distinctive feature, and the most commonly mis-sized. This explainer sets out how SMAX is priced, where the cost concentrates, and the levers worth knowing before a renewal.

OpenText SMAX, the Service Management Automation X platform that grew out of the former Micro Focus and HP service management lineage, is licensed in a way that rewards buyers who understand the model and quietly penalises those who do not. Its defining feature is the choice between named and concurrent user licensing, a distinction that has largely disappeared from the big SaaS ITSM tools but remains central to how SMAX is priced. Get that choice right and the platform can be cost-effective; get it wrong and you pay for capacity you never use. This explainer walks the SMAX licensing model, the places cost concentrates, and what to check before a renewal.

It sits under our guide to mid-market and other ITSM platform pricing, which covers the platforms SMAX is most often weighed against.

Named versus concurrent: the core choice

The single most important thing to understand about SMAX licensing is the named-versus-concurrent distinction, because it determines how the whole contract is sized. A named user licence is assigned to a specific individual and is paid for regardless of how often that person logs in. A concurrent licence is drawn from a shared pool and is consumed only while someone is actively using the system, so a pool of, say, fifty concurrent licences can serve a much larger population provided they are not all working at the same moment. For organisations with shift patterns, regional spread, or a large body of occasional users, concurrent licensing can be dramatically cheaper. For a small team that is all logged in all day, named licensing may be simpler and not much more expensive.

Licence typeHow it is countedBest fit
Named userOne licence per assigned person, paid regardless of useFull-time agents who are always logged in
Concurrent userShared pool, consumed only while activeShift-based, regional or occasional users

How modules and editions stack up

On top of the user model, SMAX functionality is divided across modules and editions. Core service management, IT asset management, and the more advanced automation and discovery capabilities are not all the same line item, and an edition that bundles everything is priced for everything whether or not you deploy it. Buyers frequently carry an edition richer than their actual configuration, or have modules enabled that no process depends on. Because the licence total reflects both the user count and the capability set, reviewing what is genuinely switched on and used is as important as counting users. The principle is the same one we apply across platforms in how to compare mid-market ITSM pricing: pay for the configuration you run, not the one on the order form.

SMAX cost is the product of two decisions: the user model and the capability set. The concurrent option is its biggest lever and its most common mis-size. Get both right before discussing discount, because the model decides the baseline the discount applies to.

Where buyers overpay

Four overspends recur on SMAX contracts. The first is buying named licences for a population that would sit comfortably on a smaller concurrent pool. The second is the opposite error, sizing the concurrent pool against total headcount rather than genuine peak concurrency, which inflates the pool well beyond what the usage data justifies. The third is paying for modules that are enabled but unused, a quiet form of shelfware that the cross-platform view in our shelfware reclamation guide covers in full. The fourth is carrying a premium edition for a deployment that only uses the core. Each of these is invisible on the contract and obvious in the usage logs, which is why a usage-based review before renewal pays for itself.

Free download · The ITSM Renewal Timing Playbook

The gated ITSM Renewal Timing Playbook includes the entitlement-mapping checklist we use to right-size licences like SMAX before a renewal.

What to check before a SMAX renewal

Approaching a SMAX renewal, three checks matter most. First, measure genuine concurrency from the system's own session data over a representative period, not headcount, and test whether the concurrent pool is sized to that reality. Second, list every enabled module and edition feature and tie each to a process that depends on it; anything unattached is a candidate to drop. Third, confirm whether your population profile still suits the licence model you are on, since a team that was once all full-time agents may now include many occasional users who belong on a concurrent pool. Run those three before any price conversation, because they reset the quantity the discount applies to. As with any platform, timing the renewal well, covered in our complete guide to ITSM renewal negotiation, turns a correct baseline into a better deal.

Our contract negotiation service maps SMAX entitlements against real session and usage data, tests the named-versus-concurrent question against evidence, and folds the corrected model into the renewal. We are independent and cover every platform, so the recommendation follows your usage rather than a vendor relationship.

How SMAX licensing compares to SaaS ITSM

It helps to see SMAX in context, because its model is genuinely different from the per-agent SaaS tools that dominate the market. Most modern cloud ITSM platforms have retired concurrent licensing entirely and price by named agent, with capability split across editions rather than discrete modules. That makes them simpler to reason about but removes the concurrency lever that, for the right population, makes SMAX cheaper. The practical implication at renewal is that a like-for-like comparison against a SaaS competitor has to convert SMAX's concurrent pool into an equivalent named-seat count before the prices mean anything, and then add back the hosting and administration that an on-premises or self-managed SMAX deployment carries but a SaaS tool does not. Buyers who skip that normalisation either overstate SMAX's cost by counting the pool as if it were named seats, or understate a SaaS rival's by ignoring the seats SMAX serves concurrently. The model difference is exactly why a structured, like-for-like total is the only honest basis for the decision.

Book a renewal review.

We map SMAX entitlements against real usage and negotiate the licence model that actually fits. Fixed fee or gainshare, no fee unless we save you money.

Book a renewal review →

Frequently asked questions

How is OpenText SMAX licensed?
SMAX (Service Management Automation X) is typically licensed by agent, with a long-standing distinction between named users and concurrent users. A named licence is tied to a specific person; a concurrent licence is shared across a pool and counts how many people use the system at the same time. Functionality is also divided across modules and editions, so the licence total reflects both the user model and which capabilities are switched on.
What is the difference between named and concurrent SMAX licences?
A named user licence is assigned to one individual and is paid for whether or not they log in. A concurrent licence is drawn from a shared pool and is consumed only while a user is active, so a smaller pool can serve a larger population that does not all work at once. For shift-based or occasional users, concurrent licensing can be substantially cheaper; for a team that is all logged in all day, named can be simpler. Mismatching the two is a common source of overspend.
Where do buyers overpay on SMAX?
The recurring places are buying named licences for a population that would be cheaper on a concurrent pool, sizing the concurrent pool against peak headcount rather than genuine concurrency, paying for modules that are enabled but unused, and carrying an edition that is richer than the deployment requires. A usage-based review before renewal usually surfaces all four.

The ITSM Negotiation Brief

Vendor moves, benchmark data, and renewal alerts for ITSM buyers.

ITSM Negotiations

Independent, buyer-side ITSM contract negotiation. Fixed fee or gainshare. Not affiliated with any ITSM vendor.

Services
NegotiationRenewal AdvisoryOptimization
Platforms
ManageEngineTOPdeskSolarWinds
Company
AboutContactJournal
Independent. Not affiliated with ServiceNow, BMC, Atlassian, or any ITSM vendor.Buyer Side · Est. 2019