Staying on OpenVMS or Migrating to Linux: A Strategic Cost Comparison
At VMS Software, it is our mission to protect the value that our customers have built into their applications on OpenVMS over decades. These applications are bespoke masterpieces written to cater just to a specific company and use case, they are ingrained in their culture and operations, and still functioning from thirty years ago, still running - let's face it - a large portion of the modern world. With OpenVMS now running on x86 and in the cloud, it is entirely possible for most of our customers to keep their valuable applications on this legendary platform.
While much of the migration conversation focuses on platforms, the real challenge lies in the applications themselves. Migrating off OpenVMS typically means a full rewrite: replacing stable, tailored systems with entirely new software stacks. This introduces significant cost, risk, and change management overhead that is often underestimated. It is sometimes possible to pursue a hybrid approach and wrap the system in APIs and run on Linux, or isolate the VMS application and use microservices, but that leaves some of the problems unsolved and introduces additional complexity and reduces serviceability of such solutions. In any case, it’s not just a technical port but a business transformation involving application re-architecture, process redesign, change management, retraining users, and more. The real question is, do the benefits of such migration outweigh the costs?
In a previous article, I've covered the relative risks of staying on VMS vs going to a commodity OS. In this one, I will focus on the cost side of that decision: comparing the long-term financial and operational impact of migrating to x86 while staying on OpenVMS versus rewriting and moving to Linux.
Sample Environment
As a sample environment, we've chosen a relatively small system running a critical application handling a lot of personal information (let’s say citizen records) and payments. The application has approximately 1 million lines of COBOL code and relies on an Oracle RDB database. The production cluster consists of 3 nodes, currently on HP rx2800. The development machine is a single-node rx2600 i2, and the test cluster consists of two rx2660s. The system also uses a SAN for storage. The whole setup is currently installed in a private server room that can be expanded at some additional cost. In terms of software, all systems are running VSI OpenVMS V8.4-2L3, Oracle Rdb, COBOL, DECforms, and Apache web server, as well as a few other (mainly open source) tools.
The production system has high uptime requirements: less than an hour of downtime per year. Update frequency would be moderate: open source tools such as Apache, OpenSSL and OpenSSH would be updated when available and all important patches would have to be installed, which would amount to about 6 updates per year, not requiring the app to be recompiled. These updates, hardware maintenance, backups, user requests, and performance monitoring and tuning are keeping the current system manager fairly busy, and because they are supporting that system alone, the customer is getting managed services coverage for nights and weekends from VSI to ensure the system is running 24/7. Apart from the system manager, there is also the COBOL developer/database engineer taking care of the application, fixing eventual bugs and providing occasional updates and new features. There is silver support from VSI (24/7, with a right to minor releases included).
We estimate the current running costs on Integrity to be approximately $521,000k a year (including the team of two, software costs, managed services and the server room infrastructure), but this cannot go much longer as Integrity is approaching end of life.
We will explore 2 scenarios: in the first one, the team will move their system to x86 servers and stay on VMS for another 10 years, and in the second one, the team will port their application to Linux as soon as possible and spend the rest of those 10 years on Linux. For simplicity, we will assume that in both cases the company will use 6 DL380 servers or 6 VSI Cloud (or OCI in case of Linux) instances, so hardware costs and server room infrastructure costs will be the same.
Scenario 1: staying on VMS
The company expands the server room and puts some DL380 servers and a new storage solution, slightly increasing the server room infrastructure costs. They get an evaluation license, the admin installs OpenVMS V9.2-3 on one of the servers, and the COBOL developer tries to recompile their application on x86. That works, but there are some issues, so they get migration services from VSI. In about 6 months, they are ready to start testing, which consumes a lot of both the developer and the admin's time (so they need to get more help on their environment from VSI) and involves a lot of testing by the users themselves, which is a major undertaking, but in about 6 months after that, they are done and ready to run in production on x86. While there will be updates to both OpenVMS and the layered products they have installed, the rate of updates on VMS will be approximately the same as before.
There are some more costs in the first year: in addition to the money they usually spend, the company would purchase migration services for $300k, managed services for $100k (to replace the admin who would be helping with the x86 environment), spend $60k on the hardware and $2k on some additional server room infrastructure. VSI does not charge for x86 licenses while you are migrating to x86, so that would not be part of the costs. The costs for the first year would be closer to $990k.
In the next 9 years, the same setup will be maintained, costing around $523,000k without the hardware. If we assume a constant inflation rate of 3% and the first year costs described above, the total cost of ownership for 10 years will thus be $6,457,810, not considering hardware maintenance and upgrades.
An option would be to run in the cloud instead of buying the hardware. 6 instances in OCI would cost about $29,000 a year (assuming similar characteristics to the DL380 setup and 100% performance guarantee), so the first year cost will be 941k and the running costs would be $541,000, amounting to about $6,608,000 over 10 years with adjustment for inflation. While not reflected anywhere in our cost estimate, the cloud would actually mean that you never have to deal with hardware risks, never need new hardware, never need to hire anyone who knows hardware, you'd be able to move your servers to anywhere in the world with minimal downtime, and more.
Another option would be to opt out of staff and get managed and application services from VSI whenever the system admin and the COBOL developer decide to retire. If we assume that the administrator is replaced by 24/7 managed services and you get 600 hours of application services a year to cater to your COBOL development needs, your costs actually go down a little bit, amounting to about $448,792 a year and
$5,679,297 over 10 years (adjusted for inflation). 600 hours of application services is much less than what you get from your one full-time developer you say? That is entirely true. In our experience, a good developer with adequate workload does not code the entire time: they have time to look at the code from time to time, refactor it, catch up on industry news, look at the real-time performance data, ponder improvements, etc. If you get application services, the team will follow their statement of work, resulting in fewer hours and a lower price.
Scenario 2: Migrating to Linux
After purchasing the new servers, the company contacts one of the contractors on the market for a Linux migration. They pay $3M up front, and for 3 years (at least), they are still running their VMS setup with their existing team while the contractor is porting their application to Linux on the new servers using Oracle Classic. In the third year, when the new application is close to being released, a new team is hired: two system administrators to provide 24/7 support for the system, a front-end developer, a back-end developer, and a tester. For approximately a year, the new team is working alongside the old team (costing about $1.3M a year), and at the end of the third year, production switches over to the Linux system, and the old team leaves. This sounds really easy on paper, but in reality, it is a process that is complex and full of setbacks: the gaps in documentation, the risk of losing institutional knowledge, the difficulty of replicating exact business logic, the potential for functional drift during a rewrite, to name a few. Change management is a problem in itself: users will need to be retrained, business processes redefined, testing will have to be done by non-technical staff, and there will be resistance to change. Keep in mind that there will always be a period when the new system is run alongside the old system, ready for failover – but the length of that period varies. For some of our customers, it has been as long as 10 years – but in absence of special compliance needs, there will still be at least a few months after the new system is fully running in production. After that, the costs of the system are mostly comprised of the Oracle software, the team salaries and server room infrastructure or cloud instances, amounting to approximately $678,000 a year if running on own hardware and $697,000 if running on cloud.
The total cost of ownership adjusted for inflation would then amount to about $10,756,122.84 in case of hardware and $10,913,358.89 in case of cloud – provided that the migration is completed in year 3 and there are no instances running OpenVMS left after that.
Why is it $3M and three years for the migration? It’s an optimistic estimate. We have seen examples of +$5M and with much longer timelines. For an application we have just described, one would need to write the new back end inlet's say C# or Java, a new front end in Javascript, switch the database to one available on Linux, connect the two, write the new tests and CI/CD pipelines, which is easily a year of work for an entire team. However, migration efforts of this scale typically take a few years to complete we took an average of 3 for this example (which, depending on your hardware support and uptime requirements, may mean that you will have to migrate to VMS on x86 before you migrate off to Linux). $3M accounts for 10,000 hours of services of a highly qualified team of engineers who are familiar with both OpenVMS and Linux at $300 an hour.
A small note on engineer qualifications: applications written for OpenVMS often leverage its features, such as RMS file handling, DECforms, cluster failover, scheduling. A successful Linux rewrite will not only replicate the functionality but also re-architect the application to leverage Linux strengths. This adds significant design and testing overhead.
You could potentially hire the new team right away and make them work together with the old team on the migration, but then you would also need to get managed services to keep your application running. Assuming the old team is the system admin and the COBOL developer and the new team is one system admin, one front-end developer, one back-end developer, and one QA engineer, the total cost of that team per year would be $948,000. The migration would be riskier and the team would probably work on it longer, but the resulting costs over 10 years would be somewhere between the $10M as previously estimated and $8.7M (with no external help). The QA engineer will have to develop an entire test suite from scratch, including automatic (using a new framework) and manual testing. On top of that, there would be testing performed by the company employees who use the system every day, taking them off their jobs and asking them to test the new software – which would be the same in case of migrating to x86 on OpenVMS, so we did not consider that as part of the costs. But in general, remember that in the case of the Linux migration, we are talking about a whole new interface, requiring longer testing, adapting the old test plan (even if the new interface is reasonably close to the old one), and there would be employee training involved – unlike the x86 migration scenarios. We also need to factor in documentation and training.
Why does the team need to be larger when running on Linux? First, if we don’t already have enough Linux engineers, there would be 1-2 additional systems managers to provide 24/7 availability and to install the many updates that would inevitably be released within 10 years and that would probably break backward compatibility. An alternative to this would be getting support from a third-party company and/or signing up for longer support with CIP - the costs of that are unknown to us. Second, there would be a larger development team: at least one front-end developer for the web part of the application, one back-end developer for the server portion, and one QA engineer. Why? Going from COBOL and DECforms to let's say C# and Javascript, here would be a lot more updates to dependency libraries, requiring one to recompile and relink with new libraries, praying there are no deprecated functions. It's very likely that at least some parts of the application would have to be rewritten over the course of those 10 years, and a full-time QA engineer would be required to test the changing functionality. Costs could be reduced by finding a third-party solution that provides some of the same functionality as the original application or by outsourcing the development into a different company, which is typically slightly cheaper. However, this would be determined on a case-by-case basis, and we are not familiar with many successful examples of such cost reductions, so we will stick to our original estimates.
One other way to reduce costs that we typically see with migrations like this would be going from Oracle Rdb on OpenVMS to an open-source database solution on Linux. This option would also be available when going OpenVMS to x86, so that does not really add anything to the comparison. However, while considered a little less disruptive when the entire application is being replaced, it still adds a degree of risk to the project as well as increasing its cost compared to Oracle Rdb to Oracle Classic migration.
Conclusion
Migrating from Integrity to x86 on OpenVMS is cheaper than migrating from one OS to another. It is more straightforward, it requires a narrower set of skills, it is less time-consuming and less risky. The migration costs are therefore much lower. Running on OpenVMS as opposed to running on Linux means fewer and less disruptive updates, less work for the team (both system management- and application-related). However, software costs are lower when running on Linux, and Linux expertise is more accessible and probably already exists in the company, which may make it the cheaper solution in the long run in a subset of cases (but not always). The end result is, as usual, “it depends” - but I hope that this article has made you consider some of the factors in your migration that you hadn’t considered before, giving you a better view of the problem. Whatever you do, VMS Software will be there to help you protect your application for as long as you decide to run it.
Chief Executive Officer
