Atlassian Cloud Architecture: Organization, Site, Product, and What a Migration Crosses
Mihai Perdum
Author
15 min readSeptember 16, 2026
Key takeaways
An organization sits above one or more sites; a site holds one product instance each; a directory decides who can sign in. Org admin is automatic on every site in the org and cannot be removed from it; site admin and app admin have zero org-level security capability.
Atlassian's own current term for the third admin tier is app admin, not product admin — 'product admin' is what people search, but it does not appear in Atlassian's live docs.
A directory is local or identity-provider, and single sign-on can only be enforced in an identity-provider directory. Org-level account suspension and removal run against a REST path literally named /directory/.
A Data Center to Cloud migration crosses every one of those boundaries fresh: JCMA re-mints every numeric ID, and Atlassian ships a beta, source-instance-only API to fetch the old-to-new ID mapping afterward.
A Cloud-to-Cloud move does not use JCMA at all — Atlassian scopes JCMA to Server and Data Center sources only. It uses Copy product data instead, which needs an org admin who is also an app admin, works within or across organizations, and never mints a new account: an existing accountId gets more data linked to it.
Copy product data's own documentation lists what it does not move: automation flows and global permissions are both flatly excluded, and Marketplace app data is not migrated at all yet, on either migration type.
An Atlassian Cloud tenant has an architecture whether you have mapped it or not: an organization at the top, one or more sites underneath it, a product provisioned per site, and a directory that decides who gets in. Almost nobody draws this before a migration, because most of the time nobody has to — the tenant works whether or not the person running it could sketch the org/site/directory tree from memory. A migration is exactly the moment that stops being true. It asks, directly, who is allowed to create the destination organization, whether the destination site already has a directory the new users need to land in, and which of those boundaries the migration tool in front of you actually touches. Get the shape wrong and the failure shows up as a blocked admin action or a missing account, days into a plan that assumed it was already handled.
This is that shape, straight from Atlassian's own admin documentation, and then the part that actually matters when you are moving something: what a Data Center to Cloud migration rebuilds from scratch, and what a Cloud-to-Cloud move gets to keep.
Organization vs. site: what's actually shared
The organization is the top of the tree. Everything else — every site, every product, every user record — sits inside exactly one organization. An organization can hold more than one site, and the relationship between an org and its sites is not a loose one: when you become an organization admin, "you automatically acquire the Site Admin role for all the sites in the organization which cannot be modified/removed." That is Atlassian's own wording, and it is worth reading literally. It is not that an org admin is permitted to also be a site admin somewhere; the role is automatic, blanket, and un-revocable, on every current and future site the organization holds.
The reverse is not true, and this is the fact people get backwards. Being a site admin on one site grants nothing at the organization level. The admin-roles page's capability table is explicit about where the line sits: an organization admin can view and manage users across the whole organization and touch every organization-level security setting; a site admin's visibility is scoped to their one site, and every organization-level security action — single sign-on configuration, provisioning, two-factor enforcement, API key management — is blocked for them, full stop.
Practically, the navigation path admins actually use is org, then site, then Directory, in that order: "Go to Atlassian Administration. Select your organization if you have more than one. Then select Directory." A person can administer more than one organization, and each one carries its own sites, its own directory, and its own admin roster underneath it.
Org admin vs site admin vs product admin: who controls what
Three roles show up when Atlassian people or documentation talk about who controls what in a Cloud tenant, and it is worth being precise about the third one, because the name people search is not the name Atlassian uses. Atlassian's current admin-roles documentation names the three tiers organization admin, site admin, and app admin — not "product admin." "Product admin" is real, common phrasing (it is how people actually search for this), but it does not appear anywhere in Atlassian's own live docs; the role Atlassian ships is scoped to configuring one specific app, and that is what "app admin" names.
The capability split, quoted directly from Atlassian's admin-roles page:
Organization admin can view and manage users across the whole organization, configure user-access settings, and touch every organization-level security control. Billing access is limited even here.
Site admin can see users only for their own site, cannot configure organization-level user-access settings, and is blocked from every organization security action the org admin controls.
App admin "can administer settings in a specific app" and explicitly "don't have access to Atlassian Administration" at all — no organization user list, no site-level settings outside their one app. That scoping is deliberate: an app admin for Jira Software has no visibility into Confluence settings on the same site, and no visibility into another product's app admins either, even when both products sit on the same site under the same organization.
The practical read: if a migration plan needs someone to touch org-wide security settings, SSO, or provisioning, an app admin cannot do it and a site admin cannot do it. Only an org admin can, and — from the previous section — every org admin already holds site admin everywhere in the organization, so that person can also do the site-scoped work themselves if needed.
Play that forward and it explains a specific, recurring stall: someone with site admin access tries to turn on single sign-on for a migrated site and cannot find the setting, or finds it and cannot save it. The capability table above is the reason — SSO configuration is one of the organization-level security actions the table blocks for both site admin and app admin, with no exception. It is not a bug and not a permissions edge case; it is the role working exactly as documented. The fix is not a different setting to find, it is a different person: whoever owns SSO for the target organization has to be an org admin, or has to grant that role to someone who is, before the migration's identity work can finish.
This is also where the two migration types make different demands on who has to be in the room. A Data Center to Cloud migration needs an org admin early, because the organization, the site, and the directory it lands in either do not exist yet or need configuring — SSO enforcement, user provisioning, and the security settings covered above are org-admin-only work, and nobody else on the project can substitute. A Cloud-to-Cloud move makes a narrower but easy-to-miss demand: Copy product data explicitly requires one person who holds both the org admin role and the app admin role for the products being transferred, at the same time. An org admin who is not also an app admin on the relevant apps cannot start the transfer, and an app admin who is not also an org admin cannot either. Checking that one person actually holds both roles is worth doing before the transfer is scheduled, not on the day of it.
Where identity lives: directories and identity providers
Every organization carries directories, and Atlassian's documentation is specific about there being exactly two kinds: "a local directory" and "an identity provider directory." A local directory holds users nobody is syncing from anywhere else — they were invited, or they signed up themselves. An identity-provider directory holds users synced or authenticated through an external identity provider, and it carries a capability a local directory does not: "You're only able to enforce single sign-on in authentication policies of an identity provider directory." A local directory cannot be forced onto SSO; the identity-provider directory is the only place that lever exists.
Inside each directory, the actual unit of control is finer than "local or IdP." Atlassian's documentation describes "a default authentication policy in each type of directory," and defines it as the thing that "contains the security settings you can apply to subsets of users within a directory" — meaning a single directory is not one uniform security posture, it can carry more than one authentication policy, each scoped to a different subset of the people in it. For a migration, that matters at the exact moment a plan says "everyone gets SSO" or "everyone stays local": the honest version of that sentence has to name which policy, in which directory, the migrated users land under, because the directory itself does not enforce a single answer for every user inside it.
This is not an abstract distinction — it is also where the API surface for account-level operations actually lives. Organization-level account suspension and removal run against the Atlassian Admin API with an org-admin API key, not a product token, and the endpoint path is literally built on the word "directory": suspending an account is a POST to .../directory/users/{accountId}/suspend-access, and removing one is an async, permanent DELETE to .../directory/users/{accountId}. The same org/site split shows up directly in migration tooling built for this: one Cloud-to-Cloud toolkit's own configuration keeps its site-scoped credentials, the ones used for space- or project-level operations, entirely separate from its org-scoped credentials, which exist for exactly one purpose — the org-level user-suspension call. The code draws the same boundary the documentation does, because the API forces it to.
What a Data Center to Cloud migration crosses
This is where the structure above stops being trivia and starts deciding what work a migration actually is.
A Data Center to Cloud migration crosses every boundary in the tree fresh. There is no existing organization, no existing site, no existing directory relationship to inherit — the Jira Cloud Migration Assistant builds all of it as part of the run, and in the process it re-mints IDs. Every entity — issue, project, comment, and more — gets a new identifier in Cloud; the Data Center numbers are not retained. Atlassian's own fix for the confusion this causes is a documented API: a beta, server-side endpoint that runs against the source Data Center instance and returns the old-to-new ID mapping, so anything downstream that still has the old numbers baked in — reports, integrations, saved links — can be reconciled after the fact. Atlassian is explicit that it is beta ("it may change or be removed in future JCMA versions") and that it is meant for reconciliation, not as a permanent integration to build against.
The ID-mapping API is specific enough to be worth reading before you need it, not after. It is gated to JCMA v1.11.4 and later, it runs against the source Data Center instance rather than the Cloud destination, and it answers with a small, documented set of states rather than just success or failure:
text
1GET /rest/migration/latest/report/id-mappings?cloudSiteUrl=<url>&invalidateCache=false
23202 mapping report still being generated — poll again
4200 mapping report ready, returned as CSV
5404 the beta API has been removed from this JCMA version
6400 four named causes: an incorrect cloudSiteUrl, the cloud site not connected
7 (missing container token), no existing migration found for that site, or
8 the ID-mappings CSV file could not be created (folder permissions)
Atlassian's own framing of this endpoint matters as much as its shape: it is explicitly beta, explicitly liable to "change or be removed in future JCMA versions," and explicitly meant for reconciling old references after the fact — not as something to build a permanent integration against. Treat it as a one-time cleanup tool for the migration window, not as infrastructure. Pull the mapping once, while the source instance is still up and the beta endpoint still exists, and use it to fix whatever still points at the old numbers — a saved dashboard filter, a report someone bookmarked by issue key, an integration's webhook payload that logged the old ID. Waiting until the old numbers surface a support ticket is waiting until the source instance, and the API, are both gone.
Identity crosses the same way the IDs do. A Data Center user has no Atlassian account at all until the migration creates one; matching a Data Center username to the right Cloud account, and deciding what happens when the match is ambiguous, is real work with its own failure modes. A companion piece covers that mechanics in depth — this article stops at the structural fact that DC-to-Cloud starts with nothing on the Cloud side and has to build the organization, the site, the directory entries, and the accounts as it goes.
What a Cloud-to-Cloud move uses instead
A Cloud-to-Cloud move starts from the opposite position, and the first fact is the one people most often get wrong: it does not use the Jira Cloud Migration Assistant at all. JCMA's own documentation frames every step around a Server or Data Center source — "Services from Jira Server and Jira Data Center are not migrated to Jira Cloud" is how its own "what gets migrated" page states one of its gaps, never once describing a Cloud source. Cloud-to-Cloud is not the tool JCMA documents itself against. The tool for Cloud-to-Cloud is a different one, "Copy product data" (branded Data transfer in the admin console), reached from Atlassian Administration under Data management.
Copy product data needs someone who is both an organization admin and an app admin for the products being moved, and it works within a single organization or across two separate organizations — the cross-org case is the one that matters most in practice, because it is the path for exactly the situations where two tenants did not start life under the same organization to begin with: an acquisition, a divestiture, or two teams that each stood up their own Cloud presence before anyone decided they should be one. The identity story is the direct opposite of Data Center's: every Cloud user already has one Atlassian account tied to their email, and that account is global, not per-site. Atlassian's documentation states the consequence plainly: "when you copy users, we don't create new user accounts in the destination site. Instead, we link all data and activity associated with a user to their existing Atlassian account." Run the same transfer again later and it is idempotent by design — only new users, groups, and teams get copied on a repeat run. There is no ID-mapping problem to solve after a Cloud-to-Cloud move the way there is after Data Center to Cloud, because the account was never rebuilt in the first place. A tenant-fingerprint check is still worth running either way, since a copy plan pointed at the wrong destination site is a real, separate failure mode from anything about identity.
The documented gap list: what Copy product data leaves behind
Keeping identity does not mean Copy product data moves everything, and Atlassian documents the gap list rather than leaving it to be discovered. Two entries matter for planning: automation flows are not copied, project-level ones included, and global permissions are not copied either — both are listed as flat exclusions in Atlassian's own "what data is copied" reference, not partial or conditional ones. Anyone reading a Cloud-to-Cloud plan as "everything just shows up on the other side" is reading it wrong; automation and global permissions have to be rebuilt by hand on the destination regardless of which migration type this is.
Marketplace app data is a gap on both sides, not a Data-Center-specific problem: Atlassian's own guidance is "we don't migrate Marketplace app data yet" — current-state wording, not a permanent limitation — and the fix on offer today is direct, one app at a time: "make sure your source and destination has the same Atlassian and Marketplace apps... to migrate Marketplace app data, contact the respective Marketplace Partner." There is no bulk path around it; every app on the list means a separate conversation. And billing is a possibility worth flagging rather than a certainty: Atlassian's documentation says you "may get billed depending on the number of users you migrate and your plan on the destination" — a conditional, not a guaranteed line item, but one worth checking before a transfer, not after.
The two migration types, side by side
Put the structural facts and the migration facts next to each other and the actual difference between the two migration types is the row you'd expect, and one you might not:
Data Center to Cloud
Cloud to Cloud
Tool
Jira Cloud Migration Assistant (JCMA)
Copy product data (Data transfer)
Scope of the tool
Server/Data Center sources only
Cloud sources only, same-org or cross-org
Roles required
Org admin (for org/directory/SSO setup)
Org admin and app admin, held by one person
Numeric IDs
Re-minted; JCMA v1.11.4+ ships a beta ID-mapping API for reconciliation
Unchanged — nothing is re-minted
accountId
Created fresh during migration
Stable; existing account gets more data linked to it
Automation flows
Part of JCMA's full-instance move; Atlassian does not list it as excluded
Not copied — documented exclusion
Global permissions
Excluded — JCMA's own "what gets migrated" page lists Global permissions under What isn't migrated too
Not copied — documented exclusion
Marketplace app data
Not migrated by the core tool either way — contact the Marketplace partner
Same: "we don't migrate Marketplace app data yet"
Re-runnable
Adds data without overwriting what exists — not documented as a clean re-run
Idempotent — a repeat run copies only what's new
10 rows × 3 columnsHeader row enabled
The two rows people usually skip when comparing the tools are the roles row and the global-permissions row. The roles row is a staffing question, not a technical one, and it is worth answering before a transfer is on the calendar. Global permissions is the one gap both tools document — JCMA's own "what gets migrated" page and Copy product data's gap list both list it as excluded, unconditionally, so it gets rebuilt by hand either way. Automation flows is where the tools differ: JCMA moves it as part of the product's own migration, Copy product data does not. Marketplace app data is nobody's strong suit yet, on either tool.
None of this changes because the organization/site/directory model above is well understood. What changes is which failure mode you are actually planning for: a Data Center migration's real work is rebuilding identity and reconciling IDs afterward; a Cloud-to-Cloud move's real work is the documented gap list, filled in by hand, against a tenant model that was already correct before the transfer started. Attachment handling is its own separate trap worth knowing about either way it goes.
This is also the first thing LeanZero checks before touching a client's migration script: not what the tool claims to move, but which organization, which site, and which directory a given API key or admin login is actually scoped to. A script that runs cleanly against the wrong site is not a smaller failure than one that fails to run at all — it is a worse one, because nothing about the output says it happened.
Map the organization, the sites, and the directory before picking a tool — the tool follows from which boundaries the move actually has to cross, not the other way round.
