Before you start
Read access to your management platform or a way to query devices directly.
Agree the scope and recovery plan with the service owner. Adapt the exercise to your environment.
Set the scope and build an evidence table
Choose a manageable group of devices and record the inventory source and collection time. Create columns for device identifier, reported product, edition, version, build, servicing channel, last-seen time, business owner and application dependency. Add separate columns for the vendor source URL, support date and date checked. Unknown values should remain visibly unknown until verified. Do not start by assigning one date to every device labelled Windows.
Collect the product identity from the estate
Use read-only reports from the approved management platform or an authorised device query. Keep the product strings as evidence rather than replacing them with a friendly label. Check a small sample against the actual devices, including anything with an unusual edition or an old last-seen date. A disconnected device or stale agent report may need investigation before it can support a budget or migration decision.
Group by the attributes that determine support
Separate product, edition, release and servicing channel. Do not infer that Enterprise LTSC and IoT Enterprise LTSC have the same lifecycle because their names or release years look similar. Keep unresolved identities in an exception group. Microsoft’s release information distinguishes these product variants; use the exact product’s lifecycle record to resolve the support question instead of borrowing a date from a neighbouring row.
Attach current vendor evidence
Open the relevant Microsoft release-information page and follow the lifecycle details for the exact product. Record the applicable milestone, its date, the URL and when you checked it. Keep ordinary support and any separately evidenced extended-update entitlement distinct. A device’s age, build number or continued receipt of an update is not sufficient evidence of contractual support coverage. Escalate unclear entitlements to the people responsible for licensing.
Inspect the reason a device cannot move
For each affected group, ask its owner about application compatibility, hardware requirements, supplier constraints and permitted downtime. Record evidence for the blocker and who can resolve it. “Legacy application” is a useful starting label but not an action: identify the application, supported target and outstanding test or vendor response. Keep the technical support deadline separate from the organisation’s proposed completion date.
Produce a decision list with owners
Summarise the groups as upgrade candidates, replacement candidates and unresolved exceptions. Attach counts, confidence in the inventory and the business owner. For an exception, record the decision required, the person authorised to make it and a review date. Do not describe isolation or another compensating measure as restoring vendor support. Ask the responsible teams to assess the actual options and their limitations.
Check the report before using it for funding
Reconcile the grouped count with the original inventory and explain exclusions and duplicates. Have a colleague spot-check a normal group and an exception against the linked vendor evidence. Record the report date and arrange a recheck before a material commitment or after a product change. Keep the evidence table with the decision so that somebody can trace where each deadline came from.
What you should leave with
An evidence-backed inventory with per-product support milestones, unresolved identities, migration blockers and decision owners. Every date should be traceable to a current vendor record for the correct product.