A merger can leave one group holding two Oracle ULAs with different scope, terms, and certification dates. They do not merge by themselves. Mapping each deployment to the agreement that covers it, then sequencing the exits, is what captures the full value without stranding licenses between them.
A merger or acquisition can leave a single group holding two separate ULAs, each with its own customer definition, product list, term, and certification date. They do not combine automatically just because the entities now share a parent. Each agreement remains a distinct contract that has to be certified or renewed on its own terms, and a given deployment can usually be counted only under the agreement whose scope it falls within. The interaction between the two is governed entirely by their separate contract language, which means the first task is not counting, it is working out which deployment belongs to which agreement.
Two ULAs are two contracts, not one larger one. Treat them as a single estate and you will double count some deployments and strand others. Map first, then certify each on its own terms.
The risk is that overlapping product lists and customer definitions create ambiguity about where a deployment counts. A database running in an entity that arguably falls under either agreement can be claimed by neither cleanly, or counted twice, and an audit after the fact can challenge whichever interpretation looks weakest. The opportunity is that two agreements can together cover more products and more entities than either alone, and with careful mapping there can be more defensible deployment to certify across the pair than a casual reading would suggest. The same overlap that creates exposure also creates room to maximize, and which one you get depends on whether the mapping was done deliberately.
Not by default. Because each ULA is a separate contract, the baseline position is that each is certified on its own against its own scope and timeline. Oracle may propose consolidating the two into a single new agreement, and that can sound tidy, but it is a negotiation rather than a mechanical merge and the terms of a consolidated deal can favour the vendor. Consolidation may suit some groups and disadvantage others, depending on the overlap, the relative size of the two estates, and the timelines. The decision to consolidate, to certify separately, or to sequence the exits is a commercial choice that should be made on analysis of both contracts, not on the convenience of a single combined letter.
After acquiring a competitor, a group found it held two database ULAs with overlapping product lists and certification dates roughly a year apart. Treated as one estate, several deployments in shared data centers were ambiguous, and an early plan risked counting them twice. By mapping each deployment to the agreement whose customer definition and territory actually covered it, the group assigned every workload to one ULA, certified the agreement expiring first against its own scope, and planned the second around what remained. The result counted each deployment once, under the right contract, with no stranded licenses. Figures are indicative and the right sequence depends on the two specific agreements.
Sequencing is the heart of the work, and it follows a clear order.
Two colliding ULAs are the most demanding case of the scope questions that every certification raises. Customer definition decides which entity sits under which agreement, territory decides where each right applies, and corporate change is usually the reason there are two agreements in the first place. The discipline is the same as for a single ULA, just doubled: read both contracts, map deployment to entity, country, and product, and certify on a complete picture rather than an assumption. Done early, two ULAs are a larger maximization opportunity. Done late, they are two remediations at once.
If a merger or acquisition has left your group with more than one Oracle ULA, map both contracts and both estates now, well ahead of either certification date. Start with the ULA exit strategy pillar guide, then read M&A and your Oracle ULA and territory restrictions and global estates.
A merger or acquisition can leave one group holding two separate ULAs, each with its own customer definition, product list, term, and certification date. They do not merge automatically. Each agreement still has to be certified or renewed on its own terms, and a deployment can usually only be counted under the agreement whose scope it falls within. The interaction between the two is governed by their separate contract language.
Not by default. Two ULAs are two contracts, so unless Oracle agrees to consolidate them, each is certified separately against its own scope and timeline. Oracle may propose merging them into a single new agreement, which is a negotiation rather than a mechanical step and can favour the vendor. Whether to consolidate, certify separately, or sequence the exits depends on the terms, the overlap, and the timelines involved.
Start by mapping each deployment to the ULA that actually covers it, then look at the two certification dates and product overlaps. The aim is to count every deployment once, under the right agreement, without leaving anything stranded between the two. Where timelines differ, the earlier expiry usually sets the planning horizon. The correct sequence is specific to the two contracts and is best decided well before either window opens.
Book a confidential assessment and we will map both agreements and both estates, assign every deployment to the right ULA, and sequence the certifications so you count each license once.