Technology

Why we run LoadRunner

A short brief on when and why our team standardizes on OpenText LoadRunner (formerly HP/Micro Focus LoadRunner), the situations where it becomes a requirement rather than a preference, and how the licensing is actually priced.

Why we use LoadRunner

Open-source tools cover most of our day-to-day API and web load testing well, and we keep using them where they fit. LoadRunner earns its seat on the bench for the harder 20% of engagements: legacy protocols, enterprise SLAs, and clients who need a name their auditors already recognize.

Broadest protocol coverage

Native support for Citrix, SAP GUI, Oracle Forms, RDP, mainframe terminal emulation, and dozens of legacy and enterprise protocols that open-source tools don't script reliably, if at all.

Client- or contract-driven

A number of our engagements are with clients whose internal standards, audit requirements, or existing LoadRunner Enterprise installation dictate the tool before we're even in the room.

Enterprise-grade support

Vendor SLAs, correlation and analysis tooling, and the ability to scale to very large virtual-user counts across distributed load generators without us maintaining the scripting layer ourselves.

Where LoadRunner is mandatory

On most projects, tool choice is ours to make. These are the three situations on the performance team where LoadRunner stops being a choice and becomes the only realistic option.

No viable open-source option

Some target systems simply aren't testable with open-source tooling at an acceptable level of risk:

The application uses a proprietary or binary protocol that JMeter, Gatling, or k6 have no sampler or plugin for, and building one in-house isn't justified for a single engagement.
The client requires a vendor-backed tool with a support contract and SLA, which rules out community-maintained open-source stacks regardless of technical fit.
Correlation, think-time modeling, or protocol-level replay needs a level of maturity that the open-source equivalent hasn't reached yet for that specific technology.

Citrix / thin-client protocol

Citrix (and similar ICA/RDP-style thin-client delivery) is the clearest recurring case. The client only ever sends screen updates and receives mouse and keyboard input, so there's no conventional request/response traffic to script against. LoadRunner's Citrix protocol handles this through screen-region synchronization and OCR-based verification, built and maintained specifically for this use case.

Open-source alternatives exist only as third-party plugins (for example, a community Citrix plugin for JMeter). They can work for narrow scenarios, but synchronization is fragile, image-based correlation is manual and pixel-sensitive, and there's no vendor support to fall back on when a client's Citrix environment changes. For anything beyond a small proof of concept, we standardize on LoadRunner here.

Other mandatory scenarios

SAP GUI / Oracle Forms / mainframe terminal (3270/5250): similar to Citrix, these are thick or terminal-based protocols where open-source tools have little to no native support.
Regulatory or compliance-driven testing: some industries (banking, insurance, healthcare) require test evidence and audit trails from a recognized commercial tool as part of a compliance sign-off.
Existing enterprise investment: when a client already runs LoadRunner Enterprise / LoadRunner Cloud in-house, we test on their platform so results, scripts, and dashboards stay inside their existing environment.
Very large-scale, distributed load: engagements needing tens of thousands of virtual users across many geographically distributed load generators, with centralized monitoring and reporting out of the box.
Shared test lab under ALM governance: when a single, expensive test cluster is shared across many performance teams and environment time is booked on a fixed schedule, the tool needs to plug into that governance layer natively — this is rarely something an open-source stack was built to do.

Field note

On one enterprise engagement, the entire performance program ran through ALM as the system of record for a single shared test cluster used by 107 performance teams. Environment slots weren't booked ad hoc — they sat on a permanent rolling schedule, reserved roughly two weeks in advance, because the underlying environments (SAP, Citrix farms, integration systems) were shared, costly to stand up, and couldn't be spun up on demand per team.

In a setup like that, the hard constraint isn't scripting capability — it's governance: one shared calendar of who owns which environment, for how long, running which build, with results traceable back to a test plan. Open-source tools have no native answer to that. You could bolt a booking system onto JMeter yourself, but at 100+ teams sharing one lab, you need a purpose-built scheduling and resource-governance layer — which is effectively what ALM plus LoadRunner Enterprise already provides. This is as much a reason for mandatory use as any single protocol.

Performance teams: 107
Shared test cluster: 1
Booking lead time: ~2 wks

Advantages

Independent of the mandatory cases above, these are the reasons LoadRunner stays useful even when an open-source tool could technically do the job.

