Announcing Connect End of Support: Timeline and Next Steps

Announcements
, , , ,
1

Hi everyone,

Today we’ve published Announcing Connect End of Support: Timeline and Next Steps as a follow up to our earlier blog Taking the Ecosystem Forward: An Update on the Future of Connect. This announcement is intended for developers of Connect apps, including partners and customers with custom apps. It provides a detailed view of the phases and timing for the end of support of Connect.

I’d like to thank all of the partners and customers who submitted feedback through the survey, conversations in the community and conversations at Atlas Camp. We’ve detailed learnings from the feedback provided in the blog post and have published additional resources to help simplify planning for migration.

The start of the deprecation notice for Phase One (No new Connect apps on Marketplace) has been announced today and will come into effect on September 17, 2025. From this date, all new apps published on Atlassian’s Marketplace must be created on Forge and may not contain any Connect modules. Existing Connect apps on the Marketplace are not impacted by this change.

Subsequent phases and their associated dates are detailed in the blog post, as well as additional details and resources.

10 Likes
2

Hi @SeanBourke,
Could you clarify the plan regarding features marked as “not planned” on Forge?
To be more specific, is there any chance that these features might still be considered and delivered before Phase 2 (No new connect updates allowed), or does “not planned” mean there is no intention to bring them to Forge at all?
We expect a high level of transparency on these aspects, as we must plan the next steps properly.

For example, what happens if some apps - like ours - have a hard requirement currently classified as “not planned”? By hard requirement, I mean that no workaround or technical solution would allow migration without the feature being supported on Forge.

3 Likes
3

These features are not actively planned for development in the short to medium term and may not be delivered on the Forge platform due to the virtue of limited existing utilisation, alignment to Forge security principles.

With that said, the more we understand the need, utilisation and criticality of these from partners, the better we can reassess the priority and importance of these features. If an existing FRGE ticket exists, I’d suggest leaving the comment about how you’re unable to move to Forge without the feature and the implication of it not being available.

3 Likes
4

Hi @SeanBourke , thanks for the transparency and I appreciate that many capabilities are already available in Forge!

However, I’m a bit confused about the following: in the Jira capabilities section of Other capabilities, there’s a list which contains all the DevOps related modules and lists them as “Under consideration”. The linked issue FRGE-472 has requested these modules in 2021 already and has been updated today by mentioning that a few of these modules already exist but aren’t officially documented. For example, devops:buildInfoProvider or devops:deploymentInfoProvider seem to be the equivalent for jiraBuildInfoProvider and jiraDeploymentInfoProvider. Even Atlassian’s own Forge app Jenkins for Jira with 8k+ installs is using these modules in its manifest.yml.

Since the DevOps data is also important for Jira, I’m wondering why this is just “under consideration”? What are the things holding you back to use the existing modules and make them official, so everyone’s on the safe side and can use them? This is especially important because there are quite a few Connect apps in the marketplace using the Connect DevOps modules and probably need them in order to migrate. I just had a look at the Connect descriptors of the first six apps when searching for “devops” and three of them are using those DevOps modules, including the one with 10k installs.

2 Likes
5

Hey @SebastianHesse,

Great question. The note on the ticket is correct, these modules are undocumented as they were originally built and spiked for validation in Atlassian’s DevOps apps such as Jenkins for Jira. They are discoverable through the public repo for this app; however without without clear documentation and release notes accompanying them, they also would not come with the assurances around deprecation and change notice periods.

More broadly, Atlassian is on a journey with the Teamwork Graph and this may influence how Forge apps will interact as Open Toolchain providers. We’re working closely with the appropriate team to express the importance of these capabilities to apps, partners and developers.

2 Likes
6

Hi @SeanBourke ,

Thanks for your answer! I was somehow expecting this kind of response and your note on the Teamwork Graph :grinning_face: Unfortunately, it’s a bit vague at the moment and does not help the developers who want to use these capabilities on Forge, so I hope that there’s a clear path available soon, whatever direction you take (either supporting it via Teamwork Graph or making the unofficial modules official or something completely different).

4 Likes
7

Hi @SeanBourke

Thanks to you and the team for posting this update. I was wondering if the community could get a couple of clarifications about how all of this is intended to work, specifically related to pre-requisites and pricing:

1. Pre-Requisites and Deadlines

