A ULA is a fixed fee for unlimited deployment, so the months before exit are the time to put genuine capacity to work. The discipline is to stand up what you will truly use, evidence it, and certify it as permanent entitlement. Capacity that exists only to pad a number is the kind a later review takes back.
Yes. Deployments that are live within the term, inside the contract scope, and backed by evidence are counted at certification and become perpetual entitlement. The discipline is to stand up capacity you have a real plan to use, because the fixed fee has already bought you the right to deploy. A deployment that exists only to inflate the number is exactly what a later audit surfaces and unwinds.
The unlimited right is real value, but only the part you actually deploy and can defend converts into a permanent license. Stand up capacity with a genuine purpose, document it as you go, and the number holds for good.
Inside the term, every named product can be deployed without an incremental fee. At certification that deployment is frozen into your perpetual count, and the unlimited right ends. Anything you have not stood up by then, you will buy later at list. So the months before exit are the moment to bring forward genuine projects, consolidate onto Oracle where it makes sense, and make sure planned capacity is live rather than sitting on a roadmap. Support fees continue at the ULA level regardless of the certified count, so the additional capacity does not raise your annual bill.
The line is not about intent, it is about evidence and use. A defensible deployment has a server or instance that exists, a deployment date inside the term, a workload or a documented purpose, and a record that a reviewer can follow. Phantom capacity is an instance spun up the week before certification with nothing running on it, no plan behind it, and no trail. The first is entitlement you paid for. The second is audit exposure dressed up as value.
If a database consolidation, a new analytics platform, or a disaster recovery build is already planned, completing it inside the term turns future spend into captured entitlement. The project would have happened anyway, so the capacity is real by definition.
Test, development, and disaster recovery instances are routinely left out of a first estimate, yet each is legitimate entitlement when deployed within the term. Standing up capacity sometimes means nothing more than properly accounting for what is already live.
Where a contract requires a deployment to run 365 continuous days to count, capacity stood up too late simply will not qualify. The clock decides the deadline, and it is usually earlier than people expect, so the planning has to start well before the term ends.
A manufacturer had a disaster recovery build and a reporting platform both scheduled for the year after its ULA ended. By pulling both forward inside the term, the deployments were live, evidenced, and counted at certification rather than purchased afterward at list. The certified count rose, support stayed flat at the ULA level, and because every instance carried a real workload and a documented date, the position held under a later review. Figures are indicative and depend on the specific contract language.
Maximization works because it claims entitlement you are genuinely due. It fails when the count includes capacity that is not real or sits outside scope. Keep three rules. Deploy only what you will use or already use. Record the deployment date, the host, and the purpose as you go, not after the fact. Stay inside the customer definition and territory your contract defines, because a deployment in an out of scope entity creates remediation rather than value. The goal is the highest defensible count, never simply the highest count.
Which environments qualify, how cloud capacity is treated, whether a continuous run clause applies, and what scope your deployments must sit inside all come from the specific agreement. Two firms with similar estates can stand up very different defensible counts because their contracts read differently. In ULA work the answer almost always depends on the specific wording, so the plan is built against your own contract, not a general template.
If your ULA is approaching its end, the window to stand up genuine capacity is open now and closes at the term. Start with the deployment maximization pillar guide, then read the deployment maximization guide and moving workloads on premises to count them.
Yes, deployments that are live within the term, inside contract scope, and backed by evidence are counted at certification. The discipline is to stand up capacity you have a genuine plan to use, because a deployment that exists only to inflate the number is the kind a later audit surfaces and unwinds.
No. Test, development, and disaster recovery instances deployed within the term are legitimate entitlement and count toward the certified number, provided they are real and documented. The metric and the contract scope decide what qualifies, so the answer depends on your specific agreement.
Allow enough runway for any continuous run clock to complete and for the deployment to be genuinely operational and evidenced. Where a cloud clause requires 365 continuous days, capacity stood up late simply will not qualify. Twelve to eighteen months of runway gives room to plan and document properly.
Book a confidential assessment and we will help you turn genuine, evidenced capacity into permanent entitlement before your term ends.