Oracle's matching service levels rule requires that licenses grouped under one support agreement carry the same support level. It is the reason you usually cannot drop support on the unused part of a certified set while keeping it on the rest, and it shapes every plan to trim support after a ULA.
After a certification, many estates hold more perpetual licenses than they deploy, and the natural instinct is to stop paying support on the surplus. The matching service levels rule is what usually stands in the way. It is a longstanding Oracle support policy, not a quirk of any one contract, and it governs how support can and cannot be reduced across a group of licenses. Understanding it is essential before any cost cutting plan, because a plan that assumes you can simply cancel support on the licenses you no longer use will collide with this rule almost immediately. This article explains what the rule is, why Oracle applies it, where it leaves genuine room to act, and how to think about reducing support without breaching it. Support and repricing terms vary, so confirm the specifics against your own support agreement and the applicable policy.
Matching service levels is Oracle's policy that all licenses grouped under a single support agreement must be supported at the same level. In practice this means you cannot keep full support on some licenses in a set while quietly dropping it on others in the same set. The rule binds the group together, so a decision about support is a decision about the whole set, not about individual licenses within it. This is the mechanism that prevents the simplest form of cost cutting, namely cancelling support only on the licenses that have fallen idle. The broader support picture it sits within is set out in support costs after ULA certification.
The unit the rule operates on is the support set, the collection of licenses sharing a support agreement. Within a set, support is all or nothing at a given level. You cannot carve out the unused licenses and stop their support while the rest continues, because that would create unequal service levels inside one set, which is exactly what the rule forbids.
The same logic blocks selectively repricing part of a set. Because the set must be treated uniformly, you cannot reduce the support fee on a portion of it while leaving the remainder untouched. Any change to the support level or the supported quantity has to be applied to the set as a whole, which is why support reductions tend to be structural rather than incremental.
The commercial purpose is straightforward: the rule protects the support revenue stream from selective erosion. If customers could cancel support on idle licenses while keeping it on active ones, support bases would shrink steadily as estates evolved. By binding licenses into sets that must be treated uniformly, Oracle keeps the support base intact unless a customer is willing to act at the level of a whole set, which is a far larger decision. Knowing the purpose helps you predict how the rule will be applied, because it is consistently applied in the direction that preserves the base.
An indicative estate certifies 400 processors of a database product under one support agreement, and within a year deploys only 280. The team would like to stop support on the 120 idle processors. The matching service levels rule blocks this, because all 400 sit in one support set and must share a level. The realistic options are to terminate support on the entire set, losing support on the 280 still in use, or to examine whether the licenses are structured across more than one support set that could be addressed independently, or to retain the surplus as headroom for future growth. Each option is a structural decision, not a line item cancellation. The figures are indicative; what applies turns on how your support sets are actually defined.
Sometimes, but rarely in the simple way teams first imagine, and always within the constraint the rule imposes. Because a set must share a support level, partial cancellation inside a set is generally not available. The routes that do exist are structural. You can terminate support on an entire set where the whole set is genuinely surplus, accepting that nothing in it remains supported. You can examine how your licenses are grouped into support sets, since the boundaries of a set determine what can be addressed independently. And you can weigh keeping the surplus as licensed headroom against the cost of supporting it, because retained licenses with support are also a hedge against future growth. The mechanics of moving licenses around the estate are covered in license reallocation after certification.
Where an entire support set is no longer needed, terminating its support is available, but it is a decisive step. Reinstating Oracle support later typically carries back support charges and fees, so dropping support on a set should follow a clear decision that the licenses will not be needed, or that an alternative support path has been chosen for them. The related route of moving off Oracle support entirely is discussed in third party support after a ULA exit.
Because the rule operates on sets, the definition of your support sets determines your room to manoeuvre. Estates that grew through multiple purchases and agreements may have licenses spread across several sets, some of which can be addressed without touching others. Mapping the sets accurately is the first analytical step in any support reduction plan, and it often reveals more or less flexibility than expected.
The takeaway for cost planning is that support is reduced by structural decisions about whole sets, not by trimming the unused edges of a set. That reality argues for getting the certified position and the support set structure right at the point of certification, when the estate is being documented in any case, rather than discovering the constraint later. It also argues for keeping a clear view of which licenses are genuinely surplus and which are headroom, since the rule makes reversing a support decision expensive.
The matching service levels rule binds licenses into support sets that must be treated uniformly, so support after a ULA is reduced through structural decisions about whole sets rather than selective cancellation. Read it alongside support costs after ULA certification to see why the fee behaves as it does, and license reallocation after certification for moving entitlement around the estate. Because how your support sets are defined determines what you can actually do, confirm the rule's effect against your own support agreement before planning any reduction.
Matching service levels is Oracle's policy that licenses grouped under a single support agreement must carry the same support level. You generally cannot keep support on some licenses in a set while dropping it on others, which prevents selectively cancelling support on the licenses you no longer use while keeping it on the rest.
Sometimes, but the matching service levels rule constrains it. Because grouped licenses must share a support level, partial cancellation within a set is usually blocked. Reducing support typically requires terminating support on a whole set or restructuring how sets are defined, both of which need careful analysis against your support agreement.
We map how your licenses are grouped into support sets, show where the matching service levels rule binds, and find the structural moves that reduce support without breaching it.