During the initial announcement, Atlassian emphasized the following:

Before we enter a phase, certain readiness pre-requisites must be met.

I didn’t catch any pre-requisites in the announcement from this week. I looked at the various roadmaps too, but it is not clear as to what Atlassian thinks is an actual prerequisite, and the only thing I found was this one note on the diagram from this week’s post:

”100% of Connect Apps can start moving to Forge” [listed in diagram as Q1 2025]

So, to ask this and related questions more directly:

  • What are the pre-requisites for each phase?
  • If Atlassian does not meet the pre-requisites for a phase, will Atlassian commit to extending the deadlines of that (as well as the following) phases?
  • In the case of feature development, how much lead time does Atllassian commit to giving vendors between the pre-requisites being delivered and the start of the subsequent phase? (By “delivered”, I mean: being shipped and rolled out to 100% of clients.)

For example, if Atlassian delivers a key functionality on 3/30, but the next phase starts on 3/31, vendors cannot reasonably use and test the feature with such a short turnaround. The delivery and final rollout dates need to be significantly before the official start of the next phase.

The above types of issues represent the very real problems that vendors have faced with other Atlassian projects, so I hope that providing advance clarity here will help set expectations.

2. Final pricing

With Connect officially going away, can you confirm that final, complete and platform-wide pricing will be announced for Forge no later than June 30, as (I think) was previously promised?

Also, the Forge app revenue share is an integral part of pricing and I believe vendors need to see this soon (and ideally at the same time as Forge resource pricing). Can Atlassian provide a date for when this will be delivered?

At the end of the day, vendors care about the TCO of the app, and the revenue share is one of the most significant factors. If you price Forge compute on the cheap but the revenue share doubles (or vice versa), then vendors need to know.

Final pricing can also be a significant factor on deciding whether to use certain Forge components or not, and this is a decision that needs to be made upfront, before planning a migration and making certain technical decisions.

Thanks!

7 Likes
8

@SeanBourke / @asridhara / @danielwinterw,

Even though it is clear that a lot of thought was put in the article, the wording is still a bit confusing.

When Atlassian talks about 100% of Connect apps can start moving to Forge, which is part of the timeline diagram, can it please elaborate what this means?

I assume this means that 100% of Connect apps can start moving to Connect-on-Forge by using Connect modules in a Forge manifest.

Atlassian has indicated that Forge will not have feature parity with Connect:

Our objective is to deliver key use cases that can be achieved on Connect to the Forge platform, and most Connect modules have a Forge equivalent today. However, there are some Connect modules or use cases that we do not plan to deliver, in cases where they are no longer fit for purpose or appropriate on the Atlassian platform.

Which makes the statement that 100% of Connect apps can migrate to Forge a bit confusing, because in some cases this is only true if they continue to use Connect modules.

The reason this is confusing is also because Atlassian is mixing Connect and Connect modules. For instance, the Phase three: Connect enters end of support seems to mean that Connect apps enter end of support, but the wording itself refers to Connect modules.

Which somewhat makes sense because the real end of native Connect apps is actually in phase 2, when automated descriptor updates for Connect apps are turned off and the option to manually install Connect apps from the UPM is removed.

So Phase Two should actually be called Connect enters end of support and phase 3 should be called Connect modules enters end of support

There is also no mentioning of what happens to native Connect apps after end of support:

  • Will they be removed from the Atlassian Marketplace?
  • Will they continue to operate?
  • Can they still migrate to Forge?

May I remind Atlassian that even though Server products end of life was on Feb 15, 2024, Atlassian is still providing extended support to customers (I believe the current deadline is Feb 15, 2026), customer are still able to download & install server versions, the UPM still supports (manual) installation of Server apps and Server apps are still on the Marketplace (with the deadline postponed indefintitly).

Even after Server end-of-life, Atlassian has provided customers a way to continue operations for more than a year (with no end in sight), yet it expects Connect apps to migrate to Forge well before the end-of-life date without any option to migrate afterwards.

Can Atlassian please give clarity with regard to:

  • the effective end of life date of native connect apps
  • the effective end of life date of connect modules on forge
  • the migration path to forge for native connect apps after end of life

It would be great if it can apply the same grace period to Connect apps as it is giving Server products, just so that Atlassian and Marketplace Partners can both make sure that our mutual customers do not end up getting f*cked.

