Announcing Connect End of Support: Timeline and Next Steps

[scott.dudley]

Hi @SeanBourke

Thanks for the detailed reply. Regarding my question here:

@scott.dudley

What are the pre-requisites for each phase?

You wrote:

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.

I think it is worth pointing out that Atlassian is “waterfall-ing” the timeline, but “agile-ing” the development. I understand that the agile part will never change, but it is also why I am prodding a bit at the pre-requisites and timeline.

The pre-requisites for phase 1 should be irrelevant for most people (anyone who has a Connect app in development will surely list it before the deadline), so I will skip that part.

What are the pre-requisites for phase 2, when Atlassian stops supporting Connect descriptor updates? Or phase 3, when Connect enters end-of-support? I see estimates on the roadmap for various features, but I do not understand what Atlassian considers a pre-requisite and what is a nice-to-have.

I recognize that you might also only be able to give fairly vague descriptions of those pre-requisites at this point (rather than talking about specific features or capabilities). But to the vendor’s ear, saying “we will prioritize whatever we can by the deadline” is effectively making no commitments at all. I am assuming that these would be big picture answers, like “x% of apps with more than Y users will be able to fully adopt Forge”, “less than Z install platform outages per month”, or other responses of this style.

For phase 2, you wrote that you will be “prioritizing as many items as you can prior to the enforcement of the phase”. I think we all understand this, but it does not get to the core question: the concept of “what can we prioritize?” is fundamentally different from “what is an actual pre-requisite to jump to this stage?”. The former refers strictly to your development velocity, while the latter refers to the actual missing pieces that vendors need to allow their existing apps to continue to work on Forge. We have no control over the former, but we certainly know what we need for the latter. All that is to say that I do not think vendors know what Atlassian is committing to here (or at least I do not).

Atlassian originally committed that “before we enter a phase, certain readiness pre-requisites must be met”. Listing these pre-requisites in plain text creates accountability on Atlassian’s part, and the trust relationship with vendors needs that.

It also seems that by the definition of “pre-requisite”, the phase date needs to be pushed if you do not meet those requirements. Otherwise, if you go ahead with the phase anyway because the date has arrived, it never actually was a pre-requisite to begin with…right?

@scott.dudley

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?

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.

To perhaps clarify my question, I am not asking about what gets prioritized, or suggesting anything about using incremental adoption or not. Let’s take phase 3 as an example (but it applies equally for the other phases):

• Atlassian has some pre-requisites for phase 3
• Phase 3 (Connect going EOS) will take place on 2026-12-31
• How soon before the deadline (2026-12-31) will Atlassian commit to delivering the last changes required by those pre-requisites?

For example, if Atlassian is pulling the plug on Connect support on 2026-12-31, can Atlassian commit to delivering those phase 3 prerequisite features no later than (say) two months earlier, which (in this example) would be 2026-10-31?

Vendors need time to build and test and deploy the changes required to work with new Atlassian implementations. If the deadline is 2026-12-31 but the final changes are shipped on 2026-12-30, vendors cannot turn that around on a dime.

This concept seems to have been missed in other recent Atlassian migration project timelines, so I am just asking Atlassian to consider this in its internal timelines for Forge, and to do the right thing here (and make a public commitment about it to vendors).

Thanks!