Decommissioned COBOL workloads still on the audit
Software estates accrete. Hosts are retired, workloads are migrated, applications are sunset, but the inventories that record them are rarely cleaned with the same diligence. Decommissioned COBOL workloads still on the audit are instances that were taken out of service but never taken off the list, and a finding built from a stale inventory charges the buyer for capacity that no longer runs.
Visual COBOL and Enterprise Server are governed by the Additional License Authorizations rather than the OpenText EULA, having reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023. Neither the authorization nor any reasonable reading of consumption charges a buyer for a host that has been switched off. Yet decommissioned instances reach a finding routinely, because the data a discovery scan or self assessment relies on is often a configuration management database or asset register that lags reality by months or years. The defensive task is to reconcile the audit inventory against the live estate and remove what no longer exists.
How decommissioned workloads survive into a finding
The persistence of retired hosts in an audit is a data quality problem before it is a licensing one. A configuration management database that is not updated when a host is decommissioned will keep reporting it. An old discovery export reused for the audit will carry instances that have since been removed. A self assessment populated from a spreadsheet maintained over years will accumulate hosts that were never deleted. None of these sources is lying; each is simply stale. The finding inherits the staleness and counts the dead hosts alongside the live ones. This is the same inventory hygiene problem that drives the runtime overcount in Enterprise Server runtime deployment counting, seen from the angle of lifecycle rather than environment.
An inventory records what was provisioned, not what is running. Decommissioning removes the host but rarely the record. A finding built from the inventory therefore charges for capacity that has been switched off, unless someone reconciles the list against the live estate.
Where the stale instances hide
Decommissioned COBOL workloads tend to cluster in a few predictable places, and knowing where to look speeds the reconciliation.
- Migrated applications. Workloads moved to a new platform where the old host was left registered, sometimes during a cloud move covered in COBOL container and cloud deployment licensing.
- Consolidated servers. Capacity merged onto fewer hosts where the retired originals stayed on the list.
- Retired disaster recovery. Old standby environments replaced but never removed, related to the capacity question in Enterprise Server high availability and core counts.
- Sunset applications. Whole applications taken out of service whose runtime hosts remained registered.
- Refreshed hardware. Old physical hosts replaced in a refresh, with both old and new appearing in an inventory that spans the change.
Removing dead hosts under the four Rs
Clearing decommissioned workloads from a finding follows the four Rs. Respond inside the seven day notice window and ensure the inventory routed through the single controlled channel is the current one, not an old export. Reconstruct the live estate by reconciling the audit inventory against current configuration data, change records, and decommissioning tickets, marking every host as live or retired with a date. Rebut the finding wherever it counts a host whose decommissioning can be evidenced. Resolve on terms measured against the reconciled live estate, not the stale inventory. The decisive element is evidence: a decommissioning ticket, a change record, or a hardware disposal record turns a contested removal into a documented one. Assembling that evidence is part of the reconstruction in reconciling COBOL entitlements before an audit.
In a recent engagement
In a recent COBOL engagement, an Enterprise Server finding was built from a configuration management database that had not been reconciled after a server consolidation the year before. Several runtime hosts named in the finding had been retired when their workloads were merged onto a smaller footprint, but the records were never removed. Producing the change tickets and decommissioning dates for those hosts removed them from the count entirely; they had not run for months. The genuine consolidated runtime remained and was counted on its real capacity. The reduction came from reconciling the audit inventory against the live estate and evidencing every retirement, rather than accepting a list that described the estate as it used to be.
Holding the live estate through resolution
Removing decommissioned hosts once does not keep them out of the next audit unless the resolution is measured against a reconciled baseline. The end state is an agreement built on the current live estate, with the retired hosts documented as removed, so a future audit cannot resurrect them from an old inventory. Because the noncompliance remedy is priced at then current list, with back maintenance and audit cost recovery stacked on top, every dead host left in the count carries a multiplied charge for capacity that produces no value and runs no workload. Reconciling the inventory is therefore one of the cleanest reductions available in a COBOL defense, because a switched off host is hard for any vendor to defend once its retirement is evidenced. To have a COBOL estate reconciled against the live deployment and stale hosts removed, open a case.
Why inventory hygiene is a defensive asset
The reason this matters beyond a single audit is that good inventory hygiene is itself a defensive asset. An estate whose configuration data is reconciled to reality routinely is far cheaper to defend, because the audit starts from a number close to the truth rather than a number inflated by years of accretion. A buyer who maintains accurate decommissioning records turns each retirement into evidence that is ready before the notice arrives. The discipline connects directly to the preparation work in preparing a COBOL entitlement reconstruction, and the broader method sits inside the complete OpenText audit defense playbook for 2026.
Is your COBOL finding built from an inventory that was never cleaned?
We reconcile the audit inventory against the live estate, evidence every decommissioning, and remove hosts that no longer run. 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 inventory, lifecycle, and capacity. Each links back to the complete OpenText audit defense playbook for 2026.
- Enterprise Server runtime deployment counting
- COBOL non production and test environment scope
- how to challenge a COBOL core measurement
- reconciling COBOL entitlements before an audit
- preparing a COBOL entitlement reconstruction
If an OpenText or Micro Focus audit notice has arrived, the opening 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.