10 Likes
9

In ECOHELP-58674, we’ve raised that the same REST resources couldn’t be both authenticated by Connect and Connect-on-Forge (@ContextJwt and @ForgeRemote annotations), and that they could change the code just a little to allow this. Atlassian answered:

Our engineering team confirmed that this is an intentional behavior. They suggested your app has separate endpoints annotated each for Connect and Forge, and then have a method that servers the common functionality and its called from the endpoints.

Which means 100% apps can use Connect-on-Forge, as long as they rebuild ALL their plugin to have Forge-only endpoints that are NOT used by Connect, i.e. share 0% of the routes. It means, even to use Connect-on-Forge, it requires refactor of 100% of the app.

As Atlassian’s engineering team confirmed: This is intentional.

3 Likes
10

@aragot I just wanted to share my experience with a connect-on-forge app that is also being expended with forge only features/endpoints

While it is true that @ContextJwt and @ForgeRemote cannot be used on the same endpoint in your Connect app to support both Connect and Forge invocations, this only applies to endpoints that you invoke using Forge invoke or invokeRemote from a function, or if you use the remote as an endpoint in your Forge manifest.
You can adopt connect-on-forge with by simply converting your Connect descriptor to a Forge manifest, without the need to refactor any of your endpoints.

However, now comes the tricky bit, once you are connect-on-forge and want to move features from the Connect app to the Forge app, then this is the point where it will hurt a bit as you can’t reuse the same endpoints, but instead will need to implement a new route to support this Forge specific endpoint.
Not sure what framework you are using for your Connect app, but in case this is built on Spring, then maybe you can use the headers or params attributes of the @RequestMapping annotation to create separate endpoint routes for Connect and Forge, without changing the actual path of the endpoint.

2 Likes
11

@markrekveld is correct that you don’t need to make any changes to the endpoints for Connect-on-Forge - that’s only required once you start making Forge Remote calls from a Forge UI frontend, e.g. via invokeRemote.

@aragot that was my call about not being able to have both @ContextJwt and @ForgeRemote sit on top of the same endpoint, on the general principle that it’s risky to have flexible authz code that opaquely takes a different path depending on the input - it recalled for me the issue that led to having @ContextJwt in the first place, as well as the widespread JWT vulnerability from a few years back wherein an attacker could gain access to vulnerable resources by setting typ to none. As it is today, those two annotations can do their job without needing to make allowances for the other possibly also being active on the same resource.

Using the @RequestMapping annotation sounds like a great way to simplify our suggested approach to handle this.

1 Like
12

Is it possible to include the reasoning for “not planned” items and to include alternative solutions for typical associated use cases in https://developer.atlassian.com/platform/adopting-forge-from-connect/connect-forge-equivalences/connect-forge-capabilities-notavailable/?

For example, it is not entirely clear whether it is possible to conduct a typical third-party oauth flow with “Popup Support” as “not planned”.

13

Hey @scott.dudley,

Internally, we’ve aligned on prerequisites which we plan to deliver for each phase - these align between our roadmap objectives/timeframes and the deprecation dates which have been indicated in the blog post.

We don’t want to enact a phase if some partners are missing key capabilities. However we have to leave flexibility to make decisions and re-prioritise if needed. For phase one, which prevents new Connect apps from listing in the Marketplace, we are prioritising pre-requisites like Offline User Impersonation, Confluence Events, Confluence Background Scripts and Data Residency which are critical components that cause some partner to opt for Connect today.

While Phase Two only requires apps to move to a Forge Manifest, we understand that a lot of apps will use this opportunity to transition into Forge. We’re assessing the items which are Under Consideration to ensure they are the most critical unblocking capabilities for apps. We’ll be prioritising as many of these as we can prior to the enforcement of this phase.

It depends. The implication of each phase differs and the associated capabilities may impact that phase, or support phases later one (i.e. Offline User Impersonation is important for many new apps while also being important for existing apps moving entirely to Forge). If the feature has significant adoption on Connect and does not exist on Forge, we’ll explore the implications. If it has limited use on the Connect platform, then this may be less likely.

We are prioritising capabilities which are utilised by the broadest groups of apps first, ensuring that as many apps as possible have everything they need. You can find more details of these on our ROADMAP.

