User guide

Successor moves what a departing person owns in Jira to whoever takes over, and hands you a tracked checklist plus a CSV record for everything an app is not permitted to change.

Find it at Jira Settings → Apps → Successor. Only Jira administrators can open it, and every backend call re-checks that permission on its own - being on the page is not enough.

Run it before you deactivate

One timing rule, and it is the only irreversible thing here. Jira stops listing an account as a board administrator the moment it is deactivated or suspended, and it never lists it again. Those entries stay in the board's settings, invisible to every API Atlassian offers. If board admins matter to you, scan while the account is still active. Everything else on the list survives deactivation and can be cleaned up afterwards.

You do not choose a mode. Successor reads whether the person is still active and runs the right lane by itself - fifteen checks while they are active, fourteen after, with the one it cannot do listed in the record as out of scope rather than silently skipped.

Running an offboarding

Name both people. Search for who is leaving; if the account is already deactivated, Jira's user picker will not show them, so paste their account ID instead. Then pick who takes over - that one has to be an active account, so it is search only. One person receives everything; you can hand pieces on to others in Jira afterwards.
Scan. Read-only, and it says so. A progress bar counts the checks as they come back. Large sites are walked in batches, so you can leave the page open; stopping mid-scan leaves nothing half-done, because nothing has been written.
Review by consequence. Findings are grouped by what breaks, not by which Jira object they are. Blocking work is stuck on the person today. Will break later keeps working until the account goes. Over to you is what no app is allowed to change. Everything starts selected; untick anything you want left alone.
Confirm. A dialog restates the numbers - what moves, what stays, what is on you - and the write only happens on the button in that dialog.
Read the result. The headline answers the question first; the work you still have is above the record, not buried under it.

How a write is judged

Every write is read back on the surface that actually stores it, and only a passing read-back counts. A 2xx alone is not evidence - Jira has endpoints that return success and store nothing.

Outcome	What it means
Moved	Written, then read back and confirmed. The only outcome the app claims.
Unconfirmed	The write returned success and the read-back call itself failed, so the app cannot say either way. It is not reported as failed, because that would state something it does not know. Look, then tick.
Failed	The app tried and Jira refused. The exact error is quoted on the row, and the write is retryable from the record.
Already correct	Already pointed at the successor, so nothing was written. Several Jira writes are not idempotent and error on a repeat, so this is checked before every one.
Never ours	No app may write it. It was on the review screen before the run, unchanged.
Out of scope	A check this lane does not run. Recorded on purpose: "we did not look" and "we looked and found nothing" must not read the same months later.

The checklist

Anything the app could not do lands on a checklist above the record, split into what failed today and what was never the app's to change. Each entry carries the reason, a link to the screen where you fix it, and a tick. Ticking records your name and the time, and it lands in the CSV as an attestation - which is deliberately not the same thing as a verified read-back, and is labelled differently so an auditor can tell them apart.

Un-ticking does not erase the tick. The previous attestation stays in the record, because a history that can be quietly walked back is not a record.

When a check does not come back

If Jira refuses, times out or rate-limits a check, the run says so rather than quietly reporting a smaller number. The coverage line names how many checks did not come back and why - in plain words, not an HTTP code - and gives you a button that re-runs only those checks and merges the results into the same run. "38 of 38 moved" means something different when three checks never ran, and the record has to say which it was.

What the app cannot do

These are Atlassian platform limits, not choices.

Group memberships

Atlassian's identity layer refuses apps outright, for every group type. Successor finds the memberships and links you to Atlassian admin. If a group is synced from your identity provider, remove the membership there instead - a directory edit gets overwritten on the next sync.

Automation

Apps cannot list, read or write automation at all, so there is no count to show. Jira has its own Transfer User wizard for this, and Successor links straight to it. It replaces every reference to the person across your flows - owner, actor, and any user picker inside a flow - and previews the affected flows before you submit. Connection owners are the one exception: they stay on the departing account and have to be changed inside each flow by hand.

Board administrators

Transferable only while the account is still active. See the timing rule above.

History

Comments, worklogs and authorship are immutable for everyone, Atlassian included. No tool reattributes these.

The account itself

Deactivation and deprovisioning stay with your identity provider or Atlassian admin. Successor handles what the account leaves behind.

The record

Every run is stored and reopenable from Past runs - the latest 200 are kept. A reopened run renders exactly as it did the day it finished: same order, same numbers, same wording. You can still tick and still retry from it, and both are stamped.

A stored run is a historical document. It shows the instructions the admin was actually given that day, even if the app has since changed its wording - re-writing old records to match current copy would make every past run claim it said things it never said.

Download audit CSV exports the whole run: who ran it, both people, every artifact touched, write status, verification status, and every manual completion with attribution. This is the evidence trail for ISO 27001 (A.5.11 / A.5.18) and SOC 2 (CC6.2 / CC6.3) style reviews.

Four rows from one run's audit CSV, trimmed to the columns that answer the question. The full file repeats who ran it, who left and who took over on every row, so one line stands on its own.

runNumber	surface	artifactName	action	writeStatus	verified	manualDoneBy
48	filter-owner	Platform - open bugs	auto	204	true
48	board-admins	Platform board	auto	200	true
48	jsm-approver	HR-1042 Laptop return	auto	204	true
48	groups	jira-software-users	manual			Dana Whitfield

Settings

Board admin transfer is the one lane that uses an Atlassian-internal endpoint, because it is the only way any app can write board administrators. Every write is verified against the public read API, and if verification fails repeatedly the app switches the lane off by itself and falls back to checklist links, telling you it did. You can toggle it here.

Licensing

Scanning works without a license - see what is there before you pay. Executing a transfer needs an active license or trial.

Support

support@rigelapps.dev - attach the audit CSV if you can. Download audit CSV is at the foot of any run record, and it carries the run ID plus everything the app saw, which is more than we can work out from a description. Initial response within one business day.