Tell us what you need before Connect EoS: Submit your critical migration blockers

Announcements
1

TL;DR

As we approach Connect end of support in December 2026, Atlassian product teams are focused on delivering the remaining features you need to migrate. We’re in the process of building the roadmap that will take us through to end of support, and we want to ensure the features that matter the most to you are included.

Timely action required: “Request review” (via the bottom right Issue Context) on all existing Forge feature requests in the FRGE project that are relevant to your Apps.

The triage process will be run for a limited number of times, and then we’ll lock in decisions to protect the stability of our commitments.

We will run this triage process only 3 times over 3 months starting in March and then freeze decisions.

Why we’re doing this

We’ve spent the last few years investing heavily in Forge and closing the most important Connect → Forge gaps. We’re now less than 10 months away from Connect end of support, which is a critical window, where we need to:

  • Ensure Connect apps can migrate to Forge

  • Protect customer safety and continuity

  • Provide a clear, auditable “line in the sand” about what will and will not be done before Connect end of support (EOS)

To do that, we’re introducing a formal decision process for any remaining Connect → Forge parity gaps and migration blockers that partners want us to consider before EOS.

What we will consider before Connect EOS

We’re putting a clear decision framework in place so the most critical work is prioritized. To be approved before Connect EOS, a request must clearly fall into one or more of these must‑have categories:

  • Customer safety & continuity
    Prevents data loss, access loss, or severe workflow breakages for active App use cases.

  • Migration unblocker
    Directly enables or unblocks a viable migration path (typically to Forge) for an App that would otherwise have no workarounds or mitigations.

  • Material risk reduction
    Mitigates high or critical operational / security risk with clear evidence or incident history.

How the decision process works

We will run 3 triage cycles (monthly) and then stop. Each cycle will:

  1. Collect partner requests via FRGE labels

    • Partners identify the Forge tickets they want us to review for pre‑EOS consideration.

    • Action for you: fill out the “Request review” form on each of those FRGE issues; even if other apps have already done so.

  2. Monthly triage and recommendations

    • We review all issues that have not yet been accepted or rejected.

    • For each, we decide whether to recommend:

      • Approved (before EOS)

      • Rejected (not before EOS; possibly later, or never)

    • We apply the criteria outlined above and consider customer impact, blast radius, and feasibility.

  3. Final decision and governance

    • The recommended decisions are reviewed and approved by the internal Connect EOS decision leads.

    • We aim to be conservative by default: only requests that clearly meet the bar will be approved. When submitting your requests, please be specific about impact, urgency, and why the request is a true migration blocker.

  4. Record and communicate the outcome

Once a decision is marked as Approved or Rejected, changing it will require a re‑review and strong justification in line with the categories above. This is how we maintain a stable and predictable delivery plan for remaining blockers.

What we need you to do (Call to Action)

To ensure we’ve captured everything you consider critical before Connect EOS, we need your help now.

1. Review your existing Forge / migration blockers

Please review your current Forge feature requests, Connect → Forge parity gaps, and migration blockers in the FRGE project (the public Forge issue tracker).

Focus especially on issues that:

  • Block migration off Connect, or

  • Would cause serious customer or business impact if left unresolved before EOS.

2. “Request review” on the issues you want us to consider

For each FRGE issue that you want considered as part of this final Connect EOS decision process, please:

  1. Ensure the FRGE ticket is clearly written:

    • Problem statement and user impact

    • Affected workflows and customer types (especially enterprise / high‑impact customers)

    • Why this is a migration blocker or major continuity/safety risk

  2. Click the “Request review” button, found in the Connect EOS Feedback issue context module on every issue, and fill in the form.

Screenshot 2026-03-05 at 9.37.13 am
Screenshot 2026-03-05 at 9.37.13 am435×172 12.4 KB

Filling in this form is critical, it is the only way we will pull partner requests into the formal Connect EOS triage.

Important:

  • Please only use “Request review” for genuine EOS‑relevant blockers, not for general “nice‑to‑have” improvements.

  • If you’re unsure, err on the side of including it once, but be prepared that we will be strict in the evaluation.

