“Completely finished” is open to interpretation but “Nobody wants this” is definitely untrue - a number of partners have incremental adoption as a pillar of their migration plans. Others have already indeed opted for migrating in one swoop. There are a lot of developers on the planet with diverse requirements, preferences and perspectives.
2 Likes
It means full parity. No interpretation required.
Go ask them if they’re doing that by choice. And to get accurate feedback on Forge please make sure you’re talking to the developers writing the code.
Forge-based requirements for partner program began being announced in Oct 2024. If you want an accurate picture of voluntary Connect>>Forge migrations you simply need to go and look at what % migrated prior to then. I’d guess single digits.
And with this latest announcement we have an unreasonable and unrealistic short deprecation window that is inevitably going to be extended out for multiple years.
Partners who have experienced any of the dozen forced migrations in recent years are very aware of how poorly these migrations are managed, communicated and executed.
3 Likes
If you want a small glimpse into how poorly migrations are handled on this platform, here’s a taste of the 2+ year (and counting) Confluence v2 API migration which continues to have inadequate communication: Update to Confluence v1 API Deprecation Timeline - #25 by klaussner
And if you want a small glimpse into the production readiness of Forge, here’s a taste of how apps are being broken for end-customers with inadequate forethought or process: Reminder: Upcoming Sandbox runtime and UI Kit 1 deprecations - #15 by HeyJoe
To this day there continues to be no means for developers to update or notify customers to push them onto the latest major version of a Forge app. Meanwhile old Forge app versions are being deprecated and broken with zero UI fallback.
Damned if you do, damned if you don’t.
2 Likes
End of support for Connect until Q4 2026 still feels very rushed and we will still urge Atlassian to allow more time for this huge transition of our Connect apps and those of many other Atlassian Marketplace partner companies that make 100% of their revenue with Atlassian apps.
Like I mentioned before, Forge doesn’t feel very mature yet and it doesn’t look like the maturity is improving significantly since Forge was officially made GA back in 2021. We already faced 5 Forge bugs or incidents that were affecting us in 2025 alone, so not even within 3 months. This is with only 2 of our 15 apps on Forge and one app that we’re trying Connect on Forge with.
I know Atlassian is investing heavily into Forge, but unfortunately it’s still far from a comparable experience to Connect. It would be more reassuring to get Forge to a comparable maturity level to Connect first, before announcing any dates for its end of support. It would also release pressure on Atlassian to deliver all necessary Forge features at an acceptable quality level in time for all Connect vendors to migrate to.
15 Likes
Hi @SeanBourke
Thanks for the detailed reply. Regarding my question here:
You wrote:
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?
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!
10 Likes
Could you please clarify if the “Upload app” option (after ticking Enable development mode) will still be available for Connect apps or when will it be completely removed?
Thanks!
No it won’t, it is mentioned in the phase 2 description
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.