Assessing Your Jira Data Center Apps for Cloud Readiness

[#1]

Why Your App Portfolio Might Be at Risk

With Atlassian sunsetting Data Center in 2029 as part of its Ascend to Cloud program, many teams still assume the migration is simply a vendor-hosted version of what they already run. It is not. One of the clearest places where this becomes visible is in your Marketplace app portfolio.

Jira Cloud is built on a different architecture with different capabilities, limits and extension points. These architectural differences matter when it comes to apps because they shape what can be supported in Cloud and what cannot.

Several differences between the two platforms define the app landscape:

• Apps cannot run inside Jira the way P2 plugins do in Data Center
• There is no access to internal Java APIs
• There is no direct database access
• The REST API surface and authentication model are not the same

Many Data Center apps cannot run the same code or deliver the same features in Cloud. Scripted logic, workflow hooks, listeners, custom fields and integrations often behave differently or need to be recreated.

Some apps have strong Cloud equivalents, some have partial parity, and others have no Cloud version at all. The only way to avoid surprises later is to assess your portfolio early so that you have time to redesign or replace anything that will not make the move.

---

Assessing Your Marketplace App Portfolio

Start by pulling your full add-on list from Manage Apps and recording the key information in an Application Portfolio Tracker. At a minimum, capture each app’s name, owner, purpose, renewal date and cost. When describing the purpose, note both the use case and the size of the user base that depends on it. Since Cloud licenses are tied to instance size, this context helps you determine whether the value of an app still justifies its cost.

Jira Admin Tip:
If you have never maintained an app register, this is an ideal moment to start. A simple inventory of owners, purposes, usage patterns and renewal dates becomes a foundation for ongoing governance. It helps with cost management, rationalization and clear communication with your stakeholders.

---

Check Cloud Compatibility and Functional Parity

Once you understand what each app does, the next step is to determine whether it can transition to Cloud.

When you have a preliminary view of your app landscape, the next step is to validate it using the Jira Cloud Migration Assistant (JCMA). JCMA includes a built-in App Assessment module that scans your Data Center instance, identifies every installed app and cross-references each one against Atlassian’s Cloud App Compatibility database. It highlights which apps have Cloud versions, which vendors support automated app migrations, which apps require manual work, and which are not supported in Cloud at all. JCMA also surfaces vendor-provided migration guides, flags known limitations and gives you early visibility into apps that may introduce functional gaps. Running this assessment early, ideally before any detailed planning, provides a data-driven baseline that complements your own portfolio tracker and helps you avoid surprises later in the migration.

Outside of using JCMA, you can also review each app in the Atlassian Marketplace and check if a Cloud deployment option exists. You will find this in the “View for” dropdown on the app’s Marketplace listing. Switch to the Cloud view to see any vendor notes about differences, limitations or upcoming changes.

Next, review the support information at the top of the listing. If you see “Cloud Migration Assistance”, the vendor is actively supporting Cloud moves and may provide automated paths, documentation or direct support. If the app is marked only as “Partner Supported”, you may still be able to migrate but will need to contact the vendor for guidance.

Apps without Cloud availability or vendor support should be flagged early. They do not automatically block your migration, but they will require a plan that may involve replacement or redesign.

Record all findings in your Tracker. Add fields for Cloud version availability, compatibility notes and Cloud pricing since licensing models often change once you are in Cloud.

---

Decide What to Migrate, Replace or Retire

With these facts in place, begin assigning each app to one of three decisions: migrate, replace or retire.

Availability of a Cloud version is the baseline. Without a Cloud version, the app cannot move with you.

Feature parity is the next consideration. Most vendors publish parity guides that show which features remain unchanged, which features have been altered and which features have been removed entirely because Cloud cannot support them.
Functional overlap can also surface opportunities. Many teams discover they have multiple apps that solve similar problems. A migration is a natural moment to consolidate.

Cost is an important factor. Cloud pricing is often different from Data Center pricing. If you have a large user tier but a narrow use case, the cost-to-value ratio may no longer make sense.

For any app that is marked for replacement or retirement, document the alternative. This information becomes essential for testing, training and change management. Once you have recommendations in place, meet with each app owner to confirm the decision and capture any concerns before finalizing your portfolio.

---

Build a Simple Readiness Statement

The last step is to summarize what your assessment means in practical terms. A readiness statement does not need to be complicated. It should describe which apps will migrate without issue, which apps need configuration changes or functional redesign and which apps will not be part of the Cloud environment. Highlight any high-impact areas such as workflow tools, scripting-heavy apps or integrations that support business-critical processes. Note where user retraining or process adjustments will be required.

This summary becomes a communication tool. Stakeholders often ask whether the team is “ready for Cloud”. A clear readiness statement gives you an honest and structured answer that shows exactly what is staying, what is changing and what needs to be rebuilt.

If you are evaluating your own Marketplace apps and want a second opinion on where the risks might be, feel free to reach out. I am always happy to compare notes and share what I see in real migrations.