Skip to main content
DoneThat

AI Adoption GuideITRetire

License reclamation detector

ML identifies licenses, subscriptions, and entitlements tied to a retiring asset and surfaces them for reassignment or cancellation.

IT processPlanSelectDeployProvisionSupportUpgradeReplaceRetire

By Don, DoneThat’s AI coach · updated

Overview

Retiring hardware or decommissioning a virtual machine rarely ends with powering it off. Every asset that leaves production still carries entitlements somewhere: a Microsoft 365 seat tied to a user who logged in from that laptop, an Okta application assignment inherited from a group, a Flexera discovery record that never got reconciled, or a ServiceNow configuration item with open software relationships. Those links do not disappear when the asset does. They keep billing cycles running, reserve seats other teams could use, and inflate compliance counts long after the machine is gone.

A license reclamation detector runs at retirement time to answer one question before the asset is wiped and archived: which licenses, subscriptions, and entitlements are still associated with this retiring configuration item? Machine learning cross-references identity, discovery, entitlement, and CMDB signals to produce a structured finding. Each finding names the license SKU (or subscription identifier) and the linked configuration item. When no reliable mapping exists, the finding is empty rather than guessed. The Software Asset Management team still executes reassignment, cancellation, or true-up adjustments. The detector surfaces what would otherwise require manual spreadsheet work across four or five systems.

DESCRIPTION: ML maps retiring IT assets to license SKUs, subscriptions, and entitlements so SAM teams can reclaim or reassign spend before decommission closes the window.

TAGS: license reclamation, software asset management, IT asset retirement, entitlement mapping, cost recovery, Flexera, ServiceNow, Microsoft, Okta, SAM

WORD_COUNT: 1,186

BODY:

Retiring hardware or decommissioning a virtual machine rarely ends with powering it off. Every asset that leaves production still carries entitlements somewhere: a Microsoft 365 seat tied to a user who logged in from that laptop, an Okta application assignment inherited from a group, a Flexera discovery record that never got reconciled, or a ServiceNow configuration item with open software relationships. Those links do not disappear when the asset does. They keep billing cycles running, reserve seats other teams could use, and inflate compliance counts long after the machine is gone.

A license reclamation detector runs at retirement time to answer one question before the asset is wiped and archived: which licenses, subscriptions, and entitlements are still associated with this retiring configuration item? Machine learning cross-references identity, discovery, entitlement, and CMDB signals to produce a structured finding. Each finding names the license SKU (or subscription identifier) and the linked configuration item. When no reliable mapping exists, the finding is empty rather than guessed. The Software Asset Management team still executes reassignment, cancellation, or true-up adjustments. The detector surfaces what would otherwise require manual spreadsheet work across four or five systems.

Why retirement is the last reliable reclamation window

Most organizations discover orphaned licenses months after decommission, when finance asks why headcount dropped but subscription counts did not. By then, audit trails are thin, the original owner has moved roles, and the configuration item may already be retired in the CMDB without its entitlement relationships cleaned up.

Retirement workflows create a natural checkpoint. The asset is still identifiable, its last known user and install base are recent, and change records document intent. Inserting reclamation detection at that checkpoint converts a reactive SAM exercise into a predictable cost outcome tied to retirement cost-benefit reporting. Gartner and other industry analysts have long noted that unused software represents a significant slice of enterprise software spend, often cited in the range of 20-30% of total license inventory in mature SAM programs. Retirement is where a measurable portion of that waste can be captured with the least ambiguity, because the asset's productive life is explicitly ending.

The outcome target is cost: fewer recurring charges, fewer shelfware seats, and cleaner entitlement positions before the next vendor audit.

What each finding contains

The detector's output is deliberately narrow so SAM teams can act without interpreting model prose.

Each finding lists entitlements tied to the retiring asset. For every mapped relationship, the finding cites the license SKU (or equivalent product identifier from the entitlement source) and the linked configuration item from the CMDB. That pairing is the minimum viable handoff: SKU tells SAM what to reclaim or reassign; the CI tells them where the association was observed and which retirement ticket to attach evidence to.

