Moving Jira Data Center to Cloud, Government Cloud, or Isolated Cloud? Don't Forget Your Marketplace

[Petru Simion _Simitech Ltd__]

Moving Jira from Data Center to Cloud is a major undertaking. Teams can spend months analyzing projects, cleaning up configurations, testing migrations, and planning the transition.

But there is another part of the migration that can become a problem if it is considered too late:

Marketplace application compatibility.

And today, the destination isn't necessarily just Atlassian Commercial Cloud.

Organizations with government, regulatory, security, or infrastructure-isolation requirements may be considering Atlassian Government Cloud (AGC) or Atlassian Isolated Cloud (AIC).

That changes the Marketplace app discussion considerably.

Why AGC and Isolated Cloud change app evaluation

For a conventional Data Center-to-Commercial Cloud migration, one of the first questions is usually straightforward:

Is the Data Center app we depend on also available for Cloud, and does it provide the capabilities we need?

With AGC or AIC, there are additional questions.

An app being available for Commercial Cloud doesn't automatically mean that it is available for Government Cloud or Isolated Cloud.

Security and architecture can also become an important part of the evaluation:

• Where does the application process and store Jira data?
• Does customer data leave Atlassian-managed infrastructure?
• Does the application communicate with external services?
• Does the vendor operate external application servers or databases?
• What does the application's architecture mean for the organization's security review?

For organizations operating in regulated or highly controlled environments, these questions can be just as important as the application's functionality.

And they are much easier to address during migration planning rather than after the migration has already taken place.

Forge helps — but not all Forge architectures are necessarily the same

Atlassian Forge provides an important foundation for building applications that run on Atlassian-managed infrastructure.

But simply seeing “Built with Forge” shouldn't replace understanding the architecture of a particular app. Forge can support different architectural models, including integrations with remote systems.

For our applications at Simitech, we've deliberately chosen a straightforward architecture:

Built entirely on Atlassian Forge.

No Simitech-hosted application servers.

No external Simitech databases.

No customer Jira data leaves Atlassian-managed infrastructure.

That architectural approach has become particularly relevant as we have expanded our apps beyond Commercial Cloud.

A milestone for us at Simitech

We recently completed something we've been working toward for some time:

All nine Simitech Jira apps are now available for Commercial Cloud, Atlassian Government Cloud, and Atlassian Isolated Cloud.

We have organized these applications around three areas that we think are particularly relevant when organizations are analyzing, migrating, and operating large Jira environments.

1. Configuration analysis — understand what you're migrating

Before migrating years of Jira configuration, it helps to understand what is actually there and how it is being used.

Config Insights for Jira brings together three applications that analyze different parts of Jira configuration.

Fields Usage for Jira traces fields through screens, screen schemes, issue type screen schemes, workflows, workflow schemes, and projects. This can help identify dependencies, understand where fields are actually used, and find potential cleanup candidates before migration.

Roles Usage for Jira analyzes Project → Role → User/Group and User/Group → Role → Project relationships, providing visibility useful for access reviews, governance, migration preparation, and validation.

Versions Usage for Jira analyzes relationships between versions, projects, and issues, helping identify dependencies, duplicates, and unused versions.

The question we're trying to help administrators answer is simple:

What configuration do we actually have, where is it being used, and what do we really need to migrate?

2. Historical issue analysis — understand more than the current issue state

Configuration is only part of what organizations accumulate over years of using Jira.

Issues contain another enormous source of information: changes, workflow transitions, comments, assignee history, status history, and historical field values.

Issue Insights for Jira brings together three applications for analyzing that information.

Issue History & Snapshots Reporter for Jira provides Issue History, point-in-time Issue Snapshots, and Snapshot Comparisons.

That distinction is important because these capabilities answer different questions:

What changed?

What did this issue look like at a particular date and time?

What is different between two points in time?

Those questions can become particularly useful when investigating or validating historical information around a migration.

Time in Status Reporter for Jira analyzes historical workflow behavior, including time in statuses and status groups, status entries, transitions, status entry dates, and assignee-related time.

Advanced Comment Search for Jira provides global searching of historical Jira comments, with filtering by author, text, date, and issue attributes.

Together, these tools are intended to help answer another question:

After moving to Cloud, can we still investigate and analyze the history behind our Jira issues—not just their current values?

3. Historical Assets analysis — because the CMDB changes too

For organizations using Jira Service Management Assets, the historical-data problem doesn't stop with Jira issues.

Assets change over time. Attributes change, ownership changes, relationships evolve, and the current state of an object doesn't necessarily tell you what was true six months or two years ago.

Assets History & Snapshots Reporter for Jira provides Asset History, point-in-time Asset Snapshots, and Snapshot Comparisons.

This makes it possible to investigate what changed, reconstruct the values of an asset at a particular date and time, or compare its state between two historical points.

For migration projects, that can provide another way of investigating and validating historical information. Outside migration, the same capabilities can support auditing, compliance analysis, troubleshooting, and historical CMDB reporting.

Scale makes these questions harder

Most of these questions can be answered manually in a small Jira environment.

The problem changes when you're dealing with hundreds of projects, large configuration structures, hundreds of thousands of Assets, or more than a million issues.

That's why scalability has been an important part of our work.

Our issue-based applications have been tested with Jira environments containing approximately 1.5 million issues, and our Assets historical reporting has been tested with approximately 200,000 assets.

Large result sets can be exported to CSV and Excel for further analysis, audits, migration validation, documentation, BI tools, or other downstream workflows.

We've also been working on configurable parallel processing so Jira administrators can balance processing performance against Jira API usage according to the characteristics of their own environment.

AGC and Isolated Cloud availability doesn't eliminate security evaluation

One distinction is worth making explicitly.

An app being available for Atlassian Government Cloud does not mean that the Marketplace app itself automatically becomes FedRAMP authorized.

Organizations still need to perform the security, compliance, and procurement assessments appropriate to their environment.

What AGC and AIC availability provides is the ability to evaluate and use applications designed for those Atlassian environments rather than discovering late in a migration that an application your organization depends on is available only for Commercial Cloud.

For us, reaching availability across Commercial Cloud, Government Cloud, and Isolated Cloud was therefore more than simply adding two more deployment targets. It means we can support organizations with very different Cloud, security, and isolation requirements using the same core set of Jira analysis capabilities.

Let's discuss

I'm curious how others are handling this during Data Center-to-Cloud migrations.

If you're moving to Government Cloud or Isolated Cloud, at what point in your migration process are you evaluating Marketplace apps?

And for Jira administrators, Solution Architects, and Solution Partners who have already gone through this:

What has been the biggest challenge — app availability, feature parity, security review, data egress, migration of app data, or something else?

I'd be interested to hear what you're seeing in real migrations.