For many organizations running Oracle Rdb on OpenVMS, migrating to a modern relational engine is the right long-term destination. It is also, far too often, the wrong first step.

That’s the idea behind our upcoming webinar, Three Paths Forward for Oracle Rdb on OpenVMS, on October 7, 2026, from 12:00 to 1:00 PM ET, co-presented with PARSEC Group and CONNX. Register for the October 7 webinar. Before then, here’s what we mean.

What a database swap actually demands

Supported targets exist. Mature, standards-conformant relational engines such as Mimer SQL run on OpenVMS x86, and native Oracle is available on Windows and Linux. The engine is rarely the hard part. The hard part is everything around it, so before committing to a new engine, a business should be able to answer four questions:

1. Can you rebuild the applications that talk to the database? That means having the source code and understanding what it does today.
2. Is any SQL constructed dynamically at runtime, or written against Rdb-specific behavior rather than the standard? This code is where migrations surprise people.
3. Is your team ready for a new engine? New tooling, new failure signatures, and a new performance profile all have to be learned. The engine also has to support the data-access and integration tools you rely on today or plan to buy.
4. How will you validate the new database without disrupting production? Critical operations can’t serve as the test environment.

If any of those answers is “not yet,” starting with the migration means discovering the answers during the cutover.

Three paths, not three choices

In the webinar, we’ll walk through three paths: Emulation, Bridge, and Migration. They aren’t mutually exclusive. Many businesses combine them because doing so controls how many variables change at once. Instead of switching hardware, operating platform, database engine, and recompiled applications in one move, you can cut over on your own timeline, and when something fails, you can isolate why.

The path that often goes unexamined

The Bridge path starts with a question: what is actually driving your timeline?

If the pressure is running a supported engine on supported hardware, that’s a platform question. But if the pressure is that reporting, analytics, or an AI initiative needs the data and can’t get at it, that’s an access question, and access questions have answers that don’t require converting anything.

Supported SQL data-access and virtualization products, including CONNX, exist for Rdb, RMS, and Codasyl DBMS on OpenVMS. They let modern tools and data teams query the data where it lives, using standard SQL, without deep OpenVMS expertise. That relieves the business pressure without touching the engine, the application, or the platform. Read the CONNX handout in our document library.

The Bridge doesn’t make the migration question disappear. It changes when you have to answer it, and it lets you answer it on evidence rather than under a deadline.

Our position

Salem’s view is that database migration is a good decision too often made under duress, and the duress is what makes it expensive. Most often the pressure comes from hardware: aging VAX and Alpha systems, thinning spares, a support horizon someone put on a slide.

That pressure can be removed on its own. Emulation on vtVAX and vtAlpha moves the workload onto modern hardware while the application, the database, and the operating environment stay exactly as they are. Nothing gets recompiled or revalidated, and the hardware clock stops running against you.

From there, the application layer becomes a project you manage rather than a discovery you make during a cutover. Get the source under control. Document what the applications actually do. Find out which programs are the problem while that’s still an interesting question rather than an urgent one. Solve the data-access demand in parallel, since it doesn’t have to wait for the engine decision. Then choose a target database with a real scope, a real estimate, and a validated migration plan.

That sequence (Stabilize, Understand, Migrate) is the foundation of the Salem Controlled Runway. A migration to a modern relational engine may well be where it ends. Several of the workloads we support today will eventually land on one, and we would rather help a customer get there deliberately than watch them get there in a hurry.

Sequence it correctly and it’s a project. Sequence it backwards and it’s an outage with a project attached.

Where to start

• Join the webinar: Three Paths Forward for Oracle Rdb on OpenVMS, October 7, 2026, 12:00–1:00 PM ET.
• Get a clear picture of your risk: Our fixed-scope, fixed-fee Legacy Continuity & Risk Assessment shows where your environment stands before you commit to any path.