A migration timed against your certification date can add to the count or quietly erase it. The rule is direction: moves that increase counted deployment belong before the window, moves that reduce it belong after. Confirm the counting treatment first, then sequence every move around the date.
Sequence every migration by what it does to the count you can defend on the day you certify. Moves that increase counted deployment belong before the window, and moves that decrease it belong after. Repatriating a public cloud workload on premises or to OCI so it counts is a before move. Retiring, consolidating, or shifting deployment you have already certified into perpetual entitlement is an after move, because once it is certified the entitlement is yours and the running location no longer changes the count. The single question to ask of any migration is whether it adds to, subtracts from, or leaves unchanged the certified count, and that answer, read against the contract, tells you which side of the date the move belongs on.
Direction decides timing. If a move grows the count you can defend, do it before you certify. If it would shrink the count, do it after. Never let an infrastructure schedule move deployment across the certification date by accident.
Certification freezes the count on a single day. Everything deployed and countable on that day becomes perpetual entitlement, and everything that is not counted is lost. A migration is just deployment changing location, but because counting rules differ by location, the same move can be worth a large block of entitlement or nothing at all depending on when it lands. Move a workload into a cloud the contract does not count, just before certifying, and the deployment vanishes from the number. Move that same workload on premises or to OCI with enough runway, and it stays in the count. The infrastructure is identical. The difference is entirely timing and counting treatment, which is why migration plans and certification dates cannot be set independently of each other.
No, and assuming it does is the expensive error. Cloud counting is contract specific. Many ULAs require a deployment in a third party public cloud to run for 365 continuous days to count toward the baseline, so a workload moved into AWS or Azure a few months before the window may not qualify. Some agreements exclude public cloud entirely. Many are silent on a given provider, and silence is not inclusion, so a contract that does not name a cloud usually does not count deployment there. OCI is frequently counted more readily, and some agreements treat it as on premises for counting. The practical consequence is that a migration only adds to the count if the contract allows the counting and the timing satisfies any continuous run requirement, both of which have to be confirmed before the move, not discovered after it.
An insurer had moved a block of database workloads into a public cloud the year before its certification window opened. Its ULA was silent on that provider, so the deployment would not have counted, and certifying as it stood would have lost a meaningful block of entitlement. With the date eighteen months out, the insurer had time to act. It repatriated the affected workloads to OCI, which its contract counted on the same footing as on premises, well before the window, then certified with the deployment in its counted state. The entitlement was preserved. The figures are indicative, and whether OCI counted depended on that contract's cloud language.
Sequencing is a planning exercise that follows a clear order once the contract is understood.
The most damaging sequencing mistake is letting a routine infrastructure programme run on its own calendar straight through the certification window. A cloud migration scheduled for operational reasons, with no reference to the ULA clock, can move deployment into an uncounted location in the final months and the organisation certifies without it, never noticing the entitlement it lost. The defence is not to stop the migration. It is to put the migration schedule and the certification date on one timeline, test every move against the counting rules, and adjust the order so deployment is in its best counted state on the day you certify. Done that way, the same migrations that could have erased the count instead protect and even grow it.
If a migration programme is running anywhere near your certification window, map both calendars onto one timeline before the next move lands. Start with the ULA exit strategy pillar guide, then read decommissioning Oracle before certification and Support Rewards as a ULA exit sweetener for the placement and retirement decisions that sit alongside sequencing.
Migrate before certification when the move increases the deployment that counts, and after certification when the move would reduce it. Repatriating public cloud workloads on premises or to OCI so they count belongs before the window. Retiring or consolidating deployment you have already certified belongs after it. The deciding question for every move is whether it adds to, subtracts from, or leaves unchanged the count you can defend on the day you certify.
No. Cloud counting is contract specific. Many ULAs require a public cloud deployment to run for 365 continuous days to count, some exclude public cloud entirely, and many are silent on a given provider, where silence is not inclusion. OCI is often counted more readily. So a migration only counts if the contract allows it and the timing satisfies any continuous run requirement, which is why the move and the certification date have to be planned together.
The most common mistake is migrating into a cloud the ULA does not count just before certification, then certifying without the deployment. The workload moves, the count drops, and the entitlement is lost. The fix is to confirm the counting treatment first, repatriate or move to a countable location with enough runway before the window, and certify on the deployment in its counted state.
Book a confidential assessment and we will read your counting clauses, classify every planned migration by direction, and sequence the programme so your deployment is in its best counted state on the day you certify.