When the model cannot establish a confident link between the retiring asset and an entitlement record, the finding for that dimension is empty. Empty does not mean "no licenses exist." It means the available signals did not meet the confidence threshold, and a human should investigate rather than rely on automation. This design avoids the common failure mode of reclamation bots that cancel subscriptions based on stale discovery data or a single heuristic match.

Findings are grouped by source system where helpful (for example, Microsoft tenant assignments versus Okta app grants versus Flexera normalized titles), but the primary key for action remains SKU plus CI.

How mapping works across discovery, identity, and CMDB

License reclamation is fundamentally a graph problem. A laptop CI connects to a primary user through login or assignment records. That user holds group memberships in Okta or Active Directory. Groups grant application access. Applications map to SKUs in procurement or entitlement catalogs. Parallel paths run through agent-based discovery (Flexera, ServiceNow Discovery, endpoint management tools) that tie installed software titles to the same CI.

Machine learning improves on static rules in three ways. First, it weights corroborating signals: a Flexera install of Project Professional plus a Microsoft 365 group license plus recent sign-in from the retiring device scores higher than any single hit. Second, it learns organization-specific naming drift, such as when ServiceNow software models use vendor strings that do not exactly match Flexera normalization. Third, it deprioritizes known false positives, like suite bundles where one CI should not trigger reclamation of a site-wide license.

The model does not replace entitlement authority. Flexera remains the reconciliation layer for many enterprises; ServiceNow SAM Pro or ITAM modules may hold the software model and allocation records; Microsoft Admin Center and Graph APIs expose cloud subscription assignments; Okta holds federated application entitlements. The detector reads from these systems (or from exports and integrations your retirement pipeline already uses) and emits findings aligned to the retiring CI. It does not write cancellations directly, which preserves segregation of duties between automation that recommends and SAM staff who execute.

Vendor-specific considerations

Flexera. Discovery and inventory data often provide the richest install-level evidence on the retiring asset. The detector maps Flexera software titles and versions to SKU candidates, then checks whether those titles are part of a user-based subscription, a device-based license, or a concurrent license pool. Reclamation for pool licenses differs from named-user SaaS: the finding should flag pool membership so SAM does not treat a single device retirement as automatic seat recovery.

ServiceNow. The retiring object is usually a configuration item or asset record with relationships to users, locations, and software installations. ServiceNow's software model and allocation tables supply entitlement context. Findings should reference the same CI sys_id the retirement ticket uses, so SAM can attach reclamation tasks to the decommission flow without re-keying identifiers.

Microsoft. Cloud subscriptions (Microsoft 365, EMS, Intune add-ons, Power Platform, Defender suites) often bind to users, not devices. When a laptop retires, the relevant cost lever may be the user's license assignment if they no longer need the SKU, or a device-only Intune license if nothing else holds it. The detector distinguishes user-scoped versus device-scoped entitlements and surfaces the SKU with the CI that triggered the review, not an automatic unassign action.

Okta. Application assignments frequently outlive hardware. Group-based grants mean retiring one CI does not automatically imply the user loses access, but it may reveal that an application seat was provisioned solely for that asset's role. Findings call out Okta app labels and the linked CI so SAM and identity teams can decide whether to remove the app assignment, downgrade a license tier, or leave access intact for a replacement device.

Together, these sources cover the majority of reclamation candidates in a typical enterprise retirement batch. Gaps feed entitlement anomaly detection for patterns that retirement alone does not explain.

From detector output to SAM execution

Automation stops at the finding. The SAM team validates SKU and CI pairs against contract terms, true-up windows, and transfer rights. Some SKUs can move to a replacement asset through license assignment optimization. Others require cancellation requests to vendors, removal of Okta assignments, or updates in Flexera to reflect deallocation.

A practical sequence looks like this:

  1. Retirement ticket reaches the "pre-wipe" stage; the detector runs against the target CI.
  2. Findings attach to the ticket: SKU, linked CI, source system, confidence band.
  3. SAM reviews empty findings for manual research and non-empty findings for action.
  4. Reassignment or cancellation tasks are created with due dates before wipe completion.
  5. Secure wipe verification proceeds; reclamation tasks may complete in parallel but should not assume the asset still exists for re-discovery.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first