summary
- Connect end of support is being extended to January 31, 2027: Partners and developers now have additional time to prepare around holidays and annual planning cycles.
- Publish your migration plan: App developers should share migration plans with customers, so they know what to expect as end of support approaches.
- Connect will not remain in a steady state after end of support. Breakages will increase and compatibility gaps will widen, so the sooner you start your Forge migration, the more runway and support you’ll have.
Note: This post applies to Connect apps for Jira and Confluence. Bitbucket Connect end of support information can be found here.
Since we announced Connect end of support a year and a half ago, the app ecosystem has undergone a remarkable transition. Over 95% of paid app seats have been migrated to Forge, moving the Atlassian app ecosystem toward a more modern, AI-ready, enterprise-grade future.
We want to recognize the effort and investment made by partners and developers. You’ve made enormous progress to ensure customers can continue relying on the apps they know and trust, while taking advantage of everything Forge makes possible.
With just over six months remaining until Connect end of support begins, we want to make sure every Connect app maintainer has the information and support they need to take the next step. This post is your need-to-know guide to the transition, including:
- Key milestones, and the official end of support start date
- How to successfully navigate the move from Connect to Forge
- What happens after end of support begins
When is End of Support?
To give partners and developers additional time to prepare their apps, we’re extending the end of support date from December 2026 to January 31, 2027. This extension is intended to help teams plan around holiday breaks, annual planning cycles, and other competing priorities at the end of the calendar year.
When Connect becomes unsupported on January 31, 2027, Atlassian will only address critical security patches. Support SLAs will be relaxed, and Connect will no longer evolve alongside the Atlassian platform. Connect capabilities will also be subject to shorter deprecation windows and removed with significantly less notice.
To recap, several milestones in the Connect end of support timeline have already passed, with the final milestone approaching:
- January 31, 2025: Announced our intent to end support for Connect
- March 2025: Announced the end-of-support timeline
- September 2025: Stopped accepting new Connect apps on Marketplace
- March 2026: Apps with a Connect descriptor can no longer receive updates
- January 31, 2027: Connect end of support begins
How to ensure a smooth transition
If you’ve already made progress on your migration, thank you. We recognize the planning, engineering effort, and coordination this transition requires, and the work you’ve already done puts you in a stronger position for the next phase.
If you haven’t completed your migration yet, there is still time to move forward with a structured plan. The best place to start is by familiarizing yourself with the end-to-end process, identifying what remains for your app, and breaking the work into manageable phases.
As you plan your migration, there are three steps to work through:
| Step | What to do | What it means |
|---|---|---|
| Step 1: Convert your configuration file | Use semi-automated tooling to convert your atlassian-connect.json descriptor to a Forge manifest.yml. | This is the foundational step that registers your app as a Forge app. The tooling handles most of the conversion automatically. |
| Step 2: Publish a migration plan | Add the connectToForgeMigration module to your manifest file with a link to your migration plan (migrationGuideUrl) and your migration commitment status. | Replaces the generic Connect End of Support warning on the Connected Apps admin page with your own app-specific messaging and a link to your migration plan. |
| Step 3: Migrate your modules | In your manifest file, add a Forge module with the same key as the Connect module you’re replacing, then comment out or remove the Connect module. | Most Connect modules have direct Forge equivalents. You can migrate incrementally, one module family at a time. Some modules like macros, custom fields, and workflow validators have built-in data migration pathways. |
Forge Remote vs Runs on Atlassian
We know achieving Runs on Atlassian is an important goal for many partners, especially as a way to accelerate enterprise trust and procurement. At the same time, not every app is an immediate fit for Runs on Atlassian. Apps with complex backend architectures, external services, or specialized infrastructure may require a more incremental path.
Runs on Atlassian should not be a blocker to your Connect to Forge migration. For many apps, Forge Remote can be a practical first step or a long-term architecture that allows you to move to Forge while continuing to use the backend services your app depends on.
Migrating your Marketplace presence
Moving from Connect to Forge isn’t just a technical migration. It also involves planning how your listing and customers will move through the transition.
After completing Step 1, you can make your migrated Forge app the latest version of your Marketplace app listing, carrying over your existing listing and reviews. This listing succession happens behind the scenes, and your customers should not see any impact. Depending on your architecture and migration approach, customers may need to upgrade to a new version or approve updated permissions.
Finally, understand how Marketplace revenue share applies during migration. Revenue share is determined by the listed version of your app (Connect or Forge), not by whether every customer has upgraded. Once your Marketplace listing is updated to a Forge version, the Forge revenue share applies, even as some customers may still be completing their upgrade.
Partners may also be eligible for 100% discounted revenue share up to $1M in Forge lifetime revenue, which is designed to reward your investment and accelerate innovation on Forge.
Publish a migration plan
It’s important to give customers clear visibility into your Connect-to-Forge migration plans, including your intended timeline.
You can surface a link to your migration plan directly in Admin Hub by using the connectToForgeMigration Forge module and the migrationGuideUrl property. This helps admins understand your migration intent, right in the Admin Hub where they’re already reviewing app status. To use this module, your app must first convert to a Forge manifest. Full documentation is available here.
Eventually, we will begin surfacing your migration intent within app iframes. Please keep an eye on the Forge changelog for updates on the release timeline. We will provide advance notice and testing periods before this change goes live to customers.
What if a feature I need isn’t available in Forge?
We have been steadily working to deliver critical migration blockers over the last 12+ months, but we understand some blockers aren’t discovered until developers are in the last mile of their migrations.
Start by checking the FRGE public Jira project to see if your feature request has already been logged. We’ve recently completed an intake process to prioritize requests ahead of end of support. If your request isn’t there yet, you can submit it using this guide.
Keep in mind that requests submitted now are not guaranteed to be addressed before end of support takes effect. That said, submissions still matter; they give us visibility into whether a parity gap is significant enough to warrant attention.
FRGE tickets reflect the current status of each feature request, including transparency into which feature requests will be delivered and which are out of scope. If a scoping decision has been made and you think your use case wasn’t considered, please comment and let us know.
Not all Connect capabilities will be replicated in Forge. We prioritize feature requests that are clear migration blockers or result in serious partner or customer impact. Requests that have a workaround, affect a very small number of users, or are inconsistent with Forge’s product direction will not be prioritized.
Tips from the community
Hundreds of partners have already moved to Forge, and many have documented what worked and what they learned. These firsthand accounts are some of the best resources to help you plan your own path forward.
Migration stories from the ecosystem:
- Seibert Media: A detailed comparison of the Forge and Connect development models Atlassian Forge vs. Connect
- Move Work Forward: 5 Apps from Connect to Forge in 2 Months
- Titan Apps: How TitanApps Migrated Smart Checklist to Forge (and Got It to Run on Atlassian)
Beyond these posts, the The Atlassian Developer Community is an active space to ask questions and connect with developers who’ve tackled similar challenges.
What happens after end of support?
After end of support, only critical security vulnerabilities will be addressed and Connect feature deprecations will happen with little notice. As Jira, Confluence, and the broader platform continue to evolve, Connect will not evolve with them, and compatibility gaps will emerge and widen over time.
Post-end of support, Connect apps will not continue on in a steady state. Without ongoing investment, breakages will become more frequent, and the user experience will degrade. This includes incompatibilities with underlying platform infrastructure changes, some of which will cause apps to stop functioning without advance notice. Apps built on Connect will face increasing difficulty meeting the performance, security, and capability expectations that customers have come to expect from Marketplace apps.
We will share more detail on timelines and next steps for Connect beyond end of support. But the direction is clear: partners should not plan to maintain apps on an unsupported platform long-term. The sooner you begin your migration to Forge, the more runway you’ll have, and the more support we can offer along the way.
