Joiners, Movers, and Leavers: The ITAM Process HR Already Owns (and SAM Teams Should Be Connected To)
Every organization runs a Joiners, Movers, and Leavers (JML) process. HR owns it for payroll, access cards, and benefits. Nobody forgets to stop paying someone when they leave. Nobody forgets to update a salary when someone gets promoted. The infrastructure exists, the triggers are clear, and the accountability is well-established.
The same logic applies directly to software licenses and IT assets. A joiner needs a set of licenses and access to certain software. A mover may need a different set of licenses. A leaver should have every license reclaimed before their account is deactivated. In practice, the ITAM side of JML is the most consistently neglected lifecycle process in enterprise IT, and the financial consequences are measurable and avoidable.
What JML Means in an ITAM Context
The JML framework maps directly onto three moments in the software asset lifecycle:
| Event | What Triggers It | ITAM Action Required |
|---|---|---|
| Joiner | New employee, contractor, or third party onboarded | Provision licenses aligned to role; assign hardware if applicable; create accounts in vendor portals |
| Mover | Role change, department transfer, promotion, or location change | Review existing license assignments; deprovision entitlements no longer needed; provision new entitlements for the new role |
| Leaver | Resignation, termination, retirement, or end of contract | Revoke all software licenses; reclaim hardware; close vendor portal accounts not linked to Active Directory; reallocate or return licenses to the pool |
Each event is a licensing decision. Each decision either costs money or recovers it. The difference between an organization that runs JML well and one that does not is largely visible in the license reconciliation at renewal time.
The Financial Case: What Bad JML Costs
The numbers are not abstract. Consider a 2,000-person organization with 15% annual turnover. That is 300 leavers per year. If each leaver carries an average of one Microsoft 365 E3 or E5 license that goes unreclaimed for 60 days after departure, the annualized waste at E5 pricing ($57/user/month currently) is approximately $85,500 per year, from M365 alone, before accounting for any other software in the estate.
Scale that across a full SaaS portfolio, add Oracle Java’s per-employee pricing (where headcount directly determines license cost), and the financial exposure from poor leaver management compounds quickly.
| Vendor / Product | Why Leaver Management Matters Specifically |
|---|---|
| Microsoft 365 (E3/E5/E7) | Per-user subscription: unreclaimed seats billed monthly until removed |
| Oracle Java SE | Priced per employee organization-wide: leavers not removed inflate the license base |
| Adobe Creative Cloud | Named-user subscription: unreclaimed licenses continue billing until deprovisioned |
| Salesforce | Named-user licensing: inactive users still occupy paid seats |
| GitHub | Per-active-user billing: inactive members in organizations consume paid seats |
| Atlassian (Jira/Confluence Cloud) | Per-user pricing: unremoved users counted in the next billing cycle |
| Red Hat RHEL | Subscription per system: systems managed by leavers may go untracked post-departure |
The Three Failure Modes
1. The Leaver Gap
This is the most expensive and most common failure. An employee leaves, HR closes the payroll record, IT disables the Active Directory account, and the process stops there. The Microsoft 365 license remains assigned. The Adobe CC seat remains active. The Salesforce user remains provisioned. The Jira account remains open. Anything that does not federate to AD remains untouched indefinitely.
As noted by SAM Charter, 1,000 unreclaimed M365 E3/E5 licenses represents roughly £250,000 in recoverable annual spend. That figure multiplies when the full SaaS estate is included.
2. The Mover Accumulation Problem
When an employee moves between roles or departments, they typically receive the entitlements for the new role. The entitlements from the old role frequently stay in place. Over time, a mover who has changed roles three times carries three sets of software entitlements. This is called access creep, and it is a compliance risk as well as a cost issue. According to CrowdStrike’s 2025 Global Threat Report, 80% of cyberattacks use identity-based methods, meaning over-provisioned accounts are not just a budget problem.
3. The Joiner Delay
The inverse failure is equally costly in a different way. When onboarding is not connected to license provisioning, new employees spend their first days requesting access manually, waiting for approvals, and working around missing tools. Productivity loss in week one is hard to quantify but real. The license exists; the process to connect it to the new user does not.
What a Mature JML ITAM Process Looks Like
A mature JML process in ITAM has four characteristics: it is triggered by the HR system, not by IT helpdesk tickets; it covers the full software estate, not just AD-federated applications; it is continuous, not quarterly; and it produces auditable records.
| Maturity Level | Characteristics | Typical Outcome |
|---|---|---|
| Ad hoc | Leaver offboarding triggered by helpdesk ticket; no structured mover review; joiner licensing done manually per request | High leaver gap; frequent access creep; slow onboarding |
| Defined | HR system triggers offboarding checklist; AD deprovisioning automated; mover review done at annual True-Up | Reduced leaver gap for AD-federated apps; mover accumulation still a problem; vendor portal accounts still manual |
| Managed | HR system is the authoritative trigger for all JML events; SCIM provisioning for supported apps; quarterly review of non-federated vendor accounts | Most leaver waste eliminated; mover creep managed; some manual work remains for portal-based vendors |
| Optimized | Full integration between HR system, ITAM platform, and software estate; real-time license position updated on JML events; role-based entitlement profiles drive joiner provisioning automatically | Near-zero leaver waste; right-sized license pool; onboarding completes on day one |
The Vendor Portal Problem
The most consistently missed category in JML offboarding is vendor portal accounts. Applications that federate to Azure AD or Okta are automatically deprovisioned when the AD account is disabled. Applications that use their own login systems are not.
Common examples include Microsoft VLSC, Oracle’s Customer Support portal, Red Hat Customer Portal, Adobe Admin Console, Atlassian Access, JetBrains Toolbox, and cloud console accounts in AWS IAM or Azure that were provisioned directly rather than through Entra ID. These accounts remain active after departure. In some cases they represent access to license keys, billing accounts, and production environments.
A complete JML process maintains a registry of all vendor portal accounts per user, separate from the AD account, and includes explicit deprovisioning steps for each at offboarding.
Embedding JML in ITAM Governance
The practical integration point is the HR system. When HR is the authoritative source of truth for employment status, and JML events flow from the HR system into ITAM tooling, the process becomes continuous rather than periodic.
The data flows that matter are: new hire records (joiner trigger), role change records (mover trigger), and termination records (leaver trigger). Each feeds a workflow that updates the license position in real time, flags licenses for reclaim, and generates an audit trail for the next renewal or compliance review.
This is where the gap between identity governance tools and ITAM platforms typically sits. Identity tools like Okta and Microsoft Entra ID Governance handle the access provisioning side well. What they do not do is translate those events into a license position: how many M365 E5 seats are now available for reallocation, whether the reclaimed Oracle Java headcount changes the renewal obligation, or whether a department’s Salesforce seat pool is now over-provisioned relative to active users.
Licenseware connects to the Microsoft Graph API to pull live M365 assignment and usage data, giving ITAM teams an accurate, continuously updated view of which licenses are actively consumed versus assigned to inactive or departed users. That data feeds directly into the license position, making the financial impact of every JML event visible without waiting for the quarterly reconciliation cycle.
The fuller picture of how Licenseware fits into a JML workflow spans three components working together:
| Licenseware Component | Role in JML | What It Provides |
|---|---|---|
| License and Contract Management (LCM) | Central record of entitlements and allocations | Tracks which licenses are purchased, how many are allocated to which users or departments, and how many are available in the pool. When a leaver is processed, LCM is the system that marks the license as reclaimed and available for reallocation. When a joiner is provisioned, LCM confirms the allocation against available entitlements before the license is assigned. |
| Licenseware Collector (LC) | Ground-truth infrastructure and software inventory | Continuously scans the environment to detect what is actually installed and running across physical servers, VMs, and endpoints. When a mover changes roles and their old workstation is reassigned, LC detects the software installed on that device and flags any applications that are no longer aligned to the new user’s role profile. It also catches shadow installations that never went through the formal provisioning process. |
| Software Inventory Management (SIM) | Reconciliation layer between entitlements and deployments | Compares what LCM says is allocated against what LC says is installed and active. In a JML context, SIM surfaces the gaps: licenses assigned in LCM that LC cannot find active on any device (leaver waste), installations detected by LC that have no corresponding LCM allocation (unauthorized or orphaned deployments), and users whose installed software profile does not match their current role (mover accumulation). |
The loop that makes this operationally useful is: LCM holds the allocation record, LC holds the deployment reality, and SIM continuously reconciles the two. When HR triggers a leaver event, LCM updates the allocation, LC confirms the software is no longer running on the departing user’s devices, and SIM closes the gap in the license position. When they do not match, that is the finding that needs action, whether it is a deprovisioning step that was missed, a device that was not wiped, or a vendor portal account that sits outside the AD-federated estate and needs manual closure.
The Renewal Conversation Changes When JML Is Running
The most direct argument for investing in JML ITAM governance is what it does to the renewal conversation. Organizations that reconcile their license position against current headcount and active users before entering a renewal negotiation consistently identify recoverable spend that they can use as negotiation leverage or direct cost reduction.
The calculation is simple. Reclaimed leaver licenses reduce the renewal quantity. Right-sized mover entitlements reduce the E5 count in favor of E3 where appropriate. Clean joiner records mean the True-Up reflects actual growth, not a mix of real growth and provisioning backlog.
The vendors do not run this analysis for you. They present a renewal based on what you currently have provisioned. Your job is to show up with a number that reflects what you actually need.
