Rocket Visual COBOL: two licenses, seats and deployment.

Rocket Visual COBOL is a COBOL application development and modernization toolset, formerly a Micro Focus product and now owned by Rocket Software, which acquired the OpenText Application Modernization and Connectivity business in 2024. It provides COBOL development inside Visual Studio, Visual Studio Code, and Eclipse, with patented compiler technology that targets native platforms such as Windows, UNIX, and Linux as well as managed code environments including .NET and the Java Virtual Machine. For mainframe owners it matters because it is a core tool in the rehosting and modernization conversation, the route by which COBOL applications move off z/OS to distributed or cloud targets, which is why its licensing belongs in any mainframe estate review.

Visual COBOL is licensed in two parts that must be counted independently. Development is licensed on authorized users, a per developer seat that covers the IDE integrations and the compiler. Deployment is licensed separately, commonly on a per vCPU or core basis for the COBOL runtime in system test, pre-production, and production. The development license includes only a limited runtime for unit testing on the same machine used to develop, expressly not for system test, production, or deployment. So a compliant estate needs development seats for the people who build and a deployment entitlement for every environment the compiled application runs in, and the two are priced and measured on different metrics.

Directional and pattern level. License authorizations and deployment terms evolve under Rocket, so confirm the current model in your own schedules before modeling a renewal.

The dominant cost driver is deployment scale, the vCPU or core count of the production and pre-production runtime, which tends to grow quietly through virtualization, cloud elasticity, and disaster recovery copies. The second is the developer seat count, which often outlives the project that justified it as contractors roll off and seats are not reclaimed. The third is the mix of native and managed code targets, since .NET and JVM deployments can be scoped differently from native and can pull the entitlement in directions a buyer did not plan. A modernization program also creates a spike in seats and runtime during the build that should not be allowed to set the steady state recurring bill.

Visual COBOL exposure sits on the deployment side far more than the development side. Common traps we see at pattern level:

The renewal bends most where deployment cores and stale seats can be pared back. The five levers that pay:

The COBOL modernization tooling market is genuinely contested: Rocket Visual COBOL competes with IBM's COBOL tooling, GnuCOBOL and other open implementations for some workloads, and the broader question of whether to rehost off the mainframe at all. That makes a credible alternative a real lever during a build decision, when the toolchain is not yet sunk. Once an application has been recompiled and is in production on Visual COBOL runtime, the switching cost rises sharply, so the realistic move on an installed estate is deployment right sizing and seat hygiene rather than retooling. Evaluate the alternative seriously at the project gate; hold scope discipline at renewal.