Removing Oracle before certification rarely saves money, because a higher certified count is free and support does not fall with it. Replace workloads for real technology reasons on a plan that runs after exit, not as a tactic to certify less.
There is a tempting logic that says if you are leaving Oracle, you should start by getting rid of Oracle, replacing databases with alternatives before you certify so you end the relationship lean. For most organisations that logic is backwards at the certification stage, and acting on it forfeits value that the ULA mechanics would otherwise hand you for free. Replacing Oracle workloads can be the right long term strategy, but the timing relative to certification changes whether it creates value or destroys it. This article separates the genuine case for replacement from the false economy of removing Oracle to certify a smaller number.
Rarely, and almost never to reduce the certified count. Certification carries no fee, and support fees continue at the ULA level regardless of how many processors you certify, so a higher certified number is free value rather than added cost. Removing Oracle in order to certify less therefore throws away perpetual licenses you could keep at no extra charge, while delivering no support saving in return. Replacement belongs to your technology roadmap, planned and executed after exit when it can be done deliberately, not compressed into the certification window as a tactic. Place this inside the wider plan in the ULA exit strategy guide.
The certified count becomes your perpetual entitlement. Every defensible deployment you certify is a license you own forever at no incremental cost, and a larger count gives you headroom to grow, to reallocate, and to negotiate from later. Tearing out Oracle before you certify shrinks that permanent asset for no offsetting benefit, because the support bill is set by the agreement, not by the count. The principle that certifying more is free is the foundation here, and it is the opposite of the instinct to minimise.
Teams sometimes assume that removing Oracle before exit cuts the support bill. During a ULA it does not, because support is tied to the agreement rather than to the certified number. Support reduction is a separate exercise, undertaken after certification and governed by Oracle's rules on how support sets can be reduced, which carry their own constraints. Conflating the two leads to removing valuable deployments in the false belief that the bill will follow them down.
There are real reasons to replace Oracle: a strategic move to another platform, the end of life of an application, a workload that fits a managed service better, or a decision to consolidate. These are legitimate and often valuable. The point is that they are technology decisions with their own business case and their own timeline, and they are almost always cleaner to execute after you have certified a strong count, so you keep the licenses as an asset while you transition rather than destroying them on the way out.
Before removing any Oracle workload near exit, ask three questions. Is the removal driven by a genuine technology or business case, or only by a wish to certify a smaller number? Have you confirmed that support will not fall as a result during the ULA? And could the same migration be done after certification, keeping the perpetual license as an asset during the transition? If the only reason to act now is to certify less, the move almost certainly costs more than it saves. The specifics depend on your roadmap and your contract.
Consider a logistics company, figures indicative, that planned to move several databases to an alternative platform and assumed it should decommission them before certifying. On review, those databases represented a significant block of processors that would have certified into perpetual licenses at no cost, and the support bill would not have moved either way during the term. The team reversed the sequence: it certified the full defensible count first, capturing the licenses as an asset, then ran the platform migration on its own roadmap afterward. It kept the perpetual entitlement as headroom and optionality, and the eventual support reduction was handled as a separate, deliberate step rather than being assumed to follow the migration.
Replacing Oracle workloads before exit rarely saves money and usually forfeits free perpetual value, so replacement belongs on your roadmap after certification rather than inside the window. Read this alongside the ULA exit strategy guide and the sibling pieces the OCI incentives Oracle will offer at exit and Exadata decisions at ULA exit. If you are weighing a platform move around your exit, the next step is to sequence it correctly so you keep the licenses first.
Rarely, and almost never to reduce the certified count. Because there is no fee for certification and support stays flat regardless of the certified number, a higher count is free value, so removing Oracle to certify less usually destroys value rather than saving it. Replacement makes sense for genuine technology reasons, planned after exit, not as a certification tactic.
Not at the ULA stage. Support fees during a ULA are tied to the agreement, not to how many processors you certify, so removing deployments before certifying does not cut the bill and does forfeit perpetual licenses you could have kept for free. Support reduction is a separate, later exercise governed by the matching service levels rule.
We sequence your platform plans around the certification window so you capture the perpetual count as an asset, then run replacement on its own timeline.