With the ability to incrementally adopt Forge from Connect, it would be wise to start sooner and go as far as you can, rather than waiting for everything to be available before you even start looking into Forge.

The latest guidance for finalised Forge pricing details remains to be announced mid 2025.

14

Hey @lexek-92,

Thanks for the feedback. We’ve received further feedback regarding popup support from other partners and are continuing to discuss this internally.

The removal of the allow-popups CSP would mean that apps can effectively open any popup to any location. Today, we support redirection to URLs which have been pre-defined in the manifest without a user warning. If we were to commit to level setting this rule for popups, it would require us to only permit popups where an app has defined egress to * within their manifest. Does this seem reasonable given the constraint and would help in your circumstance?

Please follow FRGE-561 for continued updates.

15

Hey @remie,

That’s correct, this indicates that all existing Connect apps can now move to the Forge platform by way of Connect on Forge. This would suffice for phase two, in which marketplace will no longer poll a remote descriptor for any app updates.

At this stage, End of Support is a state at which the Connect platform has no support beyond critical or security related bug fixes. We will likely see components of the Connect framework disappear over time. For example, as our products continue to evolve, it is likely that they will deprecate support for Connect in key areas. We expect to provide notice to customers if they are running apps on a non-longer supported platform.

Apps would continue to operate in the way the do today, however would be at increased risk of facing any emerging bugs (as support is limited to critical / security related bugs) and may face increasing deprecations. For this reason, we’ve noted this as use at your own risk.

Apps would still be able to migrate to Forge at the stage where phase three is implemented, as it is the primary pathway for continued support.

Partners and developers are free to make their own determinations about when (or even if) they migrate existing Connect apps to Forge; however we view it as a hazardous decision to delay action on the possibility the deadlines will shift. The earlier partners transition to Forge, the more deliberate and less risky the migration will be. Partners who transition early also ensure their capabilities don’t lag behind our platform.

16

@SeanBourke thanks for getting back to me!

Apps would still be able to migrate to Forge at the stage where phase three is implemented, as it is the primary pathway for continued support.

Just so I understand this correctly, Connect-on-Forge with Connect Modules will remain available even after phase 3? This is important because of the smooth transition to forge with the minor version update when moving verbatim from Connect to Forge (without scope changes, etc).

Can you please confirm this with a yes or no answer?

The earlier partners transition to Forge, the more deliberate and less risky the migration will be. Partners who transition early also ensure their capabilities don’t lag behind our platform.

This seems like a bit of a catch-22 at the moment. Partners that migrate early might get surprised by missing features or migration pain (like the fact that there is no clear path for data migration, see also Taking the Ecosystem Forward: An Update on the Future of Connect - #42 by remie).

I think many of the questions in this thread is partners trying to figure out the best window for migration based on the timeline and the availability of features.

1 Like
17

The funny thing is that I was thinking of migrating forge app to Connect app

18

Hi Sean,

  1. It may also be worthwhile to make a page where vendors may submit their Connect app descriptors and review the migration path for each module or lack of thereof
  2. Popup is just an example, many people may run into the same questions with different modules, and it would be nice to have these things laid out in the documentation
  3. As per popup, it’s sounds like a big overcomplication and you may be missing the point of question. We want to do a very standard OAuth login flow with a static set of third-party services. I am not even sure if we need the sandbox parameter for it, but this pattern should be common enough to have an established “best practice” approach or to have an understanding that any reasonable solution is currently impossible
19

Most of the requirement appear to revolve around Connect/Forge feature parity, but are there any maturity and reliability guidelines set for Forge advancements, which may or may not be associated with any phase?

While we appreciate the transparency, the sheer amount of forge related incidents is truly concerning, especially the ones related to the app installation process, when many potential customers may be forever lost.

Apps would continue to operate in the way the do today, however would be at increased risk of facing any emerging bugs (as support is limited to critical / security related bugs) and may face increasing deprecations. For this reason, we’ve noted this as use at your own risk.

At this moment, with the exception for deprecations, Forge does seem to be the platform where vendors are much more likely to run into emerging and obscure bugs.

2 Likes
20

Nobody wants this. There’s not a single developer on the planet who wants to spend years incrementally migrating their apps. Incredible waste of time.

How about Atlassian completely finishes the Forge platform so that developers can 100% migrate apps in one swoop?

2 Likes