Software end of support: map versions and migration exposure
Software can continue running after ordinary support ends, while the updates and assistance available for it change. Research should map the exact deployed edition and entitlement before treating a lifecycle date as a shutdown, a licence expiry or a guaranteed migration purchase.
The focused deliverable is an installed-estate calendar and a migration-cohort bridge. It uses Microsoft policy information read on October 25, 2026. Every product label and Y0/Y1/Y2 date in the example is fictional; none is a claimed end date for an actual Microsoft release.
Locate policy and entitlement separately
Microsoft’s Fixed Lifecycle Policy distinguishes mainstream, extended and post-support treatment in its lifecycle table, and directs readers to product-specific lifecycle records. It also states that the policy does not cover every product. A brand name alone cannot establish the applicable servicing channel or end date.
Microsoft’s Extended Security Updates FAQ describes ESU as a limited bridge for eligible legacy products, rather than a continuation of the full original lifecycle. Locate What is the Extended Security Update program? and the applicable product and eligibility discussion. A program being offered does not prove a customer purchased or activated the correct coverage.
Collect product, edition, release/build, servicing channel, ordinary support end date, entitlement record and coverage end. Verify actual installation separately. A licence purchase or a migration plan cannot establish how many old instances remain in use at the cutoff.
Rebuild a mutually exclusive estate
Assume one thousand original installations, divided into three non-overlapping cohorts. Six hundred have no ESU and ordinary support ends at Y0 year-end. Two hundred fifty are a fictional long-service edition supported until Y2. Another 150 are legacy installations already beyond ordinary support but have verified valid ESU coverage through Y1.
| Original cohort | Installations | Stated evidence and planning date |
|---|---|---|
| Ordinary support ending Y0, no ESU | 600 | First-wave planning population |
| Long-service edition ending Y2 | 250 | Later ordinary-support date |
| Legacy with verified ESU through Y1 | 150 | Limited covered bridge, separate wave |
| Total | 1,000 | Mutually exclusive original identities |
The first-wave base is six hundred. Assume management also chooses to migrate one hundred from the 250-installation long-service cohort early. The first wave becomes seven hundred, leaving 150 ESU-covered installations for Y1 and 150 remaining long-service installations for Y2. The three planned waves sum to one thousand.
The early one hundred is a management scenario, not forced solely by a support date. If it is not actually approved, keep it separate from the base six hundred. Do not add the same one hundred again when calculating the remaining Y2 population.
Reconcile completion and old-instance retirement
Suppose two hundred of the original six hundred have a new platform deployed. That alone may not establish migration completion: old and new instances can coexist during testing. Define completion using owner-approved acceptance and evidence that the original instance no longer performs its previous production role. Any retained role is recorded separately; documentation alone does not make the migration complete.
If all two hundred satisfy that definition, the original first wave has five hundred remaining, including the one hundred voluntarily accelerated installations. If only 150 satisfy it and fifty still run in parallel, verified completion is 150 and remaining first-wave work is 550. New installation count is not the same as old-estate retirement.
Use the original installation identifier to avoid counting a parallel new instance as an additional unresolved original asset. New business deployments outside the starting estate belong in a separate addition line. The original cohort bridge measures migration of those thousand identities, not every installation the company will ever run.
Test a different entitlement boundary
Suppose a purchasing slide says ESU is available but no contract, product match or activation evidence establishes coverage for the 150 legacy installations. Their state should be entitlement unverified, not automatically ESU-covered. Do not transfer them into the six-hundred no-ESU cohort silently; retain the uncertainty and test its effect as a separate scenario.
Different editions or channels under a similar product name can have different dates. Check the actual lifecycle entry and customer eligibility rather than assign the first date found in a web search. This worksheet does not interpret all licensing rights or say that support ending terminates a right to run software.
Use the lifecycle verification sheet
| Field | Obtain | Check |
|---|---|---|
| Deployment | Dated installed-estate inventory | Actual edition/build and stable identity |
| Policy | Product-specific lifecycle record | Fixed policy applicable, correct channel |
| Entitlement | Contract and relevant activation evidence | Eligible product and covered period |
| Dependencies | Application and owner acceptance records | Migration target actually usable |
| Completion | Cutover and old-instance records | Deployment distinct from verified retirement |
| Calendar | Approved waves and dates | No duplicated accelerated cohort |
When records conflict, compare product scope, observation date, channel and whether the count represents licences or running instances. A financial procurement total cannot simply override deployment evidence. Preserve unverified installations and name the record needed to resolve them.
If customer records are unavailable, a public-market researcher may establish only a product dependency and a relevant date question. Do not invent the estate size or treat an announced end date as guaranteed supplier revenue. Customer timing, purchase terms and actual conversion remain separate inputs.
Update with product-policy revisions, entitlement changes, installed versions, approved waves and verified retirements. Keep ordinary support, ESU coverage and operational migration as distinct clocks. The conclusion should identify the cohort approaching a defined support boundary and the verified work remaining, without claiming an automatic outage or a fixed commercial benefit.
Preserve entitlement and dependency clocks
Coverage should use the period in the actual entitlement record, not an assumed calendar year. A procurement reference to Year 1, renewal or support can describe a different interval or service from the one needed for the installed edition. Match the entitlement identifier and product before marking the 150 legacy installations covered.
Migration readiness also depends on the business application and its owner acceptance. If the new operating platform is deployed but the application remains on the old instance, the original exposure has not disappeared from the defined cohort. Record partial completion rather than force a single yes/no field. The lifecycle date, customer entitlement and verified operational cutover are separate clocks; none alone establishes the amount or timing of a supplier’s future sale.
FAQ
Does end of support mean the software stops running that day?
No. The support boundary and operational runtime are different objects in this worksheet.
Is offered ESU coverage enough to mark an installation covered?
No. The product, eligibility and actual customer coverage need evidence.