RFC-129: Surfacing Partner Migration Plans to Site Admins for Apps Running on Connect

General Request for Comments (RFC)
,
1

RFCs are a way for Atlassian to share what we’re working on with our valued developer community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.

Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!

Project Summary

As we approach Connect end of support (EoS) in December 2026, it is critical that customers are informed about any apps they have installed that run on a platform that will be unsupported by the end of the year. While there is still time before this deadline, we want to engage with you early to ensure we build the right mechanisms to support you and your customers through this.

  • Publish: 19 March 2026

  • Discussion: 26 March 2026

  • Resolve: 9 April 2026

Problem

We recognise that as we eventually ramp up communications to customers regarding Connect EoS, it will likely drive inquiries to your support teams, and site administrators will look for answers from partners. If we do not provide a standardised way for you to surface app specific migration guidance where site admins will see these messages, we anticipate the default reaction will be to raise a support ticket with you to ask, ‘What do I do?’ or ‘Is this app safe?’.

We want to solve this information gap to prevent unnecessary friction for administrators and reduce the support load on your teams**.** To assist with partner supportability and ensure a smooth transition, we want to provide an opportunity for you to explain your specific migration status directly within the messaging that customers see.

We are exploring a capability that allows you to provide us with a URL that details your app’s specific migration plans. We would then surface this link to site administrators within the product, allowing you to have a way of addressing common customer questions before they are asked.

Important context: This feature and the associated customer messaging are not going live immediately. We are sharing this proposal now because we want your input on what information you need to provide us to effectively manage your customer base when the time comes.

Proposal

We are currently exploring introducing a standardised messaging component in the Atlassian Administration experience that informs customers if an app is relying on elements of a platform that will be unsupported by the end of the year (i.e., Connect). This will apply for any apps that a customer has installed which are utilising Connect modules, including pure Connect apps and Forge apps with Connect modules.

Our proposal is to provide these site administrators with a URL provided by you that details any necessary information regarding your progress to Forge in the messaging they will see. The primary surface where we intend for this URL to be displayed is the Connected Apps page where administrators can view details about their installed apps.

We are currently evaluating the best technical implementation for how you will supply this URL to us, but the core outcome remains the same, we want to drive traffic from the message directly to a page you control.

By linking to an external page you own, you can provide dynamic updates on the status of your app. We envision you using this space to communicate:

  • Status: ‘We are working on it’ vs ‘Ready to migrate’, etc

  • Timelines: If customers can expect to see a Forge version before the end of the calendar year

  • Actions: Specific instructions for the admin (e.g., ‘Upgrade to the latest version’, ‘No action needed yet’)

  • Support: How site admins can contact your support team, documentation, FAQs, or any other resources

Asks

We are seeking your feedback on the inputs you need to provide us to make this successful. We want to ensure that the ‘hook’ we build into the product is sufficient for you to manage your customer base and support load.

We are open to your suggestions, but in particular, we want to understand if this approach with a URL is enough. Please provide your opinion on the following:

  • Does a link to your site give you enough control to manage customer questions and actions?

  • Would you need specific status flags, like “We will migrate to a supported platform by end of year” displayed directly in the messaging that customers will receive in the Atlassian UI?

  • Would you want different versions of your app to provide different URLs?

As mentioned previously, we are currently evaluating different methods for partners to provide us with this URL. One option under investigation is enabling this capability through the Forge manifest. Due to its technical design, this functionality cannot be made available to apps using a Connect descriptor. Instead, for apps with a descriptor, our thinking is to instead guide customers to upgrade to the latest version of the app or contact partners directly for any questions.

  • Would having the partner-owned URL feature available through the Forge manifest meet your needs?

We’re interested in your feedback on whether this approach would work for your use case!

Out of scope

  • Immediate deployment of this feature/customer messaging - this RFC is for planning and feedback. Customer facing changes will not occur now

  • Changes to the overall Connect EoS policy, dates, or communication strategy.

  • Automatic detection or inference of recommended migration paths

  • Enforcement of the content hosted at developer‑provided migration URLs. If no URL is provided by a partner, we will simply default to your marketplace listing as a starting point for customers to get more information

  • Building full migration tooling beyond linking to developer‑owned experiences.

  • Broad UX redesign of surfaces beyond the new/updated components required for this proposal.

  • Any changes to billing, licensing, or entitlements associated with Connect or Forge apps.

