Marketplace revenue share updates: 2026

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:

  1. In about six months, vendors who haven’t fully migrated their apps from Connect to Forge will start facing financial penalties.
  2. 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]
  3. Atlassian has not communicated a deadline for when the Forge team will establish enough feature parity to unblock migrations. [c]
  4. 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]
  5. 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]
  6. Forge itself, as it stands today, is also less stable than Connect. [g]
  7. All of the above is likely to lead to a period of instability across the Atlassian Cloud platform. [h]
  8. 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.
  9. 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:

  1. 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:

  1. 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]
  2. 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:

  1. 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?
  2. 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?
  3. 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]
  4. 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.