The unlimited years feel like freedom from license management. They are the opposite: the period in which the exit count is either built, deployment by deployment, or lost to fog. This session is the operations manual: the always on register, the quarterly snapshot, the provisioning gate, corporate events processed the month they happen, cloud moves made with the certification clause in hand, and the annual dry run that makes year three boring.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
A taught session with three knowledge checks: the colleague who thinks tracking is wasted effort under unlimited, the mid term divestiture and what it does to the exit count, and the year two dry run that finds 60 percent register coverage with twelve months to fix it. It closes with the one page exit readiness scorecard a well run ULA updates annually.
The full narration of this session, section by section, for reading and reference.
Welcome back, session thirteen of forty. The entry paper from last session is signed. The unlimited period has begun. And here is the strange psychological fact at the center of today: this is the most dangerous stretch of the whole agreement, precisely because it feels the safest. Deployment is free, compliance anxiety evaporates, and the natural response of every organization is to stop paying attention. Which is exactly how session eleven's renewal machine gets built, one untracked quarter at a time. So today is the operations session: the register, the quarterly rhythm, the corporate events that hit mid term, the cloud migration handled deliberately, and the annual rehearsal that makes the exit boring. None of it is glamorous, all of it is cheap, and together it decides which of session eleven's three exits your company gets. The term is not a holiday from counting. The term is the exit, being built or being lost. Let's build it.
Five takeaways. One, you'll run the rhythm, the operating cadence of a well managed ULA, five habits costing a few days a quarter. Two, you'll keep the register, the deployment log that the exit count will eventually stand on, and you'll know exactly what each row must capture. Three, you'll handle the events, acquisitions, divestitures, reorganizations, at event time, when they cost an email, instead of at exit, when they cost leverage. Four, you'll migrate with the exit in mind, because the cloud question inside a ULA is really a certification question wearing infrastructure clothing. And five, you'll rehearse, the annual dry run, a mock certification that finds the gaps while they're still free to fix. One framing thought: everything today is module one's discipline, aimed at a date. You already know how to inventory, evidence, and file. What the ULA adds is a deadline with millions attached, which turns good habits from virtue into strategy.
Four numbers. Day one, when exit preparation starts. Not year three, not when the rep starts calling, the week the ULA is signed. The register opens with the term, because every quarter it doesn't exist is a quarter of deployments that will someday need reconstructing from memory. Thirty six, the months of deployment the certification count must reconstruct. Think about reconstructing anything in your company from three years ago: who deployed what, where, on which hardware, since when. Records beat memory at that range every single time, and the gap between them is measured in donated licenses. Twenty two percent, the annuity, billing every year of the term, deployment or no deployment, tracking or no tracking. The meter that never pauses, mentioned here as a reminder of what's already being paid while the fog forms. And one, the count date. Everything in this session, every register row, every quarterly snapshot, every event file, exists to make one afternoon in year three completely, gloriously boring. Session eleven showed you what that afternoon costs when it's exciting. Fog is manufactured during the term, not at the end. Today is the anti fog session.
The operating rhythm, five habits. First, the register, always on: every deployment of a listed product logged as it happens, what, where, how big, since when. Not quarterly, not eventually, as it happens, because the provisioning moment is when the information is free. Second, the quarterly snapshot: a scripted inventory of the estate each quarter, reconciled against the register. This is the drift detector, when the scripts see something the register missed, you learn it within weeks, while the deploying team still remembers what they did. Third, the provisioning gate, session eleven's one page on one wall: the product list checked before any Oracle software deploys, which is the entire defense against off list creep, and it costs a checkbox. Fourth, the cloud log: every cloud deployment tagged and dated, mapped against the certification language you negotiated, or didn't, at entry. We'll spend a whole section there. And fifth, the annual dry run, the mock certification, rehearsed once a year so the real one is the fourth performance, not the first. Total cost: a few days per quarter. Total value: session eleven's spread between the best exit and the worst, which was millions. Now, the register itself, because the details matter.
The ULA register, five fields per deployment, and each one answers a question the exit will ask. Product and metric: which listed program, counted under session two's rules, processor counts with core factors, because the certification is per product, in the contract's metric, and a count in the wrong unit is a dispute waiting politely. Host and environment: the server or cloud instance, its cores, its virtualization setup, module one's counting evidence, captured at deployment time when it's a copy paste instead of an investigation. Entity and location: which company in the customer definition deployed it, in which country, because a deployment outside the definitions isn't entitlement, it's a finding, and the register should know the difference before Oracle does. Dates: deployed since, decommissioned when, because the test at exit is installed and running on the count date, and dates are what prove it. And evidence: the install records, feature usage output, screenshots, scan results, whatever documents that this deployment is real. The declaration is only as strong as what stands behind it. One row per deployment, kept current. It's module one's evidence file with a deadline attached, and the deadline is coming whether the register exists or not. Which brings us to a colleague with an objection. Knowledge check one.
Knowledge check one. A colleague argues: we have a ULA, deployment is unlimited, so tracking deployments is wasted effort until the final year. Right? A, right, unlimited means the numbers cannot matter until certification. B, right, as long as the final year count is done carefully. C, wrong: the exit count is built from term records, and tracking also catches off list deployment while it's still fixable. Or D, wrong, because Oracle requires quarterly reports during a ULA. Pause here, and ask: what does year three know that year one forgot?
The answer is C. The colleague has confused compliance with strategy, and it's the signature confusion of the ULA era. They're right that deployments of listed products can't be non compliant on quantity during the term, that's literally the product being paid for. But certification reconstructs three years of deployment, and a count built in year three from memory, old tickets, and the recollections of people who've since changed jobs shrinks under its own uncertainty. That's precisely how session eleven's sloppy exit certified half its true estate: the deployments happened, the proof didn't survive. And tracking catches the two things unlimited never covered, off list products and out of definition entities, while they're cheap to fix, a mid term correction instead of an exit finding. B fails on physics: careful counting in year three cannot recover evidence that was never captured. Servers get decommissioned, cloud instances vanish, and each one takes its proof with it. D invents an obligation, there is no quarterly reporting to Oracle; the register serves your exit, not their files. Here's the sentence for the colleague: a ULA without a register is a prepaid asset nobody is keeping the receipt for. Now, the org chart starts moving.
Corporate events, three kinds, one rule. An acquisition closes: check session twelve's inclusion language the same week. If acquisitions join automatically, the new estate goes into the register and starts growing your exit count, congratulations, that sentence at entry is now paying. If they don't, the acquired estate stays tracked separately under its own contracts, and, this is the critical discipline, nothing merges until licensing signs off, because merging a non covered estate into ULA infrastructure quietly converts integration work into findings. A divestiture signs: the leaving entity exits the customer definition at close. The transition rights negotiated at entry govern the handover, and, the piece exit planning must catch, its deployments leave your future certification count, so the exit forecast gets rerun that month, not discovered short at the count. A reorganization lands: new legal entity names checked against the customer definition, every time, because entities drift out of definitions silently, and a definition that named the old structure may not cover the new one. And the rule that binds all three: the licensing file for a corporate event is built the month it happens. At event time it's an email and a register update. At exit, it's archaeology, conducted under time pressure, with Oracle watching. Let's test the divestiture. Knowledge check two.
Knowledge check two. Mid term, your company divests a division that runs twenty five processors of listed products. What happens to those deployments? A, nothing, they were deployed under the ULA, so they stay covered and count at exit. B, they leave the definition at close: transition rights govern the interim, and they exit your future certification count. C, they count at exit as long as the servers stay physically in your data center. Or D, the ULA fee is reduced proportionally. Pause here. Who is inside the definition, the day after close?
The answer is B, session eight's divestiture lesson, now running inside an unlimited grant. The divested division leaves the customer definition at close, its use of listed products stops being covered that day, and, the part that stings at exit if nobody caught it mid term, its twenty five processors leave your certification forecast, because you cannot certify deployments that no longer belong to a covered entity. The transition rights from session twelve's markup govern the handover window; without them, the buyer needs its own licenses at close, shopping at Oracle's leverage, mid transaction, which is the exact scenario the entry sentence was bought to prevent. A believes deployment history creates permanent rights, but the definition, not history, decides coverage, at every moment including the count date. C, the servers are still in our data center, is the hardware fallacy, making its fifth appearance in this course, and its value remains exactly zero, location has never once been the test. And D misreads the instrument entirely: ULA fees are fixed, nothing prorates, no event reduces them, which is itself worth knowing before you sign one. The operational move: divestitures get a licensing file the week they're announced, and the exit forecast reruns the same month. Now, the cloud, deliberately.
The cloud during the term, four disciplines, and the stakes come straight from session eleven's modern classic. First, know your counting language. Session twelve's cloud sentence, or its absence, is the single fact that shapes migration strategy inside a ULA. Reread the certification clause before any major move, not from memory, the actual words, because the difference between counts at exit and doesn't is the difference between migrating freely and migrating your entitlement away. Second, tag everything. Every cloud deployment logged with environment, instance type, core count, and dates. If cloud counts at exit, these tags are the evidence that claims it. If it doesn't, the same tags are your risk map, showing exactly what the count will miss. Either way, untagged is unknown, and unknown resolves against you. Third, sequence deliberately. Without cloud counting language, a workload that migrates before the count date leaves the certification. Which means timing matters strategically: a major migration scheduled for month thirty four might rationally wait until month thirty seven, after certification, preserving the on premises count while the licenses convert. That's not gaming anything; it's reading your own contract and scheduling accordingly. And fourth, keep the crossing records: for every workload that moves, what ran on premises, when it moved, what replaced it. The exit narrative has to survive scrutiny in both environments. The traps, next, and then the rehearsal.
The five mid term traps, and here's the uncomfortable pattern: every failed certification you'll ever hear about traces back to one of these, and none of them is a year three event. Trap one, the fog. No register, no snapshots, three years of deployment nobody can prove. The renewal machine's primary fuel, manufactured one comfortable quarter at a time. Trap two, off list creep. Products outside the list, deployed by teams who never saw it, accumulating quietly at unlimited speed, in an estate that's stopped checking anything. The provisioning gate exists precisely because this trap is otherwise inevitable. Trap three, shadow cloud. Migration proceeding at business speed, untagged, against certification language nobody has reread since signing. Entitlement evaporating by quarter, invisibly, until the count makes it visible all at once. Trap four, the silent merge. An acquired estate absorbed into ULA infrastructure because integration was urgent and the inclusion clause was unread. Findings, wearing the costume of synergy. And trap five, the vanished evidence. Servers decommissioned, staff departed, cloud instances terminated, deployments that genuinely happened but can no longer be proven, which at certification is the same as never having happened. Five traps, all preventable, all cheap to prevent, all expensive to discover. The prevention mechanism is one annual ritual, and it's the next slide.
The annual dry run, a full mock certification, once a year, four steps. Step one, run the real count. Execute the certification process exactly as your clause describes it: the scripted inventory across the estate, the register reconciliation, totals per product in the contract's metric. Not an approximation of the process, the process, because the rehearsal only predicts the performance if it's performed the same way. Step two, compare and reconcile. Inventory against register, line by line. Every mismatch is a future dispute, and today each one resolves for free: a missed register entry gets evidenced from the live system in minutes, a stale entry gets closed with a decommission date. Step three, sweep the edges, the traps checked annually: off list products, out of definition entities, untagged cloud, unrecorded decommissions. Fifteen minutes per trap, once a year. And step four, report the number: a one page exit readiness note to the ULA owner, here's what we'd certify if the count were tomorrow, and here are the gaps to close this year. That one pager, updated annually, is how the exit stops being an event and becomes a trend line. And when a dry run fails, that's not bad news, that's the entire point, as the next question shows. Knowledge check three.
Knowledge check three. The year two dry run finds the register covers only sixty percent of what the inventory scripts actually see. Twelve months remain on the term. What now? A, nothing, the scripts will find everything again at the real certification. B, reconcile now: rebuild the missing evidence while systems and people still exist, and fix the process that let forty percent slip. C, plan to renew the ULA, since the records are incomplete. Or D, certify early, based on the sixty percent that is documented. Pause here. What can year two fix that year three cannot?
The answer is B, and notice the reframe: this dry run didn't fail, it succeeded, it surfaced a forty percent evidence gap at the only time the gap is fully repairable. Twelve months out, the machines are running, the deploying teams are reachable, and every undocumented deployment can be evidenced from the live system in an afternoon, a scan, a screenshot, a register row. At the real count, some of those systems will be gone, some people will have left, and every row that can't be rebuilt becomes entitlement donated back to Oracle. So: reconcile the gap now, then, just as important, fix the intake process that created it, find where deployments were happening without registration and close that path, or next year's dry run finds the same hole, refilled. A confuses detection with evidence. The scripts will indeed see what's running at exit, but a declaration built on bare scan output, without the register's who, where, since when, and under which entity, invites exactly the dispute the records exist to prevent. C surrenders a winnable exit to the renewal machine a full year early, fog is the machine's fuel, and this fog is actively clearing. And D isn't how certification works, the count happens at term end, and certifying only the documented fraction donates the rest. Rehearsals exist so the performance is boring. Let them fail loudly, and early.
The exit readiness scorecard, five measures, one page, updated annually, here shown at the end of year two. Register coverage: ready looks like above ninety five percent of what the scripts see; this estate sits at sixty, with reconciliation underway, knowledge check three, in progress, exactly as prescribed. Cloud tagging: every instance tagged and mapped to the counting language; here, tagged from the third quarter of year one onward, meaning two early quarters need backfilling from provisioning records, noted, owned, scheduled. Off list findings: ready is zero with the gate holding; the dry run found two, both remediated, and the gate got a reminder. Event files: one per corporate event, built the same month; the divestiture file is complete and the exit forecast already reflects the departed processors, no year three surprise waiting. And the exit forecast itself: a projected count, an owner with a name, a date in the calendar, one hundred sixty eight processors and rising, owner assigned. Look at the shape of this scorecard: not perfect, honestly imperfect, improving on schedule, with a year of runway left. That's what ready actually looks like in the wild. A ULA owner who can produce this page has, quietly, already decided how the exit ends. That's the session.
Session thirteen in three sentences. One, the unlimited term is not a holiday from counting, it is the period in which the exit count is either built, deployment by deployment, or lost to fog, and fog is always manufactured mid term, never at the end. Two, the rhythm, the register, the quarterly snapshot, the provisioning gate, the cloud log, and the annual dry run, costs a few days per quarter and decides the millions between session eleven's best exit and its worst. Three, corporate events and cloud moves get processed the month they happen, against the definitions and counting language written at entry, because the same work at exit costs leverage instead of email. Next session, the exit itself: the twelve month runway, the counting rules on the count date, Oracle's exit playbook move by move, the declaration letter, and the five mistakes that convert a winnable certification into a renewal. Everything the register has been quietly building gets spent in one afternoon. Bring the records. See you in session fourteen.
Homework, about an hour, and it works with or without a ULA, because the habits transfer. One, open the register. Pick one Oracle product and start a deployment register for it this week, today's five field table is the template. The point is the habit; the ULA version is just the habit with stakes. Two, check the gate. Could a team in your company deploy an Oracle product tomorrow without anyone checking a list? Walk the actual provisioning path and answer honestly. If yes, you've found the finding, and it costs a checkbox to fix. Three, reread the cloud language. If a ULA exists in your estate: the certification clause, against the actual migration plans, summarized on one page for the ULA owner. For many companies this single page is the most valuable hour in the module. Four, file the last event. Take your most recent acquisition, divestiture, or reorganization and build its licensing file now, entities, contracts, deployments, while the people who did it still remember. And five, run a mini dry run: one product, one hour, inventory it, compare against whatever records exist, and write down the coverage percentage. That number is your baseline, and baselines, as this session argued, are how exits get decided early. See you in session fourteen.
Five reads, all free on redress compliance dot com. First, conducting internal Oracle license audits, the dry run methodology in full detail, scripts, reconciliation, reporting, the operational heart of this session. Second, the Oracle ULA negotiation playbook, the term management chapter of the module's standing reference. Third, how to check your Oracle license position, the inventory techniques behind the quarterly snapshot, three different ways. Fourth, Oracle ULA renewal negotiation tactics, what all these records are ultimately protecting you from, worth reading before next session's exit playbook, because the two mesh. And fifth, Oracle licensing in M&A due diligence, the event file discipline at full transaction depth, for the week your company announces something. That's session thirteen. A register that opens on day one, a rhythm that costs days per quarter, events filed the month they happen, cloud moves made with the clause in hand, and a rehearsal that fails early so the performance can be boring. Next session, the performance itself: certification. See you there.