3. Watch for status updates

After you have requested a review:

  • We will move the issue through these states (in a field you can see on Connect EOS issues context):

    • Under Consideration → being reviewed as part of a triage cycle

    • Approved → considered in‑scope for pre‑EOS work

    • Rejected → not planned before EOS (may still be considered later, or remain out of scope)

  • We will also add a public comment on the FRGE issue explaining the decision and reasoning.

How you’ll know what made the Connect EOS roadmap

We’ll keep the following public pages updated as the single source of truth for Connect → Forge equivalence decisions:

Over time, these pages will reflect the final set of commitments leading up to Connect EOS. Think of this as an easy to access copy of the source of truth. The source of truth is the status on the FRGE tickets.

What this is not

To set expectations clearly:

  • This is not a new, open‑ended feature program for Connect.

  • This does not guarantee that every tagged request will be approved before EOS.

  • This is not a commitment to full, one‑to‑one parity for all Connect capabilities.

It is a structured, time‑boxed way to:

  • Capture your most critical remaining migration blockers, and

  • Make transparent, auditable decisions about what we will and won’t do before Connect EOS.

Closing

We know many of you have already invested heavily in Forge and have been working closely with us to highlight gaps and blockers. This process is about honouring that work, being explicit about what remains, and giving you a clear final picture as you plan the remainder of your Connect → Forge journey.

Action requested:
Please review your FRGE tickets and in the “Connect EOS Feedback” issue context, fill in the “Request review” form for any issues you want us to review as part of this final Connect EOS scope setting process.

If you have questions about whether a particular gap qualifies, you can raise them in the comments on the FRGE ticket or here in this thread so we can clarify how the criteria apply.

FAQ

Question 1: Do my comments in the “Request Review” form get posted publically?

You have the option in the “Request review” submission form for your review comments to be Private (only available to Atlassian’s) or Public (placed as a comment on the Jira issue).

Screenshot 2026-03-06 at 11.47.21 am
Screenshot 2026-03-06 at 11.47.21 am1128×334 31.4 KB

In terms of your data, we also put the App / Partner into issue entity properties to allow our administrators to quickly generate views of which FRGE tickets impact which Apps / Partners.

Question 2: Where do I find the “Request review” button?

Every FRGE ticket will have a “Connect EOS Feedback” Issue Context module, inside that module is the “Request review” button:

Screenshot 2026-03-06 at 9.27.27 pm
Screenshot 2026-03-06 at 9.27.27 pm2552×1120 341 KB

Question 3: I have searched through the FRGE project and can’t find an appropriate ticket that tracks my problem, what now?

Please create a brand new FRGE ticket and then fill in the “Request review” form for that new ticket. Feel free to copy-paste information from the description you wrote for the FRGE ticket if that is appropriate and lets you fill in the form faster.

2 Likes
We need to talk about the revenue share deadline
2

We are blocked from migrating even for a relatively trivial app due to an obscure bug in Forge (ECOHELP-103491), which is taking months even for the Forge development team to figure out and with not clear timeline for resolution. This also blocks us from attempting to migrate more complex apps, which will likely have more blockers related to the platform limitations.

3

Thanks for the feedback! While we of course review all ECOHELP tickets, I would strongly recommend that every Partner try and migrate all of their apps as soon as possible to find the full set of issues that they might be impacted by. It would be unfortunate if you did discover more issues afterwards, but that it was too late for us to do anything about it. This process will only run for three months.

When you do find issues, please make them FRGE tickets and follow the process above.

I have also reviewed your ECOHELP ticket and I think they are about to get back to you with a change you can make to your app that may unblock you. I’ll leave further communication to the ECOHELP ticket.

4

Migrating from Connect to Forge Remote is a major update and as you know customers are pretty slow on making that manual update. For that reason we had to leave the Connect modules in the app and our backenbd still has to serve our Connect UI.
After Connect EOS, what do you plan to do for the customers that are slow enough to remain on the Connect version of an app?