2

Hi,

Would it be possible to explore using the Marketplace listing for partners to provide this information?

Since most customer-facing details are already surfaced there, it feels like a natural place to handle this. It could also help keep a clearer separation between app deployment and customer communication.

Screenshot 2026-03-19 at 8.48.55
Screenshot 2026-03-19 at 8.48.551802×1590 258 KB

I’m also not sure how large a share of apps are purely Connect vs Connect on Forge, but I’m wondering if introducing this through the Forge manifest fully addresses the problem. Apps that are purely Connect are likely a bigger concern than those that are already partially migrated.

-Janette

5 Likes
3

“Status” should also include a clear way to communicate to the customers if migration is blocked by the platform limitations.

4 Likes
4

The URL approach shifts hosting, design and maintenance burden to every partner individually, with zero consistency for admins comparing dozens of apps. Instead, add a structured status field to Marketplace listings (“migrating by X / no action needed / contact vendor”). You control the UX, we control the content. Works for pure Connect apps too, no Forge manifest required.

Separately, partners cannot publish honest timelines without a public Connect→Forge parity tracker. Key capabilities are still missing in Forge with no committed dates. Without that, any status mechanism just generates more questions than it answers.

3 Likes
5

We’re OK with the URL. We already have a page where we inform customers for some specific upcoming changes (custom fields, REST API tokens, manual installs in our case). So having it also visible trough the marketplace is a plus in terms of communication for us.

To answer the other questions:
Yes, a URL to our site gives enough control.
Having a status flag is OK, but not that important.
One URL should suffice for us, no need for different versions.
No preference on where to provide the URL (Forge manifest, Marketplace UI, …)

6

A status flag would be helpful, especially if one of the values conveys the message: “We want to move to Forge but we are blocked by Atlassian”. Customers who are requiring Forge adoption may not see anything beyond a “not ready yet” status or realize that a vendor’s inability to move to Forge is outside of the vendor’s control.

If the goal is to reassure customers, the high-level information should be able to include statuses that do so. I imagine that having this status flag would be ultimately helpful in Atlassian’s internal reporting too.

For the mechanics of setting this data, the Forge manifest is not a great place to put it. It moves what should be management metadata into the deployment artifact. It also offers no way for pure Connect apps to offer this information, as you noted.

Why is Atlassian not just adding fields to the existing Marketplace migration info API? This API already takes a bunch of URLs that the vendor supplies and exposes them to the Marketplace, so it seems like the logical place, and vendors are already familiar with it.

7 Likes
7

Hey Janette,

Thanks for the feedback and for raising these points.

For this proposal, our current thinking is to surface partner-provided URLs directly in the in‑product messaging, so admins can go from the message straight to the source of information without needing to move through another surface. Marketplace will continue to be a useful source of customer‑facing app details, but for this flow we’d like to optimise for a single, direct, low‑friction path from the message to the partner’s guidance.

Marketplace has also not been opinionated about surfacing an app’s underlying platform to customers (for example, we don’t currently indicate whether an app is Connect, Connect‑on‑Forge, or Forge). From a customer perspective, those platform distinctions are not always meaningful, and adding that signal now could introduce confusion or unintentionally discourage installations of apps that do have a migration path.

On your point about pure Connect vs Connect‑on‑Forge apps: for apps that are still purely Connect (and therefore don’t provide a partner URL via a manifest), we are currently exploring the possibility of surfacing actions in the message such that it would either encourage customers to upgrade to the latest version of the app where the latest version runs on Forge, or direct them to contact the partner for their migration status. Would this approach cover what you’re looking for?

8

Thanks for your feedback on this. We do acknowledge that there are cases where migration may be blocked by current platform limitations. As an aside, we’re actively working to be more transparent with partners about where we are drawing the line for Connect to Forge work before end of support, so you have a clearer view as well.

In particular, we’ve kicked off the Connect EOS triage process described here: https://community.developer.atlassian.com/t/tell-us-what-you-need-before-connect-eos-submit-your-critical-migration-blockers/99433

This process is in flight now, and is designed to:

  • identify the remaining critical migration blockers that we’ll consider before Connect end of support

  • make explicit, auditable decisions about what you can expect to be delivered by December 2026

  • give partners a stable picture of the final scope, so you can factor it into how you plan migrations and how you communicate timelines and constraints to customers

