User management tools do not offboard work.
Deactivation, license reclaim and SCIM deprovisioning close the account. They do not touch anything the account owns. In Jira that second layer, the issues, filters, dashboards and leads a person leaves behind, stays exactly where it was, and it fails quietly, months later, on someone else's sprint.
Deactivation reassigns nothing. The leaver stays assignee, owner and lead on everything they touched.
Jira does not warn you. There is no built-in step that lists what a departing user still owns.
The bill comes later. Broken boards, misrouted issues and unanswerable audit questions surface long after the goodbye card.
What actually happens when you deactivate a Jira user
If you searched for this, you probably suspect the answer already: less than you hoped.
Deactivating an Atlassian account does two things well. The person can no longer sign in, and the seat stops counting against your license. Both matter, and your user management process handles both correctly.
Here is what deactivation does not do. It does not reassign a single issue. Every open issue stays assigned to the deactivated account. Every saved filter they created keeps them as owner, so nobody else can edit it. Every dashboard they built keeps them as owner. Every component and project where they were lead still lists them as lead. Their group memberships stay attached to the dormant account until someone deletes it, and then the record of what access they had is gone too.
Removing or deleting the account outright is worse, not better: their issues remain, now attributed to an anonymized former user, which makes the work even harder to inventory afterward.
None of this is a bug. Jira preserves history deliberately, and account administration was never designed to make decisions about work. Deciding who takes over a backlog is a judgment call about people and projects. It needs a different layer.
Two layers, two jobs
Offboarding a person from Jira is really two separate jobs. Most organizations have tooling for exactly one of them.
| The account layer | The ownership layer | |
|---|---|---|
| What it is | Identity, sign-in, license seat, sessions, provisioning and deprovisioning | Open issues, saved filters, dashboards, boards built on those filters, component leads, project leads, group-derived access |
| Who handles it | User management tools, SCIM sync from your identity provider, org admin console | Usually nobody. Jira has no built-in reassign-on-departure step |
| When it fails | Immediately and loudly: the person can still log in, or the seat still bills | Silently, weeks or months later, in the middle of someone else's work |
| What done looks like | Account deactivated, license reclaimed, access revoked | Every item transferred to a named successor, with a record of who took what |
Both layers are necessary. Neither substitutes for the other.
What breaks silently, months later
Orphaned ownership does not fail on the day the person leaves. It fails when someone finally needs the thing.
The board nobody can edit
A team board is powered by a saved filter the leaver owned. The board keeps rendering, until the team needs to change the filter and discovers only the owner or a site admin can, one manual ownership change at a time.
Issues routed to a ghost
Components can default-assign new issues to the component lead. When that lead is a deactivated account, new bugs are assigned to someone who will never log in again, and nothing flags it.
The backlog that quietly ages
Open issues stay assigned to the leaver. Sprints plan around them, reports count them, and each one waits until a standup finally asks why a ticket has not moved in a quarter.
The dashboard on the wall
The leaver's dashboard keeps displaying on the team TV until a gadget needs fixing. Ownership changes then go through an admin screen, dashboard by dashboard, if anyone remembers who owned what.
The report that stops arriving
Filter subscriptions the leaver set up stop being sent for a deactivated account. The weekly digest a manager relied on simply never shows up again, with no error anywhere.
The audit with no answer
A security review asks who took over the leaver's access and work. If the account was deleted in the meantime, even the list of groups they belonged to is gone. Guesswork is not evidence.
Use both layers together
This is not a choice between tool classes. Account tools and an ownership handover complement each other, and a clean leaver runbook uses both.
The leaver ticket arrives
HR or IT opens the offboarding ticket, same as today. Nothing about your intake changes.
Hand over the work
Inventory everything the person still owns in Jira and transfer it to named successors: issues, filters, dashboards, component and project leads, plus a snapshot of group memberships for the record.
Close the account
Deactivate, reclaim the license and deprovision with the user management tooling you already run. That layer is its job, and it does it well.
File the evidence
Attach the exported audit CSV to the offboarding ticket: who ran the handover, when, every item, every outcome. The next audit takes minutes.
Handover covers the ownership layer
Handover for Jira does the second job: one read-only scan of everything a departing user still owns, one plan of named successors, one audited run.
Open issues, reassigned
Open issues move to the successors you choose, up to 5,000 per run, in resumable background batches, optionally leaving a templated comment so the new assignee knows why the work landed on their plate.
Filters, including private ones
Saved filter ownership is transferred, and private filters are included: the ones no bulk screen shows you and no successor even knows exist.
Dashboards, verified
Dashboards transfer automatically through Atlassian's bulk ownership API, and every result is read back and verified. Anything Jira blocks becomes a guided step with Retry as me and Mark done, recorded in the audit instead of failing silently.
Component and project leads
Lead assignments move to successors, so default assignees and routing point at people who still work here.
Groups, snapshotted then re-granted
Group memberships are snapshotted into the audit before the account goes. Re-grants run per group as you, the clicking org admin, at the moment you click: never in the background, never from stored credentials.
Proof, permanently
Every run produces a permanent audit record, exportable as CSV, naming who ran it, when, every item and every outcome. It runs entirely on Atlassian infrastructure with zero data egress.
Honest limits, stated plainly: Handover does not deactivate accounts, that stays with your account-layer tooling. It deliberately leaves closed issues untouched, because reassigning finished work would rewrite history. And no Jira API can see a dashboard the leaver never shared with anyone; site admins can review those under Jira's Shared dashboards admin page.
Quick answers
What happens to issues when you deactivate a Jira user?
Nothing. Deactivation blocks sign-in and frees the license seat, but every issue stays assigned to the deactivated account, and their filters, dashboards, component leads and project leads all remain theirs. Jira does not prompt you to reassign anything.
Does removing a user from Jira reassign their issues?
No. Removing site access or deleting the account leaves the issues in place, attributed to an anonymized former user, which makes the leftover work harder to find, not easier. Transfer ownership first, then close the account.
Can I bulk reassign a leaver's issues myself?
Open issues, yes, with a JQL search and Jira's bulk change tool, if you know to look and can write the query. But filters and dashboards have no bulk path: ownership changes go through admin screens one item at a time, private filters are easy to miss entirely, and none of it leaves a record of who took what. Handover does the whole inventory in one audited run.
We already deactivated the account. Is it too late to transfer their work?
No, and this is the most common case. Deactivation changes nothing about ownership, so Handover scans and transfers a deactivated user's work exactly the same way as an active one's.
Does Handover replace our user management or SCIM tooling?
No, and it does not try to. Handover never deactivates accounts or reclaims licenses. It covers the ownership layer those tools do not: run Handover for the work, then close the account with the tooling you already trust.
Close the account. Hand over the work.
Handover for Jira finds everything a departing user still owns and transfers it in one audited run, entirely on Atlassian infrastructure. Free for 10 or fewer users, $1.25 per user per month above that, 30 day free trial.
See how Handover works Get it on the Marketplace