Migrating from Jira Data Center to Cloud: What Most Teams Learn Too Late

Prince Nyeche - ELFAPP

Over the past few years, one of the most common conversations I’ve had with Jira administrators is about moving from Jira Data Center to Jira Cloud.

The good news is that migration tooling has improved significantly. Tools like the Jira Cloud Migration Assistant make the technical transfer of data much easier than it used to be.

But after working with many environments and building administrative tooling used during migrations, I’ve noticed something interesting:

The migration itself is rarely the hardest part.

The real complexity usually shows up before the migration starts and after the data lands in Cloud.

Organizations that approach migration successfully tend to treat it as a three-stage process or some similar approach:

1. Preparation
2. Migration execution
3. Post-migration stabilization

Let’s walk through each stage.

Phase 1: Preparation (Where Most Migrations Succeed or Fail)

Most long-running Jira environments have evolved over many years.

By the time migration is considered, it's common to see:

• inactive users that were never removed

• duplicate groups created during reorganizations

• workflows that are no longer used

• projects that should have been archived

• custom fields added for historical use cases

Moving everything directly to Cloud usually means bringing years of accumulated complexity along with it.

A good migration starts with a thorough environment review.

Things worth auditing first

Before running any migration tooling, take time to review:

• projects and project schemes

• workflows and workflow schemes

• permission models

• user and group structures

• marketplace apps

• integrations with external systems

The goal is simple:

Understand what you actually need to migrate.

User and Group Management (Often the Most Overlooked Area)

One of the biggest operational changes when moving to Cloud is identity management.

Organizations frequently introduce Atlassian Guard during this transition, which adds centralized identity control through:

• SAML SSO

• domain verification

• SCIM provisioning

Before migrating, it’s worth cleaning up:

• inactive users

• unused groups

• redundant permission assignments

This makes access management much easier once the environment is running in Cloud.

During many migrations, administrators also need to perform large-scale user and group operations. Tasks like restructuring groups or adjusting permissions across multiple projects can quickly become tedious without bulk administrative tooling.

This is exactly the type of operational scenario where tools like BulkOps Org can simplify governance adjustments during migration planning.

Marketplace Apps: The Most Common Migration Surprise

Another area that deserves attention early is the Atlassian Marketplace.

Many organizations rely on apps that were originally installed years earlier. During migration planning, administrators should verify:

• whether the app has a Cloud version

• whether its data can be migrated

• whether configuration needs to be recreated

Apps and integrations are often the most unpredictable part of a migration, so reviewing them early avoids surprises later.

Phase 2: Running the Migration

Once preparation is done, the actual migration process becomes much more straightforward.

Most organizations rely on the Jira Cloud Migration Assistant, which helps transfer:

• projects

• issues and attachments

• workflows

• configurations

• users and groups

However, one best practice cannot be emphasized enough:

Never perform a migration only once.

Successful migrations usually involve several test runs.

A typical approach looks like this:

1. Run a sandbox migration
2. Validate the results
3. Fix identified issues
4. Run a second migration test
5. Perform the final production migration

This iterative process helps uncover:

• permission inconsistencies

• automation behavior differences

• integration issues

• configuration conflicts

 

Phase 3: Post-Migration Stabilization

One misconception about migration is that the work ends once the data reaches Atlassian Cloud.

In reality, this is when a lot of operational tuning begins.

Common post-migration tasks include:

• validating user access and project permissions

• reviewing group mappings

• reconnecting integrations

• updating automation rules

• cleaning up leftover configuration artifacts

Administrators often need to perform these changes across multiple projects or users simultaneously. 

Migration Is Also an Opportunity

One thing I often recommend to teams is to view migration not just as a technical move, but as a chance to improve the overall health of the environment.

Instead of simply replicating the existing setup, migration is a great moment to:

• simplify workflows

• reduce configuration complexity

• modernize integrations

• improve governance models

Teams that take advantage of this opportunity usually end up with a cleaner and easier-to-manage Jira environment in Cloud.

In the End

Migrating from Data Center to Cloud is a significant step, but with the right preparation it becomes far more manageable.

The key takeaway is that migration is not a single event.

It’s a process that starts well before the first migration run and continues after the data has been transferred.

With proper planning, structured testing, and thoughtful post-migration cleanup, organizations can transition smoothly to Atlassian Cloud while improving the overall health of their Atlassian ecosystem.

Arkadiusz Wroblewski

@Prince Nyeche - ELFAPP 

very nice article.

One thing I would definitely add from experience: every migration is a bit unique.

The overall phases are absolutely right 🙂 preparation, execution, stabilization  but the real complexity usually comes from the details of that specific instance: old workflows, app dependencies, permission models, user/group cleanup, integrations, and all the little historical decisions that built up over the years. That also fits very well with your point that the migration itself is often not the hardest part. 

So for me, that is usually the biggest lesson: there is no fully “standard” migration, even if the tooling is the same.

Two companies can both move from Data Center to Cloud and still have completely different challenges, simply because their environments evolved differently over time. And that is exactly why your point about doing multiple test runs matters so much. 

So yep, great write-up  and I would strongly agree that migration is much less a one-time technical event, and much more a unique cleanup, validation, and redesign exercise for each environment.