Oracle Software Support & Maintenance Contract Renewal – FAQ's

There are a couple of things to check:

• Compare it to the previous renewal, providing this paperwork was correct. The price will normally increase due to RPI (typically 4%).
• Review the original ordering document plus any amendments; you should be able to understand the link between ordered items and support lines: bear in mind that the renewal does not show your entitlement: the original ordering documentation is the binding contractual agreement between you and Oracle.

If there is something wrong with the support contract, revert to Oracle pointing out the issue and ask for a new renewal. Read our blog post for more information.

Yes – this is known as ‘co-terming’: aligning the start and end date of your support periods for multiple contracts. This process benefits you and Oracle, and does NOT reduce future flexibility with respect to de-supporting particular supported products (see below).
Some things to watch out for:

• It may not be possible to co-term if your contracts are in different entity names even though you may have one central finance department.
• During this process be aware that the pricing may need adjustment for the time left before completion of consolidation.
• When you co-term (as defined above) the Customer Support Identifier (CSI) number will remain the same, but the contract number will differ. It is important to check that everything has been included in the renewal as unintended mistakes can happen.
• Although the products are all on one renewal, it does not mean that any of the original T’s & C’s will have changed, this is indicated by the CSI number remaining with the product. To be clear: you still retain full flexibility to terminate licenses and reduce licenses but typically, this means at a CSI-level (i.e. a whole CSI). The remaining CSIs will be unaffected.

Yes – but beware.

• If the product has its own unique CSI number and is the only product with this CSI number, then there should be no issue.
• If there are several products with the same CSI number and only one is not being used, then we would advise not to cancel that product as Oracle will reprice the contract and you will end up paying the same money + RPI for less licenses.
• Where you are cancelling multiple products within a CSI, it is still probably the case that you won’t save money and even if you do, the effective price for the support for the remaining product will be very high, if not list price.

This is a common question. It may be possible, but you must carry out the following exercise:

• Review usage thoroughly.
• Determine the optimal ‘fit’ of license to usage (with consideration to your contract structure).
• Identify what licenses are not being used.
• Review old products and metrics.
• Simplify licenses;
  • Terminate least cost-effective licenses within the context of your CSIs and contract structure.
  • Migrating old products and metrics to equivalent current products and metrics. While this may not save you any money with Oracle it will make measuring and monitoring the usage easier.
  • Consider co-terming contracts. While it will not save you money with Oracle it has the potential to save some administration costs as there will be fewer support contracts to renew.

The above highlights areas that could potentially reduce support fees. This is not a quick and easy exercise to complete. Actions such as migrations and co-terming will need Oracle approvals and paperwork to be agreed.

If you have a strategy to continue to use Oracle for the next few years, then it may be worth investigating ways in which you could pay the support to Oracle on the basis of an upfront commitment. This can lead to Oracle freezing the annual uplift on your support renewal: this is a common agreement.

On-Premises licenses (now only available as 1-year term and only for limited products). You no longer have the licenses and cannot use the product; software must be de-installed before the expiry.

Note, these are subscriptions to allow use of a service with access rights granted by quantities and metrics. You will likely renegotiate a new deal unless you are no longer using those products and have migrated all necessary data off the platform.

No. There will be a clause in the original paperwork that indicates if you go over your entitlement then an expansion is required to be purchased and it can only increase. This is why the expansion clause and pricing is placed in the original ordering documentation; you’ll note that expansions have the same CSI number as the original order, again linking any such original orders and expansions together: attempting to cancel any expansion will result in a repricing of the support associated with the original order.

The quantity is shown as 1 until the ULA or Pool of Funds has been declared. This is because it is not known by Oracle how much has been declared or drawn down. Once a declaration has been made and ‘accepted’ then the renewal will show the quantity that has been declared. It is advisable to keep your signed declaration certificate so you can check quantities.

Oracle Unlimited License Agreement (ULA)

As with the ULA you need to declare how many licenses have been deployed and, unlike a ULA, drawn down from the pool of funds. Ideally you will have used up all the Pool of Funds such that the balance is as close to zero as possible: you lose whatever credit is left in the pot (i.e. not drawn-down).

The next support renewal will no longer show a quantity of 1 but the quantities that have been declared.

It depends on the ‘product family’. Oracle requires that a product family e.g. Database and options must have ‘Matching Service Levels’. This means all the Database and option licenses in your estate must have Software Update License & Support (SULS) paid (supported) or they all must be unsupported. This is to prevent customers having, say, 1 supported Processor of Database Enterprise Edition by which they could access support for their entire estate, which may be much larger.