How to scope COBOL development versus production
Development and production are licensed differently, and a finding that blurs them charges the wrong rate for the wrong thing. Knowing how to scope COBOL development versus production means drawing a clear line between the seats that author code and the deployments that run it, because a finding that counts a developer workstation as a production runtime, or the reverse, overstates on both sides of the line.
Visual COBOL and Enterprise Server are governed by the Additional License Authorizations, having reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023. The authorizations distinguish development, where a named developer authors and compiles COBOL, from production runtime, where the compiled application executes and is measured on capacity. These are different metrics for different activities, and the distinction is the foundation of the cluster article runtime versus development license counting for COBOL. This article is the practical companion: how to draw and hold the line in an audit.
Why the line matters to the finding
The line matters because the two sides are counted in different units and priced differently. Development is counted in seats, one per developer; production is counted in capacity, cores or workload. A finding that misplaces an item across the line does not merely miscount it, it applies the wrong metric entirely. A developer machine counted as a production runtime is charged on capacity it never serves; a runtime deployment counted as a development seat may understate one side while a parallel error overstates the other. Scoping correctly is therefore not housekeeping but the precondition for every other defense, because a line item cannot be rebutted until it is on the right side of the line.
What belongs to development scope
Development scope covers the activity of authoring COBOL, and it includes a defined set of items.
- Developer seats. The named or assigned developers who write and compile COBOL, counted as set out in Visual COBOL development seat counting traps.
- IDE installations in active use. Eclipse and Visual Studio with Visual COBOL where a developer actually works, distinct from dormant installs.
- Build and compile activity. The work of producing executables, which overlaps with COBOL DevHub and build server license questions.
- Development and test environments. Non production deployments used for building and validating, within COBOL non production and test environment scope.
What belongs to production scope
Production scope covers the execution of compiled COBOL applications serving real workloads, and it is measured on capacity. It includes the Enterprise Server runtime deployments that run business transactions, counted on cores or the relevant workload metric as examined in Enterprise Server runtime deployment counting. The defining feature is that production capacity is consumed by running applications, not by people authoring them, so the evidence that bounds it is utilisation and workload data rather than seat assignments.
Development is counted in seats; production is counted in capacity. They are different metrics for different activities. A finding that moves an item across the line applies the wrong metric to it, so scoping each item correctly is the precondition for rebutting any of them.
Drawing and holding the line under the four Rs
The defense scopes the estate as part of the method. Respond inside the seven day notice window and establish a single controlled channel so disclosure is organised by scope from the start. Reconstruct the estate by labelling every item as development or production before any measurement, attaching seats to developers and capacity to running deployments. Rebut any line that crosses the boundary, returning developer machines to seat scope and runtime deployments to capacity scope, and removing items that belong to neither because they are dormant or decommissioned, as in decommissioned COBOL workloads still on the audit. Resolve on terms that record the boundary explicitly, so a future audit inherits the same scope. The disclosure control behind this is set out in what records does OpenText copy in a COBOL audit.
In a recent engagement
In a recent COBOL engagement, a finding had counted a set of developer workstations as production runtimes, applying a capacity metric to machines that only authored code. The defense relabelled the estate, attaching each developer machine to a seat and each running deployment to its capacity, and showed that the misplaced workstations served no production workload. Once the items were scoped correctly, the capacity charge on the developer machines fell away and the seat count stood on its own defensible basis. The reduction was characteristic of the firm's record across more than 200 defended audits, contributing to the 68 percent average reduction and the more than $90M in claims mitigated against vendor positions.
Scope first, then defend
The practical lesson is that scoping comes before every other argument, because the metric follows the scope. Because the noncompliance remedy is priced at then current list, with back maintenance and audit cost recovery stacked on top, an item charged under the wrong scope multiplies a charge that should not exist on that side of the line at all. Drawing the development against production boundary clearly, and resolving on terms that hold it, is what keeps each metric applied to the activity it was written for. To have your COBOL estate scoped correctly before a finding is built against it, open a case.
Holding the boundary in the resolution
Scoping correctly during the audit is only half the work; the boundary has to survive into the agreement. A resolution that records which items are development and which are production, and on what metric each is counted, prevents a future audit from reopening the same question and recounting developer machines as runtimes. The forward agreement is where the line is made durable, and a buyer who scopes well but resolves vaguely will likely defend the same boundary again. Writing the development against production distinction explicitly into the resolution is what converts a one time correction into a lasting position, and it is the Resolve phase of the four Rs doing exactly what it is meant to do, which is to carry the win forward into terms the next audit must respect.
Is your finding charging production rates for development work?
We label every item development or production, attach seats to developers and capacity to running deployments, and return any line that crossed the boundary to its correct scope. To get a defense team on the file, open a case or download the guide to reading the Micro Focus ALAs.
Get The Number Down →Related field notes
These notes from the COBOL and Enterprise Server mainframe audit defense cluster cover the development against production boundary and the metrics on each side. Each links back to the complete OpenText audit defense playbook for 2026.
- runtime versus development license counting for COBOL
- Visual COBOL development seat counting traps
- Enterprise Server runtime deployment counting
- COBOL non production and test environment scope
- decommissioned COBOL workloads still on the audit
If an OpenText or Micro Focus audit notice has arrived, the first seven days matter 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.