Skip to content
Cloud to cloud

Three Jira sites means three sets of rules.

Consolidating Jira Cloud sites means copying projects from each source site into one destination site with Atlassian's cloud-to-cloud transfer, then cleaning up what the copy duplicates. Atlas Bench, an Atlassian Platinum Solution Partner, plans the merge order, clears project key and group conflicts, rebuilds what the transfer skips, such as automation rules and app data, and rationalizes fields, schemes, and groups so the merged site runs on one set of rules.

Multiple Jira Cloud sites merged into one governed site in one Atlassian organization, with duplicate fields, schemes, and groups rationalized instead of copied across.

before after one platform separate instances, separate permission models L1 L2 L3 L4

The problem

Sites multiply for ordinary reasons. An acquisition brings its own. A team started one on a credit card. An earlier migration landed in a new site to keep risk down. Each site grows its own fields, workflows, and permission schemes, and nobody owns the full picture.

Atlassian can move the data. Its cloud-to-cloud transfer copies work items with their history, workflows, boards, and JSM queues and SLAs. It does not copy automation rules, app data, or global permissions. Fields and schemes that do not match arrive as duplicates with a "(migrated)" suffix, and groups with the same name merge, which can give people access they never had. Without a plan, the merged site ends up messier than the sites it replaced.

What the work is

Site inventory

Projects, fields, workflows, schemes, groups, apps, and automation rules counted across every source site, with an owner named for each.

Target design

One set of standard workflows, fields, and permission schemes for the destination, agreed before any data moves.

Conflict clearance

Duplicate project keys resolved, same-name groups reviewed so a merge does not widen access, and apps installed on both sides before the copy.

Transfer and validation

Projects copied in waves with Atlassian's cloud-to-cloud transfer, then checked for counts, history, attachments, and permissions, with links to the old site fixed using Atlassian's link fixing.

Rebuild what does not move

Automation rules exported and re-imported, global permissions and settings set up on the destination, and app data moved with each vendor where their data needs its own path.

Rationalization

Suffixed duplicate fields and schemes merged or retired, so the site runs on the standard set instead of carrying both.

How it runs

  1. Plan

    2 to 3 weeks

    Inventory, target design, and a wave plan. Key and group conflicts listed with owner decisions before the first copy.

  2. Move

    In waves

    Projects copied in agreed waves, validated, and handed to their teams, with automation and app data rebuilt as each wave lands.

  3. Settle

    2 weeks

    Duplicates rationalized, source sites set to read-only and retired, and licensing reduced to one site.

What you get

  • An inventory of every source site, with owners and a disposition for each project
  • A standard set of workflows, fields, and permission schemes for the merged site
  • A wave plan with project key and group conflicts resolved
  • Validated project copies, with automation rules and app data rebuilt
  • Duplicate fields and schemes rationalized after the move
  • Source sites retired and licensing reduced to one site

Questions we get

Can Atlassian merge two Jira Cloud sites automatically?
Not in one step. Moving a site into another organization keeps it a separate site. To combine sites, you copy projects into one destination site with the cloud-to-cloud transfer, then clean up what the copy leaves behind.
What does the cloud-to-cloud transfer not copy?
Automation rules, Marketplace app data, global permissions, general settings, comment reactions, and a few field types. Confluence links and URLs in content still point to the source site until you run Atlassian's link fixing. We plan a rebuild for each of these before the first wave.
What happens when both sites use the same project key?
The pre-copy check flags it. Project keys must be unique in a site and are not case sensitive, so the project comes out of the plan or one key changes first. We agree those changes with owners and update anything that depends on the old key.
Will teams lose their history?
No. Work items come across with comments, attachments, work logs, and history.
How is this different from a migration?
It is a migration where the destination already has people working in it. The design work on fields, schemes, and groups matters more than the transfer itself.
What does this have to do with agents?
An agent working across sites with different rules gives inconsistent answers. One site with one set of fields and permissions is what makes an agent's output consistent and auditable.

Find out what you are actually running.

Fixed scope. The assessment reads the estate as it is: instances, schemes, licensing, and the decisions a migration would force you to make anyway. You get the findings, the ownership gaps, and the order to close them in.