Travel and hospitality run Oracle behind reservation, property, and loyalty systems across hundreds of locations. Seasonality, property structures, and franchise entities all shape what you can certify, and each turns on contract language that rewards planning before exit.
Hospitality estates are seasonal, distributed across properties, and split between owned, managed, and franchised entities. Seasonality affects whether cloud workloads count, the property footprint hides deployments that add to the number, and the franchise structure decides what sits inside your customer definition. Certify on a baseline that reconciles every property to an entity and plans the count around the season.
Travel and hospitality demand swings hard between peak and off season, and the technology estate flexes with it. Reservation capacity, booking platforms, and analytics scale up for the busy period and down afterwards, often in public cloud. This collides directly with cloud counting rules, which are contract specific and frequently require deployments in AWS or Azure to run for 365 continuous days before they count toward the certification baseline. A workload that only ran at full size through peak season may have delivered real value yet still fail the continuous test, so it does not count.
The consequence is that the certified count for a hospitality business depends on timing as much as scale. What runs continuously through the qualifying window counts. What scales to zero between seasons may not. This is manageable, but only with planning: deciding which workloads need to stay running to count, and which can be repatriated on premises or moved to OCI before exit where the contract would not credit public cloud at all. Left to chance, a large seasonal cloud estate can shrink dramatically at certification.
In hospitality the season writes part of the count. Plan what runs through the qualifying window rather than measuring whatever happens to be live on the certification date.
This is the question that decides scope in hospitality, and the answer is set entirely by your customer definition. A hotel group typically operates a mix of owned, managed, and franchised properties, and these often sit in different legal entities. The unlimited right reaches the entities your ULA names and no further. Owned and managed properties inside those entities are covered. Franchised properties, which are frequently separate businesses operating under your brand, may sit outside the definition altogether. Oracle running at an out of scope franchise cannot be certified into your count, and it can become a remediation demand if it is treated as covered when it is not.
The table below shows how the same brand footprint divides at certification, with the treatment depending on your specific definition.
| Property type | Typical entity position | Certification effect |
|---|---|---|
| Owned | Inside the customer definition | Deployments generally countable |
| Managed | Often inside, depends on the entity | Countable if the entity is named |
| Franchised | Often a separate entity outside scope | Usually not countable, possible remediation risk |
Because the split is contract specific, every property has to be reconciled to a legal entity and tested against the definition before you certify. Treating a franchise estate as uniformly in scope is one of the most expensive assumptions a hospitality business can make at exit.
Hospitality runs Oracle across reservation, property management, point of sale, and loyalty systems, and not all of it is licensed the same way. Some products count on processors with core factors, while others count on Named User Plus, where the measure is named users and devices rather than cores. In a hospitality estate, Named User Plus counts can include reservation agents, front desk staff, and the devices behind them, which is a very different counting exercise from processors. Whether processor or user metrics apply is set by your contract for each product, so the right basis must be confirmed product by product. Getting the metric wrong undercounts in one direction or overstates exposure in the other.
For a travel or hospitality business the first move is a baseline that reconciles every property to a legal entity, confirms the licensing metric for each product, and plans the seasonal cloud workloads against the certification window. Two companion playbooks sit alongside this one: Oracle ULA certification for manufacturing and Oracle ULA certification for media. The full method sits in our Oracle ULA certification guide.
Demand swings mean cloud and reservation capacity scales up for peak season and down afterwards. Because cloud counting is contract specific and often requires continuous running, a workload that only ran at peak may not count. The certified count depends on what runs through the qualifying window, so the timing of certification against the season matters.
It depends entirely on your customer definition. Owned and managed properties inside the named entities are covered, but franchised properties often sit in separate legal entities outside scope. Oracle running at an out of scope franchise cannot be certified and can become a remediation risk. Reconcile every property to an entity before certifying.
Where a product is licensed on Named User Plus rather than processors, the count is of named users and devices, which in hospitality can include reservation and front desk agents. Whether processor or user metrics apply is set by your contract for each product, so the right basis has to be confirmed product by product before counting.
We map each property to its entity, confirm the metric for every product, and plan the seasonal count around your window. Book a confidential assessment.