Oracle Essbase 21c Premier Support Ends December 2027

Oracle's Lifetime Support Policy for technology products. The version dated October second, twenty twenty-six. Scroll to the Essbase table. Essbase twenty-one point x, premier support ends December twenty twenty-seven. And the extended support column next to it... says Not Available.

Not available? Not a date, not a price, not call-us-for-a-quote. Just no.

Just no. No three-year paid cushion. December twenty twenty-seven, you drop straight to sustaining support, which Oracle defines as indefinite technical support. You get access to experts. You do not get new fixes for new problems.

So anyone running Essbase on-prem right now has about fourteen months of runway. On a platform that takes longer than that to move.

That's the episode in one line. Except... in that same document, there's a new row. And that row is Oracle quietly giving you permission to do nothing for five years.

Go on.

Essbase twenty-six A-I. General availability August twenty twenty-six. Premier support through August twenty thirty-one. Extended through December twenty thirty-three.

Hang on. Oracle shipped a new on-premise-capable Essbase release with support into the twenty-thirties... while telling everybody the future is cloud?

Both true at once. Oracle's own EPM roadmap lays out three paths. Stay on-premise and upgrade. Upgrade and lift the stack onto Oracle Cloud Infrastructure. Or migrate the applications into Cloud EPM proper.

Those aren't three versions of one project. One's a weekend. One's eighteen months and a reorganisation.

And most shops treat them as the same decision. Which is how people end up halfway through a migration with no exit.

Okay. So who actually moves now?

Lifecycle math first. If you're on twenty-one point x and you'll still be there past December twenty twenty-seven, you have two defensible options. Upgrade to twenty-six A-I and buy five more years. Or get the applications into the cloud before the clock runs out. Doing nothing isn't a third option, it's the first one with worse paperwork.

And the cloud target for a pure Essbase cube is what? Because Cloud EPM is a planning suite, and plenty of these cubes aren't planning at all.

Right question. Oracle's roadmap maps Essbase cubes onto Cloud EPM FreeForm... the free-form application type, where you build dimensions the way you want instead of inside a fixed planning template.

Which sounds like parity. I've heard that word before.

So have I. Which is why the May twenty twenty-six Cloud EPM release notes are the most useful document in this whole story. Oracle added support for Essbase load rules in cloud applications. You reuse your existing load rules and source files. No rebuilding them as Data Integration definitions.

Oh, that's genuinely big. Rebuilding load rules is the line item everyone underestimates by a factor of three.

Oracle's stated benefit is less migration effort, plus faster direct loads because you skip the Data Integration overhead. Now read the note underneath.

There's always a note underneath.

Load rules that use S-Q-L to pull data straight from relational sources are not supported. If your rule has S-Q-L in it, you strip the S-Q-L out and supply the data as a separate file.

Wait. Half the mature Essbase estates I've seen load straight out of the warehouse with S-Q-L in the rule. That's not an edge case, that's Tuesday.

So here's your triage, and you can run it this week. Count your load rules. Two piles, S-Q-L and non-S-Q-L. The non-S-Q-L pile is nearly lift-and-shift now. The S-Q-L pile needs an extraction layer built upstream before anything moves.

That ratio decides your timeline.

It decides your timeline AND your fork. Heavy S-Q-L dependency, custom calc scripts, cubes that aren't really financial planning? Wait. Upgrade to twenty-six A-I, take the window to twenty thirty-one, watch parity close.

And the ones who go now?

Cubes that genuinely are financial planning and reporting, with flat-file loads, and a reason to want what only exists in the cloud. Oracle's roadmap cites T. Rowe Price, where Cloud EPM expense predictions improved twenty to thirty-five percent against their existing driver-based methods, and revenue predictions matched them.

That's Oracle's own customer story though. A vendor reference, not an independent benchmark.

Correct, and say that out loud to your steering committee. It's a claim from a roadmap deck, not an audited result. What's confirmed is the dates.

The dates are the part you can't argue with.

And that's the deeper read. Oracle has stopped forcing one answer. Twenty-six A-I is permission to wait, with a support date attached. The load-rule support is an invitation to go. Both real. Your estate decides which one is true for you.

So the worst move is pretending the deadline is softer than it is.

The worst move is finding out in twenty twenty-seven that extended support was never on the menu. What should platform leaders watch next week? Two things. The quarterly Cloud EPM release notes, for anything that closes that S-Q-L load-rule gap. And any refresh of the Lifetime Support table... Oracle updated it on October second, and that table is the only clock that matters.

Count your load rules before someone counts your months.

Every Essbase migration you've watched go badly started with somebody assuming the data would just... arrive.