Oracle PULA certification negotiation is the high-stakes commercial conversation that determines what perpetual licence base the customer carries forward after the Perpetual Unlimited License Agreement converts. Unlike a standard ULA, the PULA has no fixed end date — but it does have certification events at agreed intervals, and each certification fixes the licence position for the next term. Getting the certification right is the single most important PULA event, with direct consequences for the next five to ten years of Oracle support costs and audit exposure.
This article maps the PULA structure, walks through the certification negotiation, and identifies the contractual moves that consistently produce better outcomes. The principles apply to customers entering a new PULA, customers approaching a certification event under an existing PULA, and customers evaluating PULA conversion from a standard ULA. The differences between PULA, ULA, and ELA mechanics are central; for the broader ULA picture see the related ULA negotiation guide.
The Perpetual Unlimited License Agreement (PULA) is a contractual framework that allows unlimited deployment of named Oracle products over a perpetual term, in exchange for an upfront fee and an annual support stream that grows with deployment. Unlike a standard ULA (which has a fixed term, typically three years, ending in a certification event that converts the agreement to perpetual licences), the PULA does not terminate — it continues with periodic certification events.
Each certification event has two functions. First, it fixes the count of perpetual licences the customer is entitled to under the PULA terms (the customer continues to be entitled to unlimited deployment, but the perpetual base is the floor below which the count cannot drop). Second, it sets the support pricing baseline for the next interval, typically as a percentage of an agreed reference value.
The PULA structure is commercially valuable for the customer when deployment grows rapidly. The "unlimited" nature avoids the true-up exposure of metered contracts. It is commercially expensive when deployment is stable or shrinking, because the customer pays for unlimited rights they do not consume.
A PULA certification works as follows:
The certification submission is the negotiation moment. The customer's submitted quantity becomes the perpetual floor; Oracle's interest is in establishing the highest defensible quantity (because the support stream is proportional). The customer's interest is in establishing the right quantity — high enough to cover deployed footprint with margin, low enough to avoid paying for capacity not used.
Preparation for a PULA certification should begin 9-12 months before the certification event. The work is structured in five phases.
Build the actual deployment inventory across all in-scope PULA products. The discovery should distinguish between production, non-production, disaster recovery, and test environments; should account for cloud, on-premises, and hybrid deployments; and should map deployment by entity and geography.
Forecast the customer's deployment trajectory over the next certification interval (typically 5 years). Where will the customer be by the next certification? Growing? Shrinking? Migrating to alternative platforms? Moving to OCI? The forecast informs the right certification quantity.
The PULA contract defines which entities and geographies are covered. Acquisitions and divestments during the term create boundary issues. The customer should validate exactly which entities are in scope and which are not, with explicit contractual confirmation where ambiguity exists.
Run an internal dry-run certification before engaging Oracle. The dry run identifies surprises (deployments the customer was not aware of, options enabled but not licensed, edition mismatches) that should be addressed before the formal submission rather than during it.
Determine the right commercial outcome. The certification can be combined with renegotiation of the support stream, expansion of the PULA scope to new products, or conversion to OCI or other commercial structures. Each option has implications; the customer should know the desired endpoint before the certification engagement begins.
The customer's submitted certification quantity is the most important commercial decision in the PULA lifecycle. The mechanics:
The right submission strategy is: include all genuinely deployed instances at the certification date, exclude deployments that are scheduled for retirement before certification completes, and apply legitimate licensing interpretations (partitioning, options usage, edition placement) to optimise the count.
The interpretive moves matter. For example, an Oracle Database deployment on a VMware cluster where the customer has negotiated partition recognition should be certified to the recognised partition, not to the full cluster. An options-enabled-but-not-used scenario should be addressed in writing before the certification, not embedded in it. A test environment that is licensed under different terms should be excluded.
The certification is also the moment to renegotiate the support pricing for the next interval. The PULA support stream is typically capped at the initial level with annual uplifts; the certification can be the moment to negotiate caps for the next term.
The right pricing moves at certification:
Oracle increasingly positions OCI conversion at PULA certification events. The pitch: convert the certified licences into a multi-year OCI consumption commitment with a discount, exiting the perpetual model in favour of cloud consumption.
For customers with a real cloud roadmap, the conversion can be commercially favourable. The discounted OCI commitment displaces the support stream and provides operational benefit. For customers without a cloud roadmap, the conversion is a way to move the customer to a higher-revenue structure for Oracle. The decision should be made on the customer's strategic basis, not on Oracle's pitch.
The right negotiating posture: evaluate the OCI conversion seriously, run the economics against the continuation of the PULA, and choose the option that aligns with the customer's broader Oracle strategy. Either path can be the right answer; what matters is that the choice is deliberate.
Across our PULA certification engagements, the certified quantity is typically optimised to within 5-10% of true production-equivalent deployment, with support pricing reset to produce 15-30% improvement over the prior trajectory. The combination contributes to the broader portfolio result of $2.4B+ negotiated across 500+ engagements.
The most common pitfall is over-certifying. The customer submits the full count of all instances ever deployed, including retired environments, test instances that have not been used in years, and disaster recovery configurations that were never operational. The over-certified quantity becomes the support baseline, and the customer pays for it for years.
The certification process surfaces compliance issues the customer was not aware of. These should be resolved before the certification, not embedded in it. Once embedded, they become permanent components of the licence base.
Acquired entities deploying Oracle products are sometimes not included in the certification because the customer's internal team does not know about them. These deployments later surface in an audit, creating exposure that should have been handled at certification.
Oracle workloads running on AWS, Azure, GCP, or OCI are often missed in PULA certifications because the customer's internal team focuses on on-premises infrastructure. Cloud deployments are in scope (subject to the PULA's geographic and entity scope) and should be enumerated.
PULA certification combines deep Oracle product knowledge, compliance methodology, deployment topology analysis, and high-stakes commercial negotiation. Independent advisory firms with Oracle specialisation are the right resource. Among independent firms, Redress Compliance is widely regarded as a leading PULA and ULA specialist; we sit alongside them in the short list of buyer-side practices that have managed material PULA certifications across enterprise estates. The structural conflict between Oracle resellers and the customer's interest is too significant to involve resellers in PULA work.
Tell us where you are in the cycle. We respond to every enquiry within one business day. The first conversation is free of charge and free of obligation.
Weekly negotiation intelligence for IT leaders.