OpenVMS: Navigating the Crossroads
Blog //09-02-2021

OpenVMS: Navigating the Crossroads

by Brandon Edenfield, Managing Director of Application Modernization

The resources needed to maintain OpenVMS applications are diminishing, and several big tech partners are already parting ways with the system. This blog navigates the potential avenues one might take towards modernizing OpenVMS systems.

As of 2021, OpenVMS continues to drive numerous mission-critical business and operational systems across the planet. Originally created by DEC back in 1977 as VMS (Virtual Memory System), the reliable, high availability operating system has proven its worth to a diverse array of organizations for many years. But the resources needed to maintain these applications are disappearing.

Developers are reaching retirement age and leaving the industry, meaning that essential maintenance is becoming increasingly time-consuming and expensive. On top of this, several big tech partners have started discontinuing support for OpenVMS.

The end of the road

OpenVMS started life on DEC VAX servers, then moved to DEC/HP Alpha servers, but neither of these platforms are supported any more. HP then ported OpenVMS to the Integrity server to replace the Alpha and powered its last OpenVMS platform with Intel’s Itanium chip. However, Intel announced in 2019 that it was discontinuing its Itanium 9700-series processers (the last in the Itanium series), with final shipments of these taking place later this year.

On top of this, there have been more end-of-support announcements made in the recent months. HPE ended standard support for OpenVMS V8.4 in December 2020, along with last orders for the Itanium i6 servers. HPE are also ending support for the final generation of its Itanium CPUs in 2025, with support for the i2 server having ended just over a week ago. If this wasn’t enough, Oracle has also joined the list, announcing that it is discontinuing the 11g database, including client components, affecting customers who use the Oracle database or Oracle database client software on OpenVMS.

With so much uncertainty and lack of support from big tech partners, it’s important to consider the future of your business-critical applications. Is it time to take a new direction and assess options for migrating OpenVMS applications?

There are several pathways to consider with OpenVMS Migration – you can find these detailed in our whitepaper; ‘Considerations for an OpenVMS Application Migration and Modernization Strategy’. This blog explores the two solutions that are most likely to be employed in a modernization project, as well as outlining the steps we take to mitigate risk in OpenVMS migration projects.

Same driver, new car

Rehosting (sometimes referred to as ‘lift and shift’ or ‘replatforming’) describes a migration where minimal changes are made to the underlying technology of the application and database. The biggest benefit of rehosting is that it limits changes to the application itself and ensures the preservation of functionality, business logic and business processes after the migration. Because of this, the testing required to verify the migration is minimized, and the cost / time for end-user retraining is eliminated.

Rehosting is not moving to an emulated hardware solution. This approach typically uses a software / hardware emulation of VAX or Alpha sitting on top of either bare metal or Windows / Linux, whereas rehosting allows the migrated application to run natively on the target platform. This removes the performance overhead often associated with an emulator and allows the migrated application to take full advantage of modern features available in the new operating environment.

The feasibility of rehosting depends not only upon having access to a native language compiler in the new environment, but also a framework that underpins the proprietary aspects of the OpenVMS world.  Fortunately, these Compatibility Frameworks are readily available in the market. They introduce a software license component in the new environment, but the reduction in overall migration cost more than pays for the licensing fees – ultimately making it more cost-sustainable.

Taking the hybrid road

It’s important to note that rehosting isn’t always the best solution. In some instances, the OpenVMS technologies simply cannot be supported in the target environment. But this doesn’t always mean that you would have to re-engineer your entire system to experience the benefits of modernization.

Many organizations adopt a hybrid approach: rehosting the components that could be easily supported in the modernized environment, and using automation to re-architect aspects for which a rehosting solution is not the best option, or where functional / technology modernization delivers added benefits to the business. For example, you may take your migration as an opportunity to modernize your database - RMS files and RDB tables can be migrated directly to Oracle or Microsoft SQL Server.

Mitigating risk

While it’s important to modernize ageing applications at the earliest opportunity possible, the process still demands both care and patience. We believe that there are three crucial factors that are essential to a successful migration project:

  • Discovery is a critical phase in any successful migration in that it determines the composition, size and complexity of the current OpenVMS environment. Making a detailed inventory of application components creates a template upon which migration solutions can be applied to each piece. Once this is in place, work can begin on analyzing the source code.
  • With a complete picture of the application set that will be migrated, the next step is planning the migration process. The key in this phase is to ensure that the migration addresses every aspect of the application. Planning the migration completely is the single most important aspect for risk mitigation.
  • Testing is also critical since most migrations require at least some modification to code and data structures. Pyramid testing is generally considered the best approach, as it employs various methods to test out both critical and non-critical functions, using automation to prioritize groups into different levels based on program criticality.

If you’re interested in learning more, our whitepaper further details the available options for migrating and modernizing applications currently running on OpenVMS, and highlights the benefits that your organization can achieve through modernization.

Further resources

Blog Application Modernization Application Modernization and Migration Application Modernization Strategy Application Re-architected and Reintegration Application Understanding OpenVMS
Brandon Edenfield

Brandon Edenfield

PUBLISHED BY

Managing Director of Application Modernization

Brandon Edenfield is the Managing Director of Application Modernization, and has over 28 years’ experience in application migration and modernization.

Read published articles