When we go live with this messaging, we expect the above information to give partners additional clarity to draw on when communicating with customers. We are currently exploring the option of having structured statuses to surface in the messaging itself as there seems to be an appetite for it.

9

Hey Nick,

Thanks for your feedback. We hear the concern around creating a consistent experience for admins.

Our current thinking is to explore adding the structured status options directly into the in‑product messaging (e.g. “migrating by X”, “no action needed”, “contact partner”), so that admins get a consistent experience without needing to leave the surface. For this to work reliably and at scale, our current exploration reveals the most viable path is making this available through the manifest, which would give us a standardised way to collect and display that information consistently across all apps.

We envision the URL that partners provide to be additive information for the customer. In scenarios where partners already have their own way of notifying their customer base about planned migrations, this solution allows them to reuse their existing structure. For others who may not have the same methods of notification, we won’t necessarily restrict the type of URL provided to us, in theory, this URL could be hosted on platforms like Google, GitHub, or even another Confluence page.

I recognise this doesn’t solve for pure Connect apps out of the box. As noted in the earlier thread, for those apps our proposal is to surface actions that either encourage customers to upgrade to the latest version (where it runs on Forge) or direct them to contact the partner. We’re open to feedback on whether that gap is acceptable or needs a different approach.

Regarding your last point on missing capabilities, I’ve mentioned above that we’ve kicked of the following process: https://community.developer.atlassian.com/t/tell-us-what-you-need-before-connect-eos-submit-your-critical-migration-blockers/99433. Please engage in this as we want to give partners explicit decisions on what will be delivered before December 2026. Our aim is that this gives you enough clarity to form realistic timelines and expectations rather than generating more questions.

10

Hey Edwin,

Thank you for your feedback, it aligns with our current direction of surfacing a partner provided URL as the primary method to link customers from the in-product messaging to your migration information. As always, open to any other feedback that may come across your mind.

11

Hey Scott,

It seems like there’s an appetite for conveying structured status options so we will take this on board. As mentioned above (and I can also see that you have already been engaging), we have this process set in motion to give partners explicit clarity on what will be delivered by Connect EOS, which should help inform and aid the status values.

On your point about the Forge manifest not being the right place for this data: we hear the concern about coupling management metadata with the deployment artefact. The manifest was our initial exploration because it gives us a standardised input, that’s reliable and scalable, and works for publicly available and in-house/bespoke apps. We’re still taking feedback like this on board as we evaluate the right mechanism so thank you for sharing!

12

Hi,

I think we’re talking past each other a bit, so let me clarify what I meant.

I’m not suggesting that users should go to Marketplace as part of this flow. I agree with the goal of having a single, direct path from the in-product message to the relevant guidance.

My point was about where the information is managed. Since Marketplace is already the place where app details live, it would make sense for the partner-provided URL to be stored there as well, alongside the rest of the app metadata. Then the product (e.g. Confluence) can pull it in and surface it.

My screenshot was only to show how this data is pulled from Marketplace, and displayed in Confluence.

For pure Connect apps, your proposed approach sounds reasonable as a fallback. As long as partners have a clear way to provide guidance once it’s available, that works for me.

13

I’m going to add my $0.02 here…

I agree with all of the folks saying - let us manage it in the marketplace. Our marketing peeps are already there. Our devs don’t want to handle the tweaking of text.

I would suggest perhaps doing a full interstetial on the page that folks have to be annoyed by when they need to upgrade. It’s our current main problem. We’re activley trying to get 40% of our install base to upgrade. However they either don’t know who their admin is OR they’re not taking our messaging as a real warning. Anything that can be done to get admins to take active actions would be awesome!

/Daniel

6 Likes
14

Yeah, we’ve got the same situation. Showing banners, messages with deadlines, and advertising new features doesn’t help much. It’s all up to the admins…

3 Likes
15

Yeah been banging on about this for years. Nobody taking it seriously.

ADMINS DO NOT MANUALLY UPDATE APPS!

If you have already migrated your apps to Forge they are now locked in a terminal spiral where your customer base will trend toward 0% of installs ever running the latest version.

