Visual COBOL versus Enterprise Server licensing

Two products, two purposes, two different metrics, and one recurring audit error that costs buyers more than any other in the COBOL estate. Visual COBOL versus Enterprise Server licensing comes down to keeping the development metric and the runtime metric apart, because a finding that conflates them prices developers as runtime capacity or runtime as developer seats.

Both products reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023, and both are governed by the Additional License Authorizations rather than the OpenText EULA. They sit at different points in the application lifecycle. Visual COBOL is the development environment, where people write, edit, and compile COBOL code. Enterprise Server is the runtime, where compiled COBOL applications and transaction processing execute in production. The licenses follow those purposes: development tooling tends to be licensed by the developer, runtime tends to be licensed by capacity. When a finding loses track of which product is doing what, it applies the wrong metric, and the wrong metric is almost always the more expensive one.

How the two metrics differ

The clearest way to hold a COBOL finding together is to keep the two metrics distinct in principle before testing them in detail. Visual COBOL, as a development product, is naturally counted by the number of developers entitled to use it, which makes it sensitive to the seat counting traps that affect any per person metric, examined in Visual COBOL development seat counting traps. Enterprise Server, as a runtime, is naturally counted by capacity, usually cores, which makes it sensitive to the core counting questions set out in what is an Enterprise Server core license metric. The two metrics measure entirely different things: one a population of people, the other a quantity of processing capacity. A finding that respects this distinction counts each product on its own basis. A finding that does not respect it produces a number that belongs to neither product.

Where a finding conflates them

The conflation between the two products takes a few predictable forms, each of which moves the count onto the wrong basis.

• Development installs counted as runtime. Visual COBOL installed on a developer workstation counted as if it were a production runtime deployment.
• Runtime hosts counted as developer seats. Enterprise Server capacity attributed to named developers who never touched it.
• Build infrastructure miscategorised. Continuous integration and build servers counted under the wrong product entirely, a question taken up in COBOL DevHub and build server license questions.
• Test runtime priced as production. Enterprise Server in non production environments counted at production capacity rather than under its own terms.
• Named developer and runtime blurred. The distinction examined in Visual COBOL named developer versus runtime metrics lost, so the same activity is counted twice under two metrics.

Keeping the two products apart

Separating Visual COBOL from Enterprise Server in a finding is a reconstruction exercise that the four Rs carry through. Respond inside the seven day notice window and hold a single controlled channel, so each product is described on its own terms rather than merged in a single export. Reconstruct the effective position by reading the authorization for the metric that governs each product, then assigning every install, host, and account to development or runtime and counting it under the correct metric. Rebut the finding wherever it has counted a development install as runtime, a runtime host as a developer seat, or the same activity twice. Resolve on terms that record which product carries which metric, so a future audit cannot re merge them. The principle is simple and the discipline is everything: development is counted by developers, runtime is counted by capacity, and no activity belongs in both counts at once. The underlying distinction between runtime and development counting is set out in runtime versus development license counting for COBOL.

In a recent engagement

In a recent COBOL engagement, a finding counted developer workstations running Visual COBOL as if each were an Enterprise Server runtime deployment, then also counted the genuine runtime hosts on a capacity basis. The same applications were effectively counted twice, once as development and once as runtime, under two different metrics. Separating the estate into its development and runtime components, and counting each under the metric the authorization actually assigned, removed the duplicate development as runtime count entirely and left only the genuine runtime capacity and the real developer seats. The reduction came from refusing to let one product be priced under the other product's metric.

One product, one metric, one count

Visual COBOL versus Enterprise Server licensing is, at its core, a discipline of keeping two metrics from contaminating each other. The products do different jobs, the authorization counts them on different bases, and the most expensive errors in a COBOL finding come from blurring that line: development priced as capacity, runtime priced as seats, or the same work counted under both. The defensive task is to assign every component to development or runtime, count it under the metric the authorization sets for that product, and require the vendor to justify any item that appears in both counts. A buyer that keeps the two products apart pays for each once, on its own basis, and not for an imaginary product that exists only in the arithmetic of a conflated finding. To have a COBOL estate separated cleanly into its development and runtime components, open a case.

Why the conflation is so costly

The reason this particular error matters more than most is that it compounds in two directions at once. When development is priced as runtime capacity, a handful of workstations can be made to look like a large production estate, and the capacity rate is the higher of the two. When the same applications are then also counted on the genuine runtime hosts, the buyer is charged twice for one set of software. The noncompliance remedy is priced at then current list, with back maintenance and audit cost recovery stacked on top, so a doubled and misclassified count produces a remedy that bears no relationship to the deployment. Keeping the two products on their own metrics is therefore not a refinement at the margin but the single largest protection against an inflated COBOL finding.

Related field notes

These notes from the COBOL and Enterprise Server mainframe audit defense cluster cover development, runtime, and metric separation. Each links back to the complete OpenText audit defense playbook for 2026.

• Visual COBOL development seat counting traps
• what is an Enterprise Server core license metric
• runtime versus development license counting for COBOL
• Visual COBOL named developer versus runtime metrics
• COBOL DevHub and build server license questions

If an OpenText or Micro Focus audit notice has arrived, the opening seven days weigh more than any week that follows them. OpenText Audit Defense is an independent, buyer side practice founded in 2020 by former vendor compliance leadership. We have defended more than 200 audits, reduced the average finding by 68 percent, and mitigated more than $90M in claims against vendor positions. We do not resell OpenText software and we are not affiliated with OpenText Corporation. To open a case, use the contact form on this site.