It is not ideal no, but you can migrate all modules over to Forge, and end up with a not used remote. Then you can remove the remote at the end and start instructing people in the UI to update.
Ideal no, but it is doable, at least in my case and cases others shared with me.
Would this jump from 15% to 25% for the marketplace make vendors consider dropping the Pay via Atlassian program?
Is pay via vendor (e.g. paddle.com) still viable under forge/run with atlassian?
1 Like
No, it is not allowed per the Atlassian Marketplace Agreement (art. 3.1):
Paid-via-Vendor Apps may not be Cloud Apps, Data Center approved Apps, or any Apps you develop using Atlassian Connect or Forge, unless Paid-via-Atlassian Apps is not available for that product or is otherwise permitted by Atlassian in writing.
But given the recent ruling in Apple vs Epic Games, this might no longer be sustainable.
5 Likes
Hi Chris,
A honest question. Are you trying to incentivize partners to migrate to Forge today or in 2026? Because it sounds like you are trying to do first but actually doing second.
I think the most sensible option would be to set any amount earned from 1st Jan 2026 onwards to qualify for 0% incentive.
If it stays like as it is, we are definitely not hurrying to migrate to Forge this year.
6 Likes
With each new unrealistic timeline announcement it’s increasingly clear that there is severe internal miscommunication on the readiness of Forge.
The bridge is incomplete while you’re telling cars that it’s safe and they’ll be fined if they don’t drive ahead.
11 Likes
My app only use Forge modules with Forge Remote Connect backend. In our backend, we authenticate to external systems using OAuth2. Will this be eligible for Forge eligibility requirements?
FYI we have one app 100% ported to Forge and fully tested on staging environment. However, we decided to not release it. Why?
Because we do not see much upside by releasing the Forge version now and losing chunk of 0% incentives. Instead we will wait till December and hit the release button.
We are early adopters of Forge and this policy essentially penalizes us for taking risks on platform that was not ready.
13 Likes
With the current incentives I’ll be shelving any conversions to connect on forge, there is no financial benefit. We will be concentrating on full forge conversions or new Forge apps. We will be trying to release any Forge stuff as close as possible to 1 Jan as possible. I suppose any conversions could be to a connect on forge app with a single connect module that doesn’t do anything. Then on the 1st Jan, convert to full Forge
@ChrisHemphill1 If we convert a connect app to Forge and 99% of users are on the connect version (haven’t upgraded) then is all revenue (including that from the connect version) still at 0% or only those that upgrade to Forge?
6 Likes
While waiting for Atlassian to respond here (?), I wanted to highlight some posts I saw recently on other threads. It seems like the revenue share change is forcing a number of partners to ship crappier software to customers before it is ready, simply to avoid having to take a financial hit.
I believe DFTC is still considered a core Atlassian value, but the end result here feels a lot like FTC.
It would be nice if the revenue penalty could be deferred until (say) six months after the platform is ready for 99% of common use cases, to give vendors time to actually build stuff after Atlassian finishes its core platform work.
From RFC-94: Configurable Egress and Remotes - #17 by daviddrawio
And on this thread: Confluence DC -> Cloud Migration & Forge: Broken Macros
14 Likes
Thank you for all the comments and feedback. We appreciate the feedback and acknowledge the concerns raised by our partners.
As of today, partners have nearly 7 months before revenue share updates take effect on January 1. The updates were announced ahead of the usual 6 month window to give partners as much time as possible to choose the path that makes the most sense for them and complete any necessary development work.
Over the remainder of the year, we’ll continue to ship improvements to Forge that will help partners fully migrate. Our product teams are committed to working with partners to prioritize unblocking features and help partners move to Forge as quickly as possible. I see some of those blockers mentioned in this thread; we will reach out to those partners to discuss options.
Some partners are also weighing the best time to migrate to maximize the revenue share benefit - that’s understandable. Migration to Forge can vary in complexity from app to app. Some partners may need the full period between now and January 1 to complete the move, others may be able to do it faster.
One key benefit to migrating sooner: Runs on Atlassian just launched, and some partners may want to be among those featured apps. We are seeing a ton of momentum here and are excited to see more!
Bottom line, we would not recommend delaying migration until the last minute. As some have commented, migration can be done incrementally, and this helps de-risk the move by surfacing any hurdles and making progress well before January 1.
Hi Chris,
Unfortunately, you did not address our main concern. Why are you punishing partners
- who already migrated to Forge
- actively migrating to Forge NOW and not in 2026
You are recommending to migrate now, but actually incentivizing to wait and migrate in 2026. Can we get some clear explanation why it is done this way?
9 Likes
If Atlassian doesn’t start widely adopting Forge internally (dogfooding) for core feature development to the same extend as P2 is used in Data Center, I am pretty confident that the Forge platform is destined to ultimately fail while alienating many third-party developers with such narrow timeline when the majority of the platform is still half-baked. Not as “here and there” thing with small modules, but as a strategic decision by the company leadership with strict requirements for new major feature development.
12 Likes
We are not delaying the migration for the sake of delaying it:
- If we can move to Forge, it makes sense to delay because Atlassian is incentivizing it.
- If we cannot move to Forge, it is because we are waiting on Atlassian to resolve blockers.
Please stop making it sound like it’s our fault.
10 Likes
Runs on AWS. That badge is also Atlassian strategically shooting itself in the foot when it comes to AI.
Since all state-of-the-art AI models inherently involve egress it punishes and discourages any AI to be integrated into any marketplace app.
Atlassian’s competitors will happily take that market share.
Ditto with the competitive edge their developer ecosystems will have whilst we Atlassian developers waste time progressively migrating to an unfinished Forge platform for the next 3-5 years as the reality of the parity issues inevitably force endless deprecation extensions.
I think that Atlassian will push to Rovo as the best AI solution for companies using Atlassian stack. Forge app could then use Rovo as AI service and data will stay within Atlassian.
They’re egressing prompts to either OpenAI or Google Gemini.
That’s going to be dodgy if I discover that Rovo apps egressing prompts are qualified for “Runs on Atlassian”.
2 Likes
Hi @ChrisHemphill1 and the Atlassian Team,
I want to express some concerns and ask a few questions about the upcoming financial penalties tied to the Connect → Forge migration.
I’m sharing this from the perspective of someone who works closely with life science companies (pharma, medtech, biotech). These customers are sensitive to platform changes due to the computer system validation requirements imposed by the US FDA, EU EMA, and other regulatory bodies. [a]
Here’s what I’m seeing:
- In about six months, vendors who haven’t fully migrated their apps from Connect to Forge will start facing financial penalties.
- Forge does not yet offer all the same capabilities as Connect. This lack of feature parity is blocking many vendors from completing a full and proper migration. [b]
- Atlassian has not communicated a deadline for when the Forge team will establish enough feature parity to unblock migrations. [c]
- Despite no committed deadline for unblocking app migrations, Atlassian has set a deadline for completing app migrations. Having one deadline without the other is forcing vendors to choose between financial penalties and removing established features. [d]
- Even if Atlassian resolves the blockers before the migration deadline, vendors may not have enough time to react to the new features with responsible (unrushed) development. [e] [f]
- Forge itself, as it stands today, is also less stable than Connect. [g]
- All of the above is likely to lead to a period of instability across the Atlassian Cloud platform. [h]
- Customers will notice. Mature apps will suddenly become less stable, and some long-available features will suddenly disappear. When this happens in more than one app, it will only erode a customer’s confidence in the entire Atlassian Cloud platform.
- In regulated industries like life sciences, unexpected instability can create a downstream burden on customers:
- Customers may need to open CAPA (Corrective Action and Preventive Action) investigations if bugs or missing features affect validated workflows in Jira or Confluence.
- If enough CAPAs occur, the customer may need to revalidate their use of Jira and/or Confluence to remain in compliance.
- All of this will be expensive , disruptive , and time-consuming for the customer. And it could lead to some customers abandoning Atlassian Cloud altogether. [i]
A few questions for Atlassian:
- Can Atlassian describe what success will look like for a Connect → Forge migration from the perspective of the customer experience ? Is minimizing the impact on end users part of the success criteria?
Regarding a change of course:
- Is there still a chance to defer the financial penalties until six months after Atlassian reasonably resolves migration blockers? (As suggested by Scott Dudley.) That would give vendors time to make more responsible, less disruptive changes. [j]
- If a blanket deferral isn’t possible, can Atlassian at least grant a penalty exemption to individual apps that register an impediment?
If Atlassian chooses to stay on the current course:
- What messaging does Atlassian recommend we use with customers when the (highly probable) period of instability hits? Is Atlassian preparing for coordinated communications that will help maintain customer confidence in the overall platform?
- When a customer complains about a Forge-migrated app having fewer features than its Connect predecessor, will Atlassian publicly acknowledge the reason for the gap? Or will partners be left to deal with the fallout individually?
- Is Atlassian planning a formal communication strategy for customers in regulated industries who may need advance notice to plan for system revalidation? Better yet, can Atlassian help coordinate change management and revalidation for customers impacted by app migrations from multiple vendors? [k]
- Likewise, will there be coordinated support for customers conducting CAPA investigations who may need to understand, explain, and justify any patterns of instability across Marketplace apps?
I’m raising these questions because I care about the stability of the Atlassian Cloud platform and the companies that depend on it–especially those in regulated industries. My intent is to encourage Atlassian to take a closer look at how this accelerated migration strategy may affect customer experience and long-term confidence in the platform.
If there’s room to change course, then great. And if not, I hope there’s a clear plan in place for supporting customers and minimizing the impact on everyone. #DFTC
If you find any of my concerns to be unfounded or in any way unreasonable, then please correct me. I will appreciate the dialogue and having my mind set at ease. And if this isn’t the right place for this conversation, please do point me to a better channel.
Otherwise, I look forward to a thoughtful response.
Thank you for listening!
Notes:
[a] If Atlassian has any questions about the computer system validation requirements of life science companies, I’m happy to discuss them with you. Feel free to send a private message.
[b] Atlassian is aware of the existence of blockers and has acknowledged them many times, including in this thread.
[c] There are many strategies available to define “ready enough” feature parity. Atlassian and the partner community could agree to something if given the opportunity.
[d] This frustration has been expressed many times in this forum, including in this thread.
[e] I understand vendors received 7 months’ notice of the Jan 1 deadline. And I agree that vendors can and should start the migration work immediately (and most are). However, given the existence of blockers, I don’t understand the assertion that Atlassian is giving vendors "as much time as possible " to “complete any necessary development work .” That’s unfair, to put it mildly.
[f] The timeline for releasing unblocking features should also include time for iteratively requesting bug fixes from the Forge team. I hope that’s an Agile principle we can all agree with.
[g] That is not a disparagement of Atlassian. It’s an observation of the current reality. Forge is more stable this year than last year. But it has not yet stabilized. For example, Atlassian’s Incident History lists nine (9) Forge-related incidents in the past 60 days. There is only one Connect-related incident listed in the same period.
[h] That’s not a criticism of Atlassian or any vendor. It’s just an acknowledgment of how software development works:
New platform + new implementations + rushed timelines = higher likelihood of defects.
[i] Another downstream impact will be keeping life science companies on Server/DC. Many of Atlassian’s large life science customers have not finished the move to Cloud. If this disruption happens during their migration process, they’ll abort and stay on Server/DC. Others will see what’s happening and not even consider a move to Cloud.
[j] Disruptive either through significant bugs or removed features.
[k] If Atlassian doesn’t proactively do this, the burden will fall on customers by default.
18 Likes
Great post @AaronMorris1! Thank you for putting this together from the regulated health care/life sciences customer perspective.
Your insights that these customers are especially sensitive to churn and instability are spot on.
I hope the leadership at Atlassian will weigh the risk of lost cloud customers in regulated sectors against the cost savings of early retirement of Connect.
Chris Cairns
Digital Rose
2 Likes
In addition to all the suggestions made by @AaronMorris1, I would also like to ask @ChrisHemphill1 what the rationale is behind the revenue change for Connect?
Surely, Atlassian does not believe the Marketplace Partner community needs further incentive to migrate to forge given that Connect will be effectively end-of-live after Phase Two, when descriptor change will no longer be propagated and manual install will be disabled, in March 2026.
Why even bother making this change for a period that will effectively only span 3 months?
Those who will not migrate to Forge before March 2026 will probably stay on Connect indefinitely and the revenue change will not make the difference in terms of incentive. Given that Atlassian will drop support of Connect, the additional funds generated by Atlassian will not go into maintaining Connect.
So why make this change?
NB: this is specifically about the Connect part of the rev share change, not the Forge part
4 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.