Thank you all for your candid and detailed feedback. We’ve read your responses carefully, and we want to address the concerns raised here in a single, consolidated reply.
Why are we doing this?
Several of you have asked where the obligation to warn customers is coming from. There isn’t a single source - Atlassian has responsibilities under both enterprise contracts and regulations in a number of jurisdictions, but we also want to make sure our customers have material information they need to comply with their own legal and regulatory requirements.
When Connect reaches end of support, apps still running on the framework will no longer receive functional fixes for product drift, SLOs will be reduced, and deprecation timelines will shorten significantly. For enterprise customers, many of whom must maintain SOC 2 and ISO 27001 compliance, running software on an unsupported framework is a material risk that can put them at odds with their security posture and audit requirements.
We are currently receiving direct inquiries from enterprise customers asking how to identify which of their installed apps still rely on Connect components. We, both Atlassian and our partners, want to ensure we don’t put customers in a situation where they feel unprepared. We acknowledge that partners are investing heavily to migrate, and we have attempted to balance customer disclosure timelines to provide as much time as possible for partners.
What are the mechanics and how will this work?
In saying the why, we recognise that much of the concern stems from a lack of clarity around what exactly customers will see, when, and for which apps. That’s fair feedback, and we have updated our documentation to clearly outline the full end-to-end experience. We will enable the messaging in the Developer Canary environment so you can test the experience, prior to any customers in production seeing it. The messaging you saw last week is the default that appears when no migration status has been set.
Admin experience (i.e., Connected Apps page) vs. iFrame messaging
We hear the concerns about iframe messaging loud and clear and want to clarify the current plan:
-
Connected Apps page messaging (visible to admins): This will roll out first and is the least disruptive surface and serves the main goal of admin awareness. A default message will be sent, but if you adopt the connectToForgeMigration module, you can state your migration intent and add a URL to share your communications (e.g., a migration plan/page). This will help show customers you understand the situation and give you the ability to communicate your actions. By doing this, the message will change into an informational banner rather than a notice. Additionally, if we detect that the latest version of an app is running on Forge, we will prompt admins to update their app in the messaging.
-
Iframe messaging (visible to end users): We will send out a changelog at least 2 weeks prior to this change going live and we are currently considering delaying this based on your feedback, but it will need to go live by the end of September at the latest. That said, we are additionally considering scoping this more narrowly based off the inputs we get around migration intent and we recognise the need to get the tone right, so we will be revisiting the language based on your feedback.
Why end users and not just admins?
The reality is admins are often not the day-to-day users of an app, and may not be aware of which apps their teams rely on most. The iframe messaging ensures the people most affected by potential changes are informed, so they can raise it with their admins and plan accordingly. Given your feedback, we are aiming to modify the iframe messaging for partners who have declared intent so that it also surfaces that context to end users. Our goal is transparency for customers while ensuring partners who are actively migrating are represented fairly.
The triaging process
We’ve been deliberately transparent about how we’re prioritising Forge feature requests because we want you to have full visibility into our thinking and decisions.
I want to clarify what our triage labels actually mean, because I can understand a ‘rejected’ label can feel disheartening when you’ve invested time raising a ticket and may have app functionality riding on the outcome.
The core question we’ve been asking when triaging each ticket is: “Would we consider blocking or pushing back the end-of-support timeline if this feature wasn’t available on Forge?”
-
‘Accepted’ tickets are ones where we agree there’s genuinely no viable way to achieve the use case on Forge today and the ramifications of it would affect several partners or apps. Marking them as accepted helps us prioritise internally and secure the resources needed to deliver them.
-
‘Rejected’ tickets are not issues for which we would block the end of support of Connect for. This is because we believe an alternative path exists to achieve the same/similar outcome or it means we simply will not be supporting the functionality on Forge. We’ve done our best to call out our reasonings and any alternative solutions directly in the ticket comments so it’s actionable and testable for you.
A ‘rejected’ label does not mean we’ve stopped caring about the ticket, and it absolutely doesn’t mean we’re dismissing the reality that the alternative can sometimes be a suboptimal experience. Many rejected tickets have since landed, and several more are actively in progress. Robert and myself are continuing to prioritise as many tickets as we can across different teams at Atlassian. However, if we have rejected a ticket, it means we don’t currently see it as a blocker to migrate given the use cases that have been provided to us through the submission process. Whilst we understand that might be frustrating, it reflects our honest assessment of what’s needed to move forward with migration versus what we interpret to represent longer-term improvements to Forge.
The intent behind this exercise was never to close doors. It was to give you clear visibility and clarity into how we’re weighing priorities internally, so you can plan with more confidence.
Connect end of support date
We’ve announced end of support will land in December 2026, and we are in discussions to finalise the exact date. We are taking partner feedback into account, including end of year holiday staffing and code freezes and are considering pushing this back by a small amount to avoid these periods. We will provide formal comms, including a confirmed date for end of support, at least 6 months in advance.
What previous comms have customers received?
Up until now, our customer-facing comms, including emails, blog post, and documentation, have focused on private Connect apps built by customers for their own use, to ensure in-house Connect developers are aware of end of support timelines. More recently, we made admin-facing messaging live in production for non-public apps. This has been deliberate so that we can give our partners as much time as possible to complete your migrations. In all of these comms so far, we’ve been clear that customers don’t need to worry about their Marketplace apps, as partners are responsible for handling those migrations.
With end of support approaching, we believe it’s now the right time to start extending this messaging to include Marketplace apps, giving customers enough runway to be informed and prepare for changes that may affect them.
How do Connect apps declare their intent to migrate?
The new connectToForgeMigration module is only available to apps with a Forge manifest, meaning your app needs to be running as Connect on Forge to utilise it. You can adopt a manifest and this module while still running essentially all of your Connect components; you don’t need to have fully migrated to benefit from it. Additionally, as prefaced by our end of support milestones, you can no longer update Connect apps, so technical constraints also apply to this app category.
If you believe your situation is unique and something is preventing you from adopting a Forge manifest, please reach out to me at esood@atlassian.com. I’d be keen to understand your constraints and explore whether there’s a path forward we can take together.
Timelines
May 26th 2026:
- We rolled out these changes for the admin experience to non-public apps in production. Changelog can be found here.
June 4th 2026:
- We will enable this feature for the admin experience messaging on the Connected Apps page for the Developer Canary Program tenants first, so you can test the messaging, adopt the new module, state your migration intent and guidelines, and ensure the admin-facing messaging accurately reflects your app, all before any customers see it.
- During this period, we encourage you to update your migration guidelines and adopt the new module if you haven’t already.
- Separately, Connect EOS submission requests will be closing so we can lock in scope (more comms on this shortly). That said, we’d still encourage you to continue submitting FRGE tickets as it gives us valuable signals on where you’d like to see Forge go in the future. However, at this point, we can’t guarantee any new requests will land before Connect reaches end of support.
July 6th, 2026:
- We will gradually start to roll out admin-facing changes over 3 months. Apps that have not indicated an intent to migrate to Forge will see this messaging first, giving partners who are already on the journey more time before their customers see anything.
- Apps that are blocked by an accepted Connect EOS ticket will be exempt from customer messaging until one month past the delivery date of that feature, to give you time to adopt it.
Late September 2026 at the latest:
- For apps we identify as migration risks, we will enable end-user iframe notices. We will issue a changelog notice at least 2 weeks prior to this change going live.
Looking ahead
After end of support, Connect will not simply continue running at 100% indefinitely. Teams within Atlassian will no longer be obligated to maintain Connect-specific functionality, SLOs will be reduced and deprecation windows will shorten. Connect will degrade over time as it falls behind Atlassian platform capabilities, and there will be an impact on app experiences.
Our goal is not to damage partner trust or customer relationships, it’s to ensure everyone has the information they need to stay informed and plan ahead.