1 Like
5

Hi! My team spent a lot of time and effort to eliminate that problem. Moving from Connect to Forge should not require Admin approval if we are considering egress changes or even most scope changes: Minor version updates (Connect to Forge)

If you are having problems, or is not working for you, can you please raise a new thread in here and my team will promptly assist: Adopting Forge from Connect - The Atlassian Developer Community

1 Like
6

I want to clarify how upgrades work today to ensure that people that are reading this and have not seen Minor version updates (Connect to Forge) can understand what it unlocks.

The Golden Rule
Whether your app is on Connect or Forge, the rule is simple: If upgrading from Version A to Version B does not increase permissions from the customers perspective, the upgrade can be automated.

  • Connect to Forge: The system automatically evaluates old Connect versions against the latest Forge version. If permissions match, it migrates them automatically over a 10-day period.
  • Forge to Forge: You can trigger these upgrades yourself using the CLI command: forge version bulk-upgrade start -e production.

Example Scenario
Let’s look at a hypothetical app with the following version history, where F is the latest version and it is preceded by 3 Connect and 2 Forge versions:

  • A, C, D: Permissions match version F according to the link I provided previously.
  • B, E: Permissions differ from F, so they cannot be automated.

The Outcome
Here is what happens when version F is released:

Current Version Upgrade Action Result
A (Connect) Auto-migrates F (Forge)
B (Connect) Cannot migrate B (Connect)
C (Connect) Auto-migrates F (Forge)
D (Forge) Bulk upgrade (CLI) F (Forge)
E (Forge) Cannot migrate E (Forge)

Conclusion
Most partners will find that their old versions automatically move to the latest Forge version. However, for versions like B and E where permissions have changed, you will need to encourage customers to manually click the upgrade button to accept the new permissions.

1 Like
7

This https://ecosystem.atlassian.net/browse/FRGE-1495 is huge blocker for all Confluence macro apps to migrate as Forge macros have a problem with performance.

I included a screen recording in the comment, please check it out.

5 Likes
8

There is one clear blocker - lack of consideration for integration testing against real Jira installation. We cannot safely migrate our more complex apps without migrating test suites, which are built as Spring backend tests, and are not E2E, which would take significantly much more time to run and wouldn’t cover all test cases.

1 Like
9

Simple. OAuth asApp.

2 Likes
10

I must say this one particularly interests me as the PMs have showed it to me in the backlog but nobody has explained to me what the use case really is? Also, as far as I can tell, apps should be able to use Forge Remote to achieve this still?

Please make sure that your follow the process above and “Request review” in an appropriate FRGE ticket if you have not already.

11

I think it would be good to specify to what extend “is blocked to migrate to RoA compatible” is part of the scope of this effort. Because it seems like “can use Forge Remote” will kill most stuff that vendors consider blocking.

12

Regarding OAuth asApp:
It’s gotten really quite boring explaining to the successive PMs who take this one over and having to explain from the beginning each time.

I spoke to lots of people from Atlassian at AtlasCamp in Brussels.

Rohit Eddy knew about it quite well when he owned the problem, but it has moved to others now.

In March 2025, it was going to be worked on in the next 3 months. So far this next 3 months seems to be rolling continuously.

This was me investing my own time & money (not some public corporation ‘s money) in the problem.

I’ve wasted an incredible amount of energy not being listened to by Atlassian (the entity, this is obviously not about individuals), I’m really at the point that this is a big waste of some of the remaining time in my life — conveying the same thing over and again and hoping for a different outcome.

Please go and have a look at the issue. It’s well documented in there.

1 Like
13

Hey @rmassaioli, this one is another blocker that feels like it should be easy to fix:

14

Hi Remie,

I think the “Request review” form gives a clear answer here:

Screenshot 2026-03-06 at 8.35.46 am
Screenshot 2026-03-06 at 8.35.46 am1158×564 46.6 KB

