Offboard people, not their work.
When someone leaves, deactivating their Jira account reassigns nothing. Handover finds the open issues, filters, dashboards, component and project leads they still own, then transfers all of it to the right successors in one audited run.
Installs in under a minute · 30-day free evaluation · billed through your existing Atlassian invoice
Deactivation is not offboarding. Jira keeps the leaver as assignee, owner and lead on everything, silently.
Orphaned work is invisible. Filters and dashboards owned by ex-employees keep running until they break a team's workflow.
Auditors ask who took over. Handover's exportable record answers in one click: who ran it, when, every item, every outcome.
Sixty seconds, whole story
What happens when someone leaves, and what Handover does about it.
Four steps. One audited run.
Built for the moment IT hands you a leaver ticket. No spreadsheets, no JQL archaeology, no "whose dashboard was that?" three months later.
Find everything they own
One read-only scan inventories open issues, filters, dashboards, component leads, project leads and group memberships. Works on active or already-deactivated accounts.
Assign successors
One default successor covers most offboardings. Override per project or per category when different people should take over different things.
Execute in safe batches
Preview every change first; nothing is written until you confirm. Then transfers run in the background in chunks with live progress, and item-level failures never abort the run.
Export the audit
Every run produces a permanent audit report, exportable as CSV for HR, security reviews and compliance evidence.
Everything the leaver ticket needs
Complete ownership inventory
Open issues by project (up to 5,000 per run, disclosed when capped), saved filters including private ones, dashboards, component leads and project leads, plus a snapshot of group memberships for your records.
Successor routing that matches reality
Default successor, per-project overrides, per-category overrides. The platform team's issues go to the platform lead; the filters go to the ops manager.
Safe, resumable execution
Batched through Forge's async queue: hundreds of transfers with progress saved every few items, safe retries, and a one-click resume if a run is ever interrupted.
Paper trail on the issue itself
Optionally leave a templated comment on every reassigned issue, so the next assignee knows exactly why it landed on their plate.
Automated to the documented edge
Dashboards transfer automatically through Atlassian's newest API, verified after every change. Where Atlassian's platform stops, Handover degrades honestly: guided steps with Retry as me and Mark done, all recorded in the audit.
Compliance-grade history
A permanent record of every handover run on your site: filterable, exportable as CSV naming who ran it and when, deletable only by admins, and stored inside your own Jira and nowhere else.
Why Handover
Offboarding tools cluster into two camps: transfer utilities that move a few things to one person, and user-management suites that deactivate accounts but never touch what the person owned. Handover is built for the whole job.
| Handover | Transfer utilities | User-management tools | |
|---|---|---|---|
| Private filters | Scanned and transferred via admin override | Typically invisible | Not covered |
| Dashboards | Automated transfer, verified, honest fallback | Often excluded outright | Not covered |
| Group memberships | Snapshot plus per-group re-grants, as you | Usually out of scope | Bulk account ops only |
| Successor routing | Default plus per-project and per-category | Single successor | Not applicable |
| Audit record | Permanent, exportable, names who and when | Limited or deletable retention | Account actions only |
| Scale and recovery | 5,000-issue runs, resumable, safe retries | Rarely documented | Not applicable |
| Tells the team | Templated comment on every reassigned issue | Silent | Silent |
Deactivation and license reclamation tools do the account half of offboarding well. Run Handover first, then deactivate with the tool you already use.
Security is the product, not a feature page.
Runs on Atlassian
Built Forge-native. No external servers, no data egress, nothing to send anywhere. Your data is processed and stored entirely on Atlassian infrastructure, honoring your site's data residency automatically.
Least privilege, declared up front
read:jira-work · write:jira-work
read:jira-user · manage:jira-project
manage:jira-configuration · storage:app
Nothing lingers
Handover stores only plans, progress and audit summaries in Forge storage on your site. Delete any offboarding record from inside the app; uninstalling removes the app's storage under Atlassian's Forge data lifecycle.
Pricing that fits the leaver ticket
Billed by Atlassian on your existing invoice, alongside your Jira subscription. No new vendor onboarding, no procurement cycle.
Cloud
- Tiered down as your site grows on Atlassian's standard per-user model
- 30-day free evaluation, cancel anytime
- Unlimited offboardings and audit history
- All features included. No editions, no gates
Small teams
- Full product, no feature limits
- Same audited runs, same security posture
- Upgrade happens automatically through Atlassian billing as you grow
Questions admins actually ask
The person already left and their account is deactivated. Too late?
Not at all. That is the most common case. Deactivating an account changes nothing about ownership; Handover scans and transfers deactivated users' work exactly the same way.
How do dashboard transfers work?
Handover transfers dashboards automatically through Atlassian's bulk ownership API and verifies every result, because that endpoint is currently marked Experimental and trust has to be earned per change. Anything the API cannot move becomes a guided step with a Retry as me option (the change runs under your own admin permissions) and a Mark done control recorded in the audit. One honest limit: no Jira API can list a dashboard the leaver never shared with anyone; site admins can review those under Jira Settings → System → Shared dashboards.
Does it touch closed issues or other people's work?
No. The scan targets open issues assigned to the leaver and artifacts they own, nothing else. Done work keeps its history: reassigning closed issues would rewrite the record, so we deliberately don't.
Why does it need manage-project and manage-configuration scopes?
Changing a project lead or a component lead is an admin operation in Jira's API model. Handover declares every scope it will ever need up front, so you'll never face a surprise permission re-approval after an update.
What about group memberships?
Handover snapshots them into the audit, then lets you re-grant them per group from the audit report. Those changes run as you, the org admin, at the moment you click: Handover never holds standing admin credentials and cannot change groups in the background, a constraint Atlassian's own architecture enforces and we treat as a feature. Directory-managed groups (SCIM, Okta, Entra) are detected and flagged for your IdP, and privileged groups sit behind a typed confirmation.
What about Confluence?
Handover for Confluence (pages, spaces, calendars) is on the roadmap. Tell us you want it and you'll shape the order we build in.
Refunds and billing?
All billing runs through Atlassian: 30-day evaluations, monthly or annual terms, and Atlassian's standard 30-day refund policy apply automatically.
The next leaver ticket takes ten minutes, not a sprint.
Install from the Atlassian Marketplace, run your first scan, and never lose another filter to an ex-employee's account.
Get Handover for JiraMarketplace listing link goes live with launch. This button currently points at Marketplace search.