I built and deployed Forge apps on UI Kit 1 and watched as Atlassian deprecated that, changed permission scope requirements and even the naming of scopes. This forced multiple major version upgrades completely outside of my control. Those are zombie apps now with the majority of installs forever stuck on outdated versions. One future deprecation or scope change is all it takes, and we all painfully know how often deprecations occur on this platform.

Effectively the migration sets in motion the destruction of your existing customer base. You may fix bugs and deploy new features but over time (deprecations, scope changes, Connect EOS etc) those customers will just cancel the subscription if the end-users are always running outdated legacy versions. Admins don’t manually update but they do regularly cull apps with low usage to cut costs.

Nor have I seen any mention of what the plan is when the Connect platform is completely switched off. Most installs will still be running on Connect because admins won’t click the update button. Meanwhile Atlassian have said legally they can’t ever automatically click that button for admins. That incompatible bind will be a disaster. Admins never manually update + Atlassian can never automatically update. Is anyone thinking about this stuff?

Atlassian’s proposed “solution”: Rolling Releases. That’s still in EAP despite the fact that partners are already being unfairly hit with revenue penalties for not migrating. And the moment you do adopt rolling releases presumably that triggers a new major version which requires manual admin update - docs don’t make it explicit despite changing permissions section in manifest.

And the Forge team have stated that rolling releases is taking inspiration from the way iOS manages permission scopes. iOS works because it’s a 1:1 relationship between the developer and the individual user. Confluence/Jira apps are obviously 1:n where the org admin is the gatekeeper for whether n users install the latest version. Poor model to take inspiration from.

So the entire ecosystem is being forced to migrate to a new platform that hasn’t yet figured out how updates and versioning works. That should have been carefully designed and deployed on day one.

Ok not great, well has Atlassian implemented any sort of admin app update notification system? Nope, nothing. Are developers given any practical communication methods to contact those admins? Nope, nothing. The only path available is to plaster apps with warning messages or make outdated apps unusable for end-users, but those end-users have zero control over that app update process.

Imagine an iOS app stopped working on your phone and you had to go ask permission from someone you may not even know. That’s the model here. Will that user manage to both identify who the admin is AND convince them to update the app? Or will that user just stop using the app? I think they’ll just stop using it. And the next time the admin does a cost-cutting sweep they’ll identify low usage and uninstall that app. Scale this scenario to the entire Marketplace and it’s not going to end well.

In regards to this thread: yes, you’re going to need a 10,000 word textarea for partners to explain to customers why an app hasn’t yet migrated to Forge because Atlassian’s deadlines and messaging are inconsistent with the technical reality and readiness of the platform.

8 Likes
16

Hi Janette,

Thanks for clarifying – that’s helpful context.

Just to add a bit more colour on our side: one of the constraints we also need to solve for is that this information should be made available for private / in‑house apps as well as public Marketplace apps. With private apps not having Marketplace listings, relying on Marketplace as the point where information is managed would mean we would likely need to build and maintain a separate path just for private apps. Given that this feature will be most useful, likely until the end of the year when Connect becomes unsupported, we’re aiming for a solution that works consistently across both public and private apps, while still providing a single, direct path from the in-product message to the partner’s guidance

17

Hey Daniel,

Thanks for sharing your feedback! Just to quickly clarify, your devs won’t need to tweak text as we would surface the URL provided. Afterwards, as long as the URL does not change, any context can be altered on that page without your devs needing to push changes for your manifest.

We’re also planning an admin-focused CTA (e.g., ‘Upgrade app’) when we detect the latest version is on Forge. This would help serve as an actionable next step rather than just an informational prompt. Would this help your concerns?

18

I mentioned this above but wanted to check if this would help your concerns with admins:

We’re also planning an admin-focused CTA (e.g., ‘Upgrade app’) when we detect the latest version is on Forge. This would help serve as an actionable next step rather than just an informational prompt. Would this help your concerns?

19

Thanks for the context on private apps, Eshaa.

I’d push back a bit on treating private and Marketplace apps as equally in need of a platform-level solution here. For private apps, the developer and the admin are typically within the same organization. The communication path to say “hey, there’s a new version, please upgrade” already exists outside the platform. A Slack message or a ticket should do the job.

The structural problem is with Marketplace apps, where there is no direct line between the partner and the site admin. Often we don’t know who the admin is and we can’t reach them.

During Atlas Camp, it was shared that after 3 months less than half of the installations are upgraded to the latest version.

7 Likes