Switching from jira:jiraDashboardItems (Connect-style) to jira:dashboardGadget (native Forge)

[RustemShiriiazdanov]

Hi all,

We are migrating our Connect on Forge app to Forge now. Our app creates Jira gadgets on customer Jira Cloud instances, and we are concerned about if these gadgets will safely migrate to Forge. The reason is we already had a minor bug after we migrate from pure Connect to Connect on Forge (our vendor name is not rendered at our gadgets anymore), so we briefly discussed the topic with Support, and the answer was:

Switching from jira:jiraDashboardItems (Connect-style) to jira:dashboardGadget (native Forge) is a significant change — it involves rewriting your gadget using Forge UI Kit or Custom UI, and there is currently no official guidance covering how to preserve existing gadget instances already placed on customer dashboards (configuration, state, placement). Gadget key changes between module types could result in existing gadgets being lost from customer dashboards, which would be highly disruptive. We would not recommend pursuing this path until there is clear official guidance on the migration.

Also, when we asked will existing Connect gadget preferences/configuration be preserved when migrating to jira:dashboardGadget, the answer was

Based on what the engineering team has shared: the same preferences are passed to Forge gadgets as to Connect gadgets, so in principle the configuration data should not be lost during migration. However, this has not been formally documented or validated at scale, and we’d caution against treating this as a guarantee until official guidance exists. The key risk remains around gadget key changes between module types — if the key changes, existing gadget instances on customer dashboards may be lost.

So we are a bit worried now if anyone had any troubles with their gadgets content migration when moving to Forge. The support recommended us to post to Developer Community to ask if anyone can share tips on migrating existing Jira dashboard gadgets (the ones already configured by customers on their instances) content during Forge adoption?

Regards,

Rustem

[AaronMorris1]

@RustemShiriiazdanov – This is not an answer to your immediate question, but I wanted to point you to another thread in the forum:

Tell us what you need before Connect EoS: Submit your critical migration blockers

TL;DR As we approach Connect end of support in December 2026, Atlassian product teams are focused on delivering the remaining features you need to migrate. We’re in the process of building the roadmap that will take us through to end of support, and we want to ensure the features that matter the most to you are included. Timely action required: “Request review” (via the bottom right Issue Context) on all existing Forge feature requests in the FRGE project that are relevant to your Apps. The …

If Atlassian Support told you this:

The key risk remains around gadget key changes between module types — if the key changes, existing gadget instances on customer dashboards may be lost.

Then that might be reportable as a valid migration blocker. (Unless someone chimes in with a positive personal experience.)

[RustemShiriiazdanov]

@AaronMorris1 oh that’s useful thread indeed! Thanks!

[rmassaioli]

My team implemented support for this in full. Many partners have performed this migration successfully before.

Can you let me know where you were looking for documentation as I’ll get my team to look into improving the documentation this week coming? I’ll also be talking to support to know what additional they want to see to have further confidence.

Thanks for bringing this to our attention.