Migrating off Oracle to PostgreSQL can cut your long term licensing cost, but its value depends on when you do it relative to the term. The destination is the easy part. The sequence against the ULA clock is what decides whether the migration saves money or quietly destroys entitlement you were entitled to keep.
By the Meridian advisory team · Ex Oracle licensing analysts · Updated June 2026
A PostgreSQL migration changes your Oracle cost over the long term, but its value depends on how it is timed against the ULA term. Migrate too early and you shrink the count you could have certified for free. Migrate too late and you keep paying support on entitlement you no longer use. The clock, not the technology, decides the right sequence.
For most organisations the answer is certify first, then migrate. The reasoning follows directly from how a ULA works. During the term you have unlimited deployment of the named products for a fixed fee, and at the end you get one opportunity to convert what you have deployed into perpetual entitlement through certification. That conversion has no fee, and crucially support stays flat at the ULA level regardless of how high the certified number lands. So the entitlement you certify is, in effect, free value that you keep forever. If you migrate Oracle databases to PostgreSQL before you certify, you remove those deployments from the count, and you hand back entitlement you could have banked at no cost. The disciplined path is to certify the strongest defensible position first, lock in the perpetual licenses, and only then reduce your Oracle footprint to cut the ongoing support you actually pay. There is a narrow exception: where you are certain you will never use a class of entitlement, the migration is already well advanced, and carrying the licenses adds support cost with no offsetting benefit. Even then the decision deserves a model rather than an instinct, because the cost of certifying more is zero and the option value of holding entitlement is rarely nothing.
Certification is a one time chance to convert unlimited deployment into permanent entitlement at no fee, with support held flat. Migrating off Oracle before you certify throws that chance away for the migrated systems. Certify first to bank the entitlement, then use a PostgreSQL migration to retire Oracle footprint and cut ongoing support. The migration realises savings; certification protects the asset. Sequence them in that order against the term.
The term defines three windows, and each rewards a different kind of migration activity. The first window is the body of the term itself, while the ULA still grants unlimited deployment. This is the cheapest moment to stand up replacement capacity in parallel, because nothing you deploy on the Oracle side costs incremental license money, and you can run old and new together during cutover without a licensing penalty. The second window is certification, the fixed point where the entitlement you keep is set. Everything you intend to certify must be deployed and evidenced before that line. The third window opens after certification, governed by the support clock and the rules for terminating support on licenses you no longer need. A migration that respects these windows deploys in parallel during the term, certifies the position at the line, and retires Oracle systematically afterward. A migration that ignores them tends to either rush systems off Oracle before certification, destroying entitlement, or drift for years afterward, paying support on idle licenses that a planned termination would have removed.
One advantage of an active ULA is easy to overlook: you can run the Oracle system and its PostgreSQL replacement side by side without paying for the extra Oracle deployment. Migrations are safest when the old system stays available until the new one is proven, and that overlap normally carries a cost. Inside the term it does not. Use the window deliberately. Build and validate the PostgreSQL targets while the Oracle originals still run under unlimited rights, so that by certification you have a clear picture of what is genuinely replaced and what still needs to be certified. The term is not just a countdown; it is a period of free optionality that a well planned migration exploits.
Eventually, and only when you act on it. Oracle support is charged on the licenses you hold, not on the systems you actually run. Decommissioning an Oracle database to PostgreSQL stops the usage, but it does not stop the support invoice on its own. The saving arrives only when you formally terminate support on the licenses the migration has retired. That step carries its own mechanics worth understanding before you take it. Oracle support agreements commonly include repricing provisions, so dropping a subset of licenses from a support set can trigger a recalculation that raises the per unit cost on what remains, eroding part of the expected saving. The way licenses are grouped and the order in which you terminate them therefore matters as much as the migration itself. A migration handed to the support team as a finished fact often realises less than expected, because the support implications were not designed in. A migration whose endgame is a clean, modelled support termination realises the full benefit.
| Phase against the clock | Right migration move | The mistake to avoid |
|---|---|---|
| During the term | Build PostgreSQL targets, run in parallel free | Decommissioning Oracle you could certify |
| At certification | Certify the deployed Oracle position fully | Certifying less because migration began early |
| After certification | Retire Oracle, model support termination | Paying support on idle licenses for years |
| Support termination | Group and sequence to limit repricing | Dropping a subset and triggering a reprice |
Consider a retailer, figures and facts indicative only, with a large Oracle database estate and an active PostgreSQL programme. The engineering team, focused on modernisation, had begun decommissioning Oracle databases a year before the ULA expired. Left unchecked, that would have shrunk the certified count materially. By pausing decommissioning until after certification, the organisation first certified the full deployed position, banking perpetual entitlement at no fee, and then resumed the migration and modelled a phased support termination that limited repricing on the remaining licenses. The total outcome was both a stronger certified asset and a real reduction in ongoing support, achieved by ordering the same activities differently.
As with most ULA questions, the general logic holds but the specifics depend on your agreement and your environment. The products in scope, how options and management packs are licensed, how your support sets are structured, and how much of the estate is genuinely replaceable by PostgreSQL all shape the answer. A database heavy ULA with high value options behaves differently from a narrow single product agreement. An estate that PostgreSQL can absorb cleanly behaves differently from one with deep dependence on Oracle specific features. The principle to carry into the analysis is constant: certification is the moment of maximum value capture, so protect it, and let the migration do its work on the cost side afterward, designed around the support mechanics rather than bolted on at the end.
Migration is one lever in a larger exit plan. Read ULA to OCI when the math works for the alternative of moving workloads to count rather than retire them, and the multi year exit roadmap for how to sequence migrations, certification, and support across years. Our ULA exit strategy guide is the pillar that frames migration, cloud counting, and timing as one decision. To time a PostgreSQL migration against your own ULA clock, the next step is a confidential assessment.
In most cases certify first, then migrate. Certification is your one chance to convert unlimited deployment into perpetual entitlement at no extra fee. Migrating off Oracle before you certify removes deployments you could have counted. Certify the position you have, then reduce Oracle footprint afterward to cut ongoing support. The exception is where you will clearly never use the entitlement and the migration is already underway.
Eventually, but not automatically and not immediately. Support is paid on the licenses you hold, so the saving arrives only when you formally terminate support on the licenses the migration retires. Repricing risk can apply when you drop a subset of licenses, so the order and grouping of what you terminate matters. Migration enables the saving; the support decision realises it.
The term sets the windows. While the ULA runs you have unlimited deployment, so it is the cheapest time to stand up replacement capacity in parallel. Certification fixes the entitlement you keep. After certification the support clock governs what you can retire and when. A migration planned around these windows costs far less than one that ignores them.