If you run Oracle Rdb on OpenVMS, you’ve probably already had the conversation internally: We’re covered through 2027, so this can wait.

It’s a reasonable read of the support calendar. It’s also the single most common reason organizations end up moving under pressure instead of on their own terms. The support date is real, but it’s watching the wrong clock. The risk that will actually decide your timeline isn’t the software. It’s the hardware sitting underneath it — and that clock is running faster.

What the 2027 date actually means

Let’s be precise about the calendar, because vague deadlines create either panic or complacency, and both are expensive.

Oracle Rdb Extended Support ends 31 December 2027. From 2028, the product moves to Sustaining Support. In practical terms, Sustaining Support means you keep access to existing patches — but no new ones are produced. If a fix doesn’t already exist for a problem you hit in 2028, it isn’t coming.

That matters. But notice what it doesn’t say. It doesn’t say the software stops working. Rdb will run on 1 January 2028 exactly as it ran the day before. Well-maintained Rdb systems have run reliably for years — often decades — precisely because the database software is mature and stable.

So if the software is stable and supported through 2027, where’s the fire?

The risk isn’t the software. It’s the ground it stands on.

Oracle Rdb doesn’t run in the abstract. It runs on OpenVMS, and OpenVMS, in most production environments, runs on VAX, Alpha, or Itanium hardware. That hardware is where three pressures are quietly closing in at once:

Hardware is aging out. VAX, Alpha, and Itanium systems get harder to source, service, staff, and insure every quarter. Spare parts come from a shrinking secondary market. The engineers who know these platforms are retiring. A failed component that was a one-day fix five years ago can now become a multi-week scramble — or an unrecoverable outage.

There is no native Rdb on x86-64. Oracle has ended Rdb on x86-64. The one destination that would have carried the database forward unchanged onto modern commodity hardware simply doesn’t exist. You cannot “just move it to a new server” the way you might with more current software.

Support is sunsetting on top of all that. After 2027, you’re combining fragile, unsupported-in-practice hardware with a database that no longer receives new fixes. Each risk is manageable alone. Together, on the same production system, they compound.

Here’s the uncomfortable synthesis: your database could be perfectly healthy while the machine it depends on becomes the most fragile thing in your entire operation. The 2027 date tells you when the software support narrows. It tells you nothing about when your hardware fails — and hardware doesn’t consult a support calendar before it dies.

Why “wait until 2027” is the expensive option

The instinct to wait assumes the move is a single event you can schedule for later. It isn’t — not if you want to do it well.

A migration done properly means understanding a system that may have decades of undocumented dependencies, running the old and new environments side by side to prove the new one works, and cutting over only once you’re confident. That takes deliberate time. If you start that work with a hardware failure already in progress, you don’t have deliberate time. You have a crisis, and crises make the decisions for you — usually the riskiest and most expensive ones.

The decision to move off aging hardware has, in effect, already been made for you. Oracle made part of it by ending Rdb on x86-64. Your hardware is making the rest of it on its own schedule. The only real question left is how — planned and reversible, or forced and all-at-once.

The good news: you almost certainly have more runway than you think

None of this is a reason to panic. It’s a reason to look, honestly, at where you actually stand — because the answer is usually better than the fear.

The first, most urgent risk — physical hardware — can be taken off the table in days, without touching the database, the operating system, or your applications. Virtualizing your existing environment onto modern x86 hardware removes the single-point-of-failure risk of aging machines while leaving everything else unchanged. Same OpenVMS. Same Rdb. Same applications. No rewrite, no cutover, no gamble. That alone converts your most dangerous exposure into a stable foundation, and it buys you the thing you were missing: time to migrate on your own terms.

From that safe ground, everything else — mapping dependencies, planning a target, moving incrementally to native Oracle on Windows or Linux — happens in reversible stages, on your timeline, not the hardware’s.

Find out how much runway you actually have

You don’t have to guess at your exposure, and you shouldn’t. Salem’s starting point is a fixed-scope, fixed-fee Risk Assessment: a clear-eyed look at your Oracle Rdb environment, your real hardware risk, and a costed, phased plan for what comes next. Low-cost, no obligation beyond the assessment, and it tells you precisely how much time you have — instead of leaving you to find out the hard way.

The 2027 clock is real. But it’s not the one that will wake you up at 3 a.m. Watch the hardware. Then give yourself a runway.

Ready to see where you stand? Request your fixed-fee assessment or talk to a Salem specialist about your Oracle Rdb environment.