A partial exit certifies your Oracle ULA to capture perpetual licenses for the products you keep, while migrating or retiring the workloads you do not. The sequence is what protects the value: certify first so everything deployed counts, then migrate against a locked number rather than throwing count away before you capture it.
Not every organisation wants to keep every Oracle product it deployed under a ULA. Some plan to move databases to a different platform, retire middleware, or consolidate after a strategy change. The partial exit is how you handle that without leaving value behind. The core insight is simple: a ULA certifies as one agreement, and everything deployed at the certification date counts toward your perpetual entitlement, so the worst thing you can do is dismantle deployments before you have captured them. This article sets out how to certify the products you keep, migrate the ones you do not, and sequence the count, the move, and the support line so the exit is clean on every axis. The order of operations is the whole game, and as always it interacts with your contract, so confirm the detail against your own terms.
A partial exit means certifying your ULA to capture perpetual licenses for the Oracle products you intend to keep, while planning to migrate or retire the workloads you do not. It is not a way to certify only part of the agreement; a ULA certifies as a whole, and the certification covers all the products named in it. What is partial is your forward plan for the estate. You maximize the count for the products that will stay, because those licenses you will use for years, and you organise the migration of the products that will go around the certification event so that nothing is lost in the timing. Done well, a partial exit leaves you holding a strong perpetual entitlement for your future Oracle footprint and a clean migration path for everything else.
Certify everything you are entitled to, then decide what to keep. Tearing down deployments before the count is locked is giving away licenses you already paid for.
Generally certify first, then migrate. Workloads still deployed at the certification date count toward your perpetual entitlement, so retiring or migrating them before you certify can throw away count you were entitled to capture. Even where you intend to move a workload off Oracle entirely, having it deployed at the moment you certify can lift the number, and a higher certified number costs nothing extra in support. The right default is therefore to lock the count with the estate at its fullest defensible extent, and only then begin the migration. There are exceptions. If a migration target changes how a workload should be licensed, or the contract treats a planned move in a particular way, the calculation can shift, so the disciplined approach is to model both sequences against the ULA clock and choose on the numbers rather than on instinct.
| Step | What happens and why it matters |
|---|---|
| 1. Measure the full estate | Count everything deployed, keep or migrate, to maximize the certified number |
| 2. Certify on evidence | Lock perpetual licenses for the whole agreement before any teardown |
| 3. Migrate what leaves | Move or retire the workloads you do not keep, against a locked count |
| 4. Plan the support line | Manage support deliberately as products are retired over time |
Sequence is indicative; confirm against your contract and the ULA clock.
Support continues at the ULA level after certification regardless of the count, so the act of certifying does not raise it, and capturing a larger number does not cost more in support. That is the same flat support rule that makes maximization free at exit, and it holds in a partial exit too. Where a partial exit can change the support bill is over time, as you retire the products you migrated away from. Reducing support is possible, but it follows its own contractual rules, and Oracle support reductions can carry repricing effects that erode the saving you expected. None of that is automatic, and a migration does not cut the bill by itself. The support line is its own workstream within the partial exit, to be planned deliberately once the count is locked and the migration is underway, rather than assumed as a free consequence of moving off a product.
It protects against the two ways value leaks out of a planned move off Oracle. The first is certifying low because workloads were already torn down, which permanently shrinks the perpetual entitlement you keep for the products that remain. The second is migrating into an unlicensed position, where a workload moves to a new platform without a clean entitlement behind it and surfaces later as exposure. A properly sequenced partial exit closes both. The count is captured at its fullest before anything moves, so the keep estate is strongly licensed, and the migration is planned against owned entitlements and documented evidence, so the move estate is clean. The result is an exit that serves your strategy rather than fighting it, which is the point of treating certification and migration as one plan rather than two disconnected projects.
A partial exit usually involves the cloud on one side and a clean count on the other. Read OCI and your ULA exit for how OCI counts toward the baseline, and bring your own license to OCI with certified licenses for running the count on the cloud afterward. For the full exit picture, read the ULA exit strategy guide.
A partial exit means certifying your ULA to capture perpetual licenses for the Oracle products you intend to keep, while planning to migrate or retire the workloads you do not. You still certify the whole agreement, since a ULA certifies as one, but you maximize the count for what stays and sequence the migration of what goes around the certification date.
Generally certify first, then migrate. Workloads still deployed at the certification date count toward your perpetual entitlement, so retiring them before you certify can throw away count you were entitled to capture. Migrate after the number is locked, unless the contract or the migration target changes the calculation, in which case model both sequences against the ULA clock.
Support continues at the ULA level after certification regardless of the count, so certifying does not raise it. A partial exit can let you reduce support over time by retiring products you no longer run, but support reductions follow their own contractual rules and repricing risk, so plan them deliberately rather than assuming a migration cuts the bill automatically.
Book a confidential assessment and we will sequence your count, your migration, and your support line so a partial exit serves your strategy instead of leaking value.