🆕 Subcomponents for Jira 4.0.0 is now on Atlassian Forge ✨

[#1]

Subcomponents for Jira Cloud was migrated to Atlassian Forge in 4.0.0, bringing enhanced security for users. Forge also allowed us to introduce features that were not feasible before: automated migration with JCMA for users moving from Jira Data Center to Jira Cloud, and feature parity between Data Center and Cloud (a public REST API and Packages on the issue view).

🔒 Enhanced security

For any third-party app landing on Jira Cloud, the honest answer to "where does the app's data live?" used to require a functional architectural diagram, an external AWS environment, and a full security review. Programs with hard budget deadlines don't have weeks for that. One enterprise Jira admin put it plainly in support: "we need the diagram now… hard deadlines for budget approval."

Subcomponents for Jira is now a Forge app – built and hosted on Atlassian's cloud platform. Subcomponents data (component hierarchies, versions, packages, property schemas, admin config) lives inside Atlassian Cloud, under the same trust posture as Jira itself. Data residency follows your Jira site's region, so GDPR alignment comes out of the box, and the app is now eligible for Atlassian's Runs on Atlassian program. Reliability fixes on release / unrelease, unarchive, gadget click-through, JQL functions, and admin modals ride along the same code-path move.

🧩 Automated migration with JCMA

For users still on Data Center and planning the move to Cloud, Forge unlocked a second thing: Subcomponents app data now migrates automatically through the Jira Cloud Migration Assistant (JCMA). Before 4.0.0, JCMA moved your Jira, but Subcomponents app data – hierarchies, versions, packages, admin config – had to be recreated by hand on the Cloud side. Fine at one project. Not fine at ten. One enterprise migration program put it in support: "349 projects using this feature… not feasible to do it one by one."

You install and configure JCMA in your Data Center Jira, run a migration that includes app data, and Subcomponents configs land on Cloud automatically – bulk works the same way for 1 project as for 349.

⚡ Feature parity with Data Center

For Cloud customers already running Subcomponents at enterprise scale, and for teams landing on Cloud via JCMA, Forge unlocked feature parity between Data Center and Cloud versions. Two specific gaps close: a public REST API and Packages on the issue view. A properties-page performance rebaseline ships alongside.

REST API

Everything that ran against the Subcomponents Data Center REST API – CI/CD sync, bulk maintenance scripts, service-catalogue integrations, post-migration reconciliation – runs against Cloud now. Endpoints cover reading and managing subcomponents, versions, and packages, in the same shape as the Jira Cloud platform REST API you already know.

Packages on the issue view

An issue's packages now appear directly in the issue layout. The Packages panel shows which packages the issue rides in without leaving the ticket, and updates as the underlying component and version relationships change.

Performance on large instances

Component and version properties pages – where you define fields on subcomponent hierarchies – used to take up to a minute to load on the large instances that hold the most schema-heavy data. On Forge, we treated the move as a one-time rebaseline: fresh code paths, no legacy debt. Properties pages that took up to a minute at 800–1000-component scale now load in seconds.

Worth a look

Whether you're evaluating Subcomponents for Jira on Cloud for the first time, running it at enterprise scale already, or planning a DC → Cloud migration, Subcomponents for Jira Cloud is worth a look – existing installs upgrade automatically, and the JCMA path lets Data Center teams test the app-data transfer against a real project before they commit.

---

From the Broken Build team behind Subcomponents for Jira Cloud