Protocols: The widest protocol library on the market — web, Citrix, SAP, Oracle, RDP, mainframe, messaging, databases, and more — under one licensing umbrella instead of stitching together several tools.
Analysis: Built-in root-cause and correlation analysis, transaction breakdowns, and reporting that would otherwise need a separate APM or dashboard stack with open-source tools.
Scale: Proven at very high virtual-user counts with distributed load generators, load balancing across regions, and centralized test management (LoadRunner Enterprise / Cloud).
Support: A vendor SLA and dedicated support line — valuable on client-facing engagements where "the community forum didn't answer in time" isn't an acceptable excuse.
Recognition: A name enterprise clients, auditors, and procurement teams already know and accept, which shortens tooling approval conversations at the start of an engagement.
CI/CD fit: Integrates with existing pipelines and third-party tools (including JMeter and Gatling scripts, in LoadRunner Cloud), so it can sit alongside our open-source stack rather than replace it entirely.

Price model & how cost is calculated

LoadRunner is licensed, not free — this is the main trade-off against open-source tools, and it's worth understanding before assuming it for a project.

Professional

Perpetual / node-locked

Desktop-oriented, per-seat or per-protocol-bundle licensing. Best fit for a single team running tests from a fixed workstation.

Enterprise

Virtual-user & server license

Centralized test lab with distributed load generators, licensed by concurrent virtual users and the protocol bundles enabled.

Cloud

Subscription / pay-as-you-go

Hourly or subscription-based SaaS pricing with elastic load generators — no infrastructure to license or maintain ourselves.

Virtual users

The core cost driver. Licenses are sold in virtual-user (VUser) packs — the more concurrent simulated users a test needs, the more the license costs.

Protocols

Standard web/HTTP protocols cost less than specialized bundles like Citrix, SAP, or Oracle Forms, which are priced as premium protocol add-ons.

Deployment

On-premises (perpetual + maintenance), Enterprise subscription, or Cloud (hourly/consumption-based) — each shifts cost between a one-time license, annual renewal, or usage-based billing.

Support tier

Standard vs premium support and SLA response times are priced separately from the base license.

Scale

Additional load generators, geographic distribution, and integrations (CI/CD, APM, ALM) can add to the total quote for larger engagements.

Alternatives we also use

LoadRunner isn't our default — it's the exception. For everything that doesn't fall into the mandatory cases above, we reach for open-source or lighter commercial tools first.

Apache JMeter

Open source

Where it fits: HTTP/S, REST, SOAP, JDBC, messaging — our default for API and web load testing.

Where it falls short: No native Citrix/SAP/Oracle Forms support; enterprise reporting needs extra plugins.

Gatling / k6

Open source

Where it fits: Code-first, CI/CD-friendly load testing for modern APIs and microservices.

Where it falls short: Same protocol gap as JMeter for legacy/thin-client systems.

Tricentis NeoLoad

Commercial

Where it fits: Supports Citrix, SAP, and Oracle Forms with a shift-left, developer-friendly workflow.

Where it falls short: Still a paid license; smaller enterprise footprint than LoadRunner in some clients.

LoadNinja / BlazeMeter

Commercial / cloud

Where it fits: Fast browser-based load testing with less setup overhead.

Where it falls short: Limited protocol depth outside standard web traffic.

Watercooler Truth

The kind of thing that doesn't make it into official documentation but comes up in every honest performance-team conversation.

Why does everyone say "we can't use JMeter because of the license"?

You hear it constantly in interviews and client kick-offs: "We have to use LoadRunner — it's a licensing thing." But JMeter is Apache-licensed, which explicitly allows commercial use. So what's actually going on?

When someone says "because of license," they're rarely making a precise legal statement about open-source terms. It's shorthand. What they usually mean is one of these:

“Our company policy requires commercially supported software.” — The IT or risk function mandates a vendor SLA for anything that touches production-adjacent environments. JMeter has no vendor to call.
“Our procurement standards favor licensed enterprise products.” — Procurement has a pre-approved vendor list. Getting a new open-source tool on that list takes a procurement cycle no one wants to open.
“Our governance process for open-source tools is more complex.” — Some organizations have a formal OSS review board. Using an open-source tool means submitting it for review, getting legal sign-off, and maintaining a software inventory entry. Easier to just use the thing already approved.
“We already own enterprise licenses, so that's our standard.” — The company bought LoadRunner seats three years ago. Those seats are paid for. The path of least resistance is to use what's already licensed and already in the tech-stack inventory.

In other words: they're referring to the commercial licensing model and support agreement of the testing tool — not claiming the Apache License prevents using JMeter in commercial environments. JMeter is free to use commercially. What it doesn't come with is a vendor contract, a support SLA, or a procurement checkbox — and in large enterprises, those things matter as much as the tool itself.

Not sure which tool your project needs?

Send us the protocols involved and the client's requirements, and we'll tell you whether this is an open-source job, a LoadRunner job, or something in between.

Request a consultation Review mandatory cases