PermissionSync
Permission schemes are the area where a migration does the quietest damage: a right removed too many often surfaces only weeks later. PermissionSync is built exactly for that.
- Permissions reconciled scheme by scheme, role by role
- Anything unclear is reported, never deleted
- Two emergency stops before every real deletion
- Dry run before every write
- Checked against Data Center after every stage
- Nothing is written until you approve it
- A traceable final report for every run
PermissionSync compares the permissions of Data Center and cloud scheme by scheme and role by role and decides for each individual permission, by a fixed rule chain, whether it is created, removed or protected. Protected are, among others, Atlassian-managed groups, app roles and accounts, service accounts, Service Management portal customers and project administrators.
At its core is a safety model against quiet damage: anything unclear is never deleted but sorted out before the rule chain and written into the report. Before every real deletion, two emergency stops check whether the protected set is unexpectedly small or the deletion proposal exceeds a defined share — otherwise the run aborts. Deletion happens only one at a time, never in bulk.
What a standard migration leaves open
After a standard migration
- A right removed too many surfaces only weeks later
- Service accounts and app roles get caught in deletion
- Changes run through unchecked
- Only visible afterwards what happened
With this tool PermissionSync
- Anything unclear is reported, never deleted
- Explicitly protected
- Two emergency stops before every deletion
- A report first, then controlled writing
How PermissionSync works
Compare, decide, report, write in a controlled way.
-
1
Compare
The permissions of both sides are read from the data layer scheme by scheme and role by role and put side by side.
Verified: Same snapshot, same result.
-
2
Decide
For each permission the fixed rule chain decides: create, remove or protect. Anything unclear is sorted out beforehand.
Verified: Uncertainty leads to a report, not an action.
-
3
Report
The result is a report first, setting out every planned change.
Verified: Nothing is written without separate approval.
-
4
Write in a controlled way
After approval it writes — with two emergency stops before every deletion and only one at a time, never in bulk.
Verified: Two emergency stops, no bulk deletion.
What it does
Scheme by scheme, role by role
The reconciliation compares both sides systematically and decides per permission by a fixed rule chain: create, remove or protect.
Anything unclear is never deleted
If a user, group or role cannot be matched with certainty, the entry is sorted out before the rule chain and lands in the report — never in the deletion proposal.
Protected accounts
Atlassian-managed groups, app roles and accounts, service accounts, portal customers and project administrators are explicitly protected.
Two emergency stops before deletion
If the protected set is unexpectedly small or the deletion proposal exceeds a defined share, the run aborts. Deletion happens only one at a time, never in bulk.
Report first, then write
The result is a report first. Writing is a separate step that must be explicitly approved.
From the data layer, not live
It reads exclusively from the versioned data layer, not live — same snapshot, same result.
Common questions before migrating
Can PermissionSync delete rights by accident?
That is exactly the risk it is built against. Anything unclear is never deleted, only reported. Before every real deletion two emergency stops kick in, and deletion happens only one at a time, never in bulk.
Which accounts are protected?
Among others Atlassian-managed groups, app roles and accounts, service accounts, Service Management portal customers and project administrators.
Do we see beforehand what is changed?
Yes. The result is a report first. Writing is a separate step that must be explicitly approved.
Why from the data layer instead of live?
Because a fixed snapshot leads to a reproducible result: same basis, same decision — regardless of when the run starts.
In control — from start to final report
Reading separated from writing
Reads come from a read-only data layer; writes go through a single controlled channel. Read access never burdens your Cloud.
A test run before every write
The dry run shows exactly what would happen. Nothing is written until you explicitly approve it.
Repeatable without risk
Every step can be run again without doing harm. An interruption is no problem, and a second run creates no duplicates.
One isolated stack per customer
All tools run on the Jira Migration Manager platform, fully separated per engagement. No mixing of data.
The final report names every item individually: repaired, to review, skipped or failed. Nothing is silently processed wrong.
Runs on the Jira Migration Manager
This tool does not stand alone. It runs on the platform that unites every tool: a read-only read layer pulls Data Center and Cloud into a versioned snapshot, and every change goes through a single, controlled write gateway.
More on the Jira Migration ManagerMore tools
Migration platform
Jira Migration Manager
The platform that brings every migration tool under one roof and makes a Jira DC-to-Cloud migration safe and repeatable: separate read and write paths, rate-limited into the Cloud, credentials encrypted, one isolated stack per customer.
- Read-only read layer and rate-limited write channel kept strictly separate
- All tools on one shared data base, chainable into pipelines
- Token-secured perimeter, encrypted keystore, one stack per customer
Assets Migration
Asset Relink
Migrates Insight/Assets to the Cloud in full: fields and contexts, AQL filters, screens and the object values on every issue. Exactly where standard tools lose the links.
- Create fields, contexts and screens in the Cloud
- Translate AQL filters from Data Center to Cloud
- Relink object values on every issue
Managed Migration
Jira Migration Helper
JCMA migrates the bulk of your data but leaves configuration broken or unmigrated. Jira Migration Helper closes these gaps module by module and, with Managed Migration, runs the right fixes for each finished project automatically — every one dry-run by default and verified against the live Cloud API.
- Repair filters, dashboards, fields, roles and permissions that JCMA leaves open
- Managed Migration: automatically run the right fixes per project as it finishes
- Web UI or CLI, every module dry-run by default and secured by the idempotent write gateway
A fit for your migration?
Describe your case in a few lines — I'll tell you honestly whether and how this tool helps.
Book a callAtlassian ends support for Data Center on 28 March 2029. If you are moving a large, deeply connected environment, plan early rather than late.