FinOps is often presented as the “hip party” that starts the moment your first workload lands in the cloud. From that point on, everything is suddenly measurable, traceable, and billable down to the millisecond. Finance is delighted by this newfound transparency, while IT may become slightly nervous about the direct accountability.
But organizations that define FinOps that narrowly overlook an uncomfortable truth: for many enterprises, the largest IT cost items are still running comfortably on-premises.
The Oracle Trap
Look at the average Oracle environment. Licenses were purchased years ago, support contracts run on autopilot, and the hardware has long since been written off. It feels stable, manageable, and, above all, safely out of reach of the FinOps police.
That is, until Oracle Cloud Infrastructure, or OCI, enters the conversation and the comparison between these two worlds becomes inevitable. And that is exactly where the friction starts.
As soon as the question arises whether a database should remain on-premises or move to OCI, the discussion quickly shifts from architecture to cost. The problem? We are speaking two different languages. Cloud costs are transparent and elastic. On-premises costs are historical, implicit, and often buried under layers of overhead, depreciation, and internal allocation models.
My Stance
If you cannot express your on-premises infrastructure in the same units as cloud consumption, you are not practicing FinOps. You are reporting costs, not managing them. And cost reporting alone will not help you make the right architectural choices for a hybrid or Multicloud strategy.
Normalization Is the Magic Word
An on-premises database still consumes CPU, memory, storage, licenses, support, and management hours. At its core, this is no different from OCI. The difference lies in how we administer, allocate, and interpret those costs. As long as we continue to treat Oracle licenses as a “fixed given” and OCI resources as “variable,” every comparison remains an apples-to-oranges exercise.
Only when you normalize on-premises costs using cloud logic do the scales fall from your eyes. You may discover that some workloads are surprisingly efficient on-premises, while others are extremely expensive because of structural under-utilization. Suddenly, DBA capacity becomes a serious cost driver per workload, rather than just a “fixed team.”
FOCUS as a Mental Model
The emergence of standards such as FOCUS, the FinOps Open Cost and Usage Specification, is interesting not only because of the technical format, but because of the mindset it encourages. It forces organizations to link cost to usage and responsibility. Not because that sounds modern, but because without it, you cannot answer a basic question:
“What does this database cost us per month, and what will it cost tomorrow in OCI, with or without BYOL?”
In the Oracle world, FinOps is rarely about “a quick saving.” It is about knowing where you stand before you move. Especially with complex ULAs, hybrid scenarios, and strategic dependencies, this is not a luxury. It is a necessity.
Conclusion
FinOps is not a discipline you pull out of the cupboard only after a migration. It is a way of looking at your landscape that is most relevant before the migration begins. Organizations that cannot explain their on-premises Oracle landscape in cloud terms are not “too early” for FinOps. They may already be too late. By embracing this mindset, we can put DBAs and developers back where they belong: on the hero’s stage, as strategic advisors to the business.
What do you think? Have you started translating your on-premises costs into the language of the cloud, or is your data center still a black box?
Global Licensing Advisory Services (GLAS), offers unbiased guidance to Oracle customers on how to best align their use of Oracle software with the strategic and tactical goals of their business.