Moving Jira from Data Center to Cloud is not only a data migration.
For long-running Jira environments, one of the most important questions should come before the migration itself:
How much of the existing Jira configuration do we actually need to take with us?
Years of Jira administration can leave behind custom fields, screens, workflows, roles, versions, and other configuration objects that were created for projects or processes that may no longer exist.
Migrating everything without first understanding those relationships can carry years of configuration complexity into the new Cloud environment.
A useful first step is therefore to analyze the existing Jira configuration and understand what is actually being used.
1. Start with custom fields
Large Jira environments can accumulate hundreds or even thousands of custom fields.
The difficult question isn't simply:
Which fields exist?
It is:
Where is each field actually used?
A field can be connected to projects through several layers of Jira configuration. For example:
Field → Screen → Screen Scheme → Issue Type Screen Scheme → Project
A field may also participate in workflow transition screens:
Field → Transition Screen → Workflow → Workflow Scheme → Project
Understanding these relationships before migration helps distinguish fields that are actively connected to projects from fields that may be candidates for further investigation or cleanup.
Doing this manually can require navigating through many separate Jira administration screens.
Fields Usage for Jira provides a consolidated view of these relationships, allowing administrators to trace fields through screens, screen schemes, workflows, workflow schemes, and projects.
2. Understand project-role assignments
Configuration analysis should not stop with fields.
A migration is also a good opportunity to understand how project roles are being used across the Jira environment.
Two perspectives are particularly useful:
Project → Role → User/Group
This answers questions such as:
- Who is assigned to roles in this project?
- Which groups provide those assignments?
- Are role assignments still appropriate for projects being migrated?
The opposite perspective is equally valuable:
User/Group → Role → Project
This makes it possible to start with a user or group and understand where that identity receives project-role assignments across Jira.
This can be useful before migration for access reviews, governance, and identifying role relationships that should be understood before recreating or validating the Cloud configuration.
Roles Usage for Jira provides both perspectives in a single reporting interface.
3. Review versions across projects
Versions are another area where configuration can accumulate over many years.
Some projects may contain old releases, archived versions, similarly named versions, or versions that are no longer relevant to the environment being migrated.
Before migration, it can be useful to answer:
- Which versions exist?
- Which projects contain them?
- Which versions are released, unreleased, or archived?
- Which issues reference a version?
- Are similarly named versions being used by different projects?
- Are there versions that warrant review before migration?
This is especially difficult to understand when versions must be inspected project by project.
Versions Usage for Jira provides a Jira-wide view of versions and their relationships to projects and issues, making it easier to analyze the release configuration before migration.
4. Look at configuration as relationships, not lists
This is perhaps the most important point.
A simple inventory tells you that an object exists.
It does not necessarily tell you why it exists or what depends on it.
For migration planning, relationships are often more useful than inventories.
Consider a custom field.
Knowing that Customer Region exists tells you very little.
Knowing that it appears on particular screens, that those screens participate in particular screen schemes, and that those schemes ultimately apply to 17 projects tells you considerably more.
The same principle applies to roles and versions.
Before deciding whether something should be migrated, consolidated, cleaned up, or investigated further, administrators need to understand its dependencies.
5. Identify candidates for cleanup — but verify before deleting
Configuration analysis can reveal objects that appear unused or have very limited usage.
That does not automatically mean they should be deleted.
An apparently unused field, role, version, screen, or other object may still have historical, integration, reporting, or organizational significance.
The objective of pre-migration analysis should therefore be:
identify candidates → understand dependencies → verify → decide
rather than automatically deleting everything that appears unused.
This turns cleanup into an informed administrative decision instead of a bulk deletion exercise.
6. Reduce what you carry into Cloud
Migration provides a rare opportunity to examine configuration that may have accumulated for years.
If an organization understands its Jira configuration before moving, it can make deliberate decisions about what should remain part of the future environment.
That can mean:
- identifying unnecessary configuration;
- understanding dependencies before making changes;
- reviewing access and role assignments;
- identifying old or duplicate release structures;
- documenting important configuration relationships;
- reducing unnecessary complexity before or during migration.
The objective isn't simply to make the migration smaller.
It is to arrive in Jira Cloud with a configuration that administrators understand.
7. Use a combined configuration view
For organizations that need to investigate all three areas, Config Insights for Jira combines:
- Fields Usage
- Roles Usage
- Versions Usage
This provides different perspectives on the same broader question:
How is our Jira configuration actually being used?
The individual applications can also be used separately when only one area needs to be analyzed.
The Simitech Cloud applications are built on Atlassian Forge and are listed by Atlassian Marketplace as Runs on Atlassian. Atlassian's Marketplace privacy information for the individual apps states that they do not process or store end-user data outside Atlassian apps and services.
Analyze first, migrate second
A Jira migration is much easier to reason about when you understand the environment you're starting with.
Before moving years of configuration into Cloud, answer three basic questions:
Where is it used?
What depends on it?
Do we still need it?
For large Jira environments, answering those questions manually can itself become a significant project.
Analyzing fields, roles, versions, projects, screens, workflows, and their relationships before migration provides a much clearer foundation for deciding what the future Jira Cloud environment should contain.
Disclosure: I am affiliated with Simitech Ltd., the company that develops and publishes the Jira apps referenced in this article.
![Photo of Petru Simion [Simitech Ltd.]](https://us.v-cdn.net/6038660/uploads/avatars/c7/df/nc7dfc3cdcefb50b8aef7269c429d3d29.png)