StructureMigrator
The official migration path for Structure for Jira transfers your board hierarchies — but not who may see them or with which view. StructureMigrator closes exactly that gap: permissions and views move into Cloud board by board, verifiable against the Data Center state.
- Transfers permissions and views Atlassian doesn't migrate — board by board
- Maps users and project roles to their Cloud counterparts automatically
- Dry-run before every write step, duplicate protection for existing Cloud boards
- Dry run before every write
- Checked against Data Center after every stage
- One isolated stack per customer
- The final report names what was skipped, too
In large Data Center installations, Structure for Jira is often the central planning tool: hierarchical board views across many projects, plus the permissions that govern who may see and edit a board, and saved views with the right columns. The official Cloud migration path transfers only the board hierarchies. Permissions and views are left behind — and then have to be set again by hand, board by board. With dozens to over a thousand boards, that turns into days of error-prone clicking whose result no one can reliably verify.
StructureMigrator takes over exactly this part. It reads the permissions and views out of Data Center, maps users and project roles to their Cloud counterparts, and writes both into Cloud board by board through the Structure Cloud interface. Every write step runs as a dry run first, showing what would happen without changing anything. The tool recognizes boards that already exist in Cloud and leaves them untouched, and after the transfer an automatic check reconciles the Cloud permissions against the Data Center state.
What a standard migration leaves open
After a standard migration
- Permissions don't come along in the migration — every board has to be re-shared by hand
- Saved views are missing, teams set up every column view again
- Users and roles have to be mapped to Cloud laboriously by hand
- Whether everything is really correct after the rework is hard to verify
With this tool StructureMigrator
- Who may see and edit a board is transferred into Cloud board by board
- Views are transferred and correctly permissioned, the familiar views are available right away
- Users and project roles are mapped automatically via the Atlassian account ID
- An automatic check reconciles the Cloud permissions against the Data Center state
In three verified stages
StructureMigrator writes nothing blindly. Every step can be limited individually to a single board, every write step runs as a dry run beforehand, and existing Cloud boards stay untouched thanks to duplicate detection. After the transfer, the result is checked against the Data Center state.
-
1
Capture & map
StructureMigrator first detects your Cloud instance's technical key data automatically, then reads all board permissions out of Data Center. After that it maps users via the Atlassian account ID and maps the project roles to their Cloud counterparts — the basis for later landing every permission with the right person.
Verified: Cloud configuration detected, Data Center permissions exported, users and roles mapped
-
2
Migrate
The tool retrieves all existing Cloud boards, detects duplicates by name, owner and structure, and then transfers the permissions board by board through the Structure Cloud interface. Boards that already exist stay untouched, and every write step can be checked beforehand in the dry run.
Verified: Permissions transferred board by board, existing Cloud boards protected
-
3
Views & verification
Finally, StructureMigrator transfers the saved views and sets their permissions correctly in Cloud. An automatic check then reconciles all transferred permissions against the Data Center export, so it is documented and traceable that Cloud matches the original.
Verified: Views transferred and permissioned, permissions checked against Data Center
What it does
Cloud configuration detected automatically
StructureMigrator determines your Cloud instance's region, domain, app and install ID itself from the live network traffic. You don't have to hunt down these scattered technical parameters or type them out — saving time and eliminating a classic source of error before the first step runs.
Users and project roles mapped automatically
Data Center accounts and project roles are mapped to their Cloud counterparts via the Atlassian account ID, not via names that may differ. As a result, the transferred permissions land with the right people and roles after the migration — and not, by accident, with someone else.
Permissions transferred board by board
Who may see and edit which board is transferred in full from Data Center to Cloud — board by board, through the official Structure Cloud interface. This is precisely the part the standard migration path omits and that you would otherwise have to redo by hand.
Saved views included
Saved column configurations — the views — move into Cloud as well and regain the correct permissions there. Your teams open their boards in Cloud with the familiar views, instead of having to set up every column layout again.
Existing Cloud boards protected
Boards that already exist in Cloud are reliably recognized by name, owner and structure, and left untouched. A second run or a partial migration therefore creates no duplicates and overwrites no existing configuration — you can safely repeat the process.
Dry-run and automatic verification
Before every write step, a dry run shows all planned changes without altering anything. After the migration, an automatic check reconciles the transferred permissions against the Data Center state and documents the result — you can see in black and white that Cloud matches the original.
Common questions before migrating
Will my existing Cloud boards be overwritten?
No. StructureMigrator recognizes existing Cloud boards by name, owner and structure and leaves them untouched. As a result, even a second run or a partial migration creates no duplicates and overwrites no existing configuration.
Can I test a single board first before migrating everything?
Yes. Every step can be limited to a single board, and every write step runs as a dry run beforehand, showing what would happen without changing anything. So you can verify on a pilot board and only then scale up.
Do the permissions really land with the right people?
StructureMigrator maps users via the Atlassian account ID, not via names that can differ between Data Center and Cloud. Project roles are mapped separately. This way the transferred permissions reach the right people and roles.
How can I verify that Cloud matches the Data Center state?
After the migration, an automatic verification reconciles the transferred Cloud permissions against the Data Center export and documents the result. Discrepancies are named rather than left unnoticed — you get a verifiable record.
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
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.