In short, the goal of this process is to help every App get to Forge. If you can maintain your apps functionality with Forge Remote then that is a legitimate path to getting to Forge.

It is very likely that any request where the primary purpose is to achieve Runs on Atlassian will be “Rejected” by the above process. To be clear, “Rejected” in this process means that it is not considered in scope for End of Support of Connect, not that it won’t ever be done. “Rejected” means that you can’t rely upon this being done before End of Support.

3 Likes
15

Rolling releases (RFC-106) isn’t a nice-to-have feature, it’s the foundation of versioning that was severely overlooked from day one of the Forge platform.

Anyone migrating to Forge before that is GA is shooting themselves in the foot because it results in the majority of your installs running outdated versions with zero practical method for you to ever update them.

I could list dozens of other blockers but maybe start with versioning first smh.

16

If you have dozens of other blockers, please make sure you use “Request review” on the relevant issues in the FRGE project. I very much want to know what they are!

One of my main goals with this process is clarity. It helps everyone to know exactly what is and isn’t in scope for Connect end‑of‑support so you can plan with confidence.

For example, you’ve raised feedback about Rolling Releases before. If Rolling Releases ships and somehow doesn’t fully meet your needs, that could leave you with very little time — and limited options for either you or us to adapt. Calling that out early gives us the best chance to address it.

Also, what if the rest of the Developer Community has their needs met but one of your many blockers you are referring to turns out to be a problem that only you had? Then we would miss it and you would be forced last minute to find an alternate solution. Better to know early if we were planning to have it in scope or not.

So, for any Forge tickets where you’re talking about Rolling Releases, or where you see other blockers, please use “Request review”. That’s the signal we will rely on to prioritise and respond for the Connect EOS.

17

You would be mad to even begin migrating until rolling releases is GA.

I’m not even convinced that it will solve the terminal problem because the feature itself also requires manual admin approval when deployed.

Let’s say you have 1024 installs and 50% (it’s much lower) of admins manually updating the app over 6 months:

  1. You very carefully map Connect to Forge permissions: 1024 installs running latest.
  2. You mess that up once (there are CDAC threads): 512…
  3. You add Rolling Releases (intended to solve this problem): 256…
  4. Scope names or requirements change (has happened): 128…
  5. Deprecations change scopes (has also happened): 64…
  6. You modify an Oauth provider client ID: 32…
  7. You add a new feature that requires a scope change: 16…
  8. You add/change a remote URL: 8…
  9. You switch that free app to paid with 100% conversion: 4…

If you’re lucky the 512 admins that manually updated the first time continue to subsequently update, but you get the point of how this spirals for every app on the marketplace.

–-

*Edit instead of adding another reply: this is the #1 blocker. If you have migrated your app to Forge already you have sentenced it to this inevitable fate. Nothing else matters if your app installs effectively go to zero as the outcome of migrating to Forge.

Also bulk-upgrade is not the solution to any of this; if a permission scope changes it requires manual admin approval.

Connect largely didn’t have this problem because scopes were READ and WRITE. Forge is trying to apply a permissions model that works in iOS (1:1 individual user control) to a completely different model in Atlassian (1:n admin multi-user control). If the admin doesn’t manually update the app then it will never update for any user.

I’ve had discussions with the Forge team and I’ve shared data to prove this is a terminal problem but I’m yet to see any workable solution.

18

@nathanwaters I know you are annoyed (rightfully so) at the version management issues, but I’d suggest focusing on actual blockers right now (what @rmassaioli is looking at). There are still gaps between Forge and Connect that cannot be worked around, and this is much more severe than the release issue, which has been also bad on Connect. Some of the examples you mentioned can also now be fixed by using the bulk-upgrade CLI command. Especially adding a scope in error and afterwards removing it, should be fixable through bulk-upgrade now. That this should be the default is another discussion, but not really blocking to adopting Forge. Some FRG tickets really are full on blockers that needs to be addressed as soon as possible though. E.g. FRGE-971, FRGE-1661, FRGE-1513 and others.

1 Like