Deprecation of Forked Repositories Outside the Parent Workspace

[#1]

[Pinned Update 12/19:] Thanks for the feedback. We understand this is an adjustment to your development processes. Therefore, we wanted to let you know we are listening and will have more updates to share in January. This will include additional details about your options for managing existing cross workspace forks and the timeline for when cross workspace forks would be automatically migrated.

[Original Post]

Hi Bitbucket Community, 

My name is Adam and I am a product manager with the Bitbucket Cloud team. On February 27, 2026, the ability to create new repository forks will be limited to the parent workspace. Existing forks to other workspaces will continue to function as normal for the time being. Where possible, we will automatically move existing cross-workspace forks to the original parent workspace. We will send another notification when this is planned. Please note, forked repositories where the creator doesn’t have write access to the parent workspace, the repositories will be left in place, and their fork associations with the parent repository will be broken.

Why we’re making this change:
This change positions Bitbucket Cloud to offer greater product reliability and introduce highly requested enterprise-grade controls like data residency.

We know that this will be a significant change for some of our customers, especially the open source community. While forks aren’t core to every Bitbucket customer’s workflow, we recognize that retiring open-source pull request support will be felt by those who depend on it.

What to expect:

• Users will no longer be able to create new cross-workspace forks after February 27, 2026.

• Existing forks to other workspaces will continue to function as normal for the time being.

• Adding the workspace slug is optional when using the Bitbucket Cloud REST API endpoint to fork a repository. Omitting the workspace parameter will assume the same workspace.

• At a later date, existing cross-workspace forks will be moved into the original parent workspace where possible.

  • Associated PRs of the forked repo remain and will function as normal

  • Once moved to the parent workspace, forked repo permissions may change based on the parent workspace.

• If moving a fork to the parent workspace is not possible or fails, you won't be able to file PRs to the parent repo of the fork, but can still file PRs inside the forked repo itself

Have questions or suggestions? We’d love to hear from you, so please leave a comment below.

[Dave Anderson]

Does "we recognize that retiring open-source pull request support will be felt by those who depend on it" mean that you no longer want to work with open-source developers, or is there some sort of work around you suggest for this?

[Colton Anderson]

Do you intend to provide any workarounds, extra settings, or features to help with development across workspaces, or is Bitbucket phasing out of open source work?

[Mouad El Kacem]

I get the technical reasons behind this change, but it’s still a big hit for open-source workflows. Cross-workspace forks make independent contribution possible without extra barriers, and removing that option risks limiting the openness and creativity that open source depends on.

I hope the team can offer an alternative or a clearer path to keep external contributions accessible.

[Tim Govers]

Any reason why I see the warning on top of a forked repository that IS in the same workspace as the parent repository?

[Volodymyr]

Where possible, we will automatically move existing cross-workspace forks to the original parent workspace.

This is a scary change, as original workspace in our company is no longer available to our team and is scheduled for removal. I'm "creator" of repositories and still have access to both organizations, but no-one else does. If this happens, everyone in the team will lose access to source code. 

[Amit Gupta]

@Adam Rouman I have 2 repos-repo1 and repo2. I forked repo2 from repo1. Will repo2 move to workspace of repo1 after this change? I do not want to. what are my options?

[Peter Falck Grony]

@Adam Rouman You say this is for cross-workspace, however I only have repositories within the same workspace (organization) but within different projects, why are these repositories getting the warning?

Will it be possible to not have the fork moved? I would rather severe the tie between the forked repository and the parent repository than having the fork moved - This change would break our organizations' compartmentalization of business logic.

[Christopher Schommer]

Hi, we got the warning for a private fork of a repo that exists in the same project/workspace? That imho doesn't make sense ...

[ccenvcvb]

I don't know what workspace or parent workspace means.

Is this part of the Atlassian "newspeak" where Issues are no longer issues but work items?

We have projects and forks across those projects. Are those affected by this change or not?
Development is a project and all release forks are in release projects.

Will this change prevent a customer with their own Bitbucket account from forking a repo we maintain?

[Adam Rouman]

Hi Folks - there are some great questions here that I will do my best to answer: 

Q: Why am I seeing this message on my fork that is in the same workspace? 

A: We initially wanted to give all users who rely on forking workflows advanced notice of the upcoming changes. Only forks to other workspaces are in scope. Based on the feedback, we are planning to update the in-product messaging to make it more clear which forks are impacted soon.

Q: How do I manage a fork's relationship to the parent repository myself? 

A: Thanks to the feedback here, we are discussing a solution for a self-serve feature that will allow customers to manage the forking relationship yourself. I hope to have an update on this soon. In the meantime, Bitbucket Support would be happy to assist by filing a ticket here and providing the team with the forked repo URL and the support team will be happy to unlink the fork relationship between forked and parent repositories.

Q: What does this mean for support for our open source workflows?

A: We recognize that this change is particularly meaningful for customers using Bitbucket Cloud for open source projects, where the typical contribution model is “fork → branch → pull request” from a different account or organization:

• Public repositories remain available – your open source projects can continue to be public, cloned, and browsed as before.

• What’s changing is the ability for contributors to create a fork into a different workspace and open pull requests back to your repo. That cross‑workspace fork + PR model is being retired.

• For ongoing open source collaboration in Bitbucket Cloud, we recommend:

  • Hosting the project in a designated shared/open source workspace, and

  • Granting trusted maintainers and frequent contributors write access so they can use branches + pull requests within that same workspace, or forks that also stay within that workspace.

• Occasional or “drive‑by” contributors who cannot be granted write access can:

  • Continue to clone your public repository and share changes as patches (e.g., via git format-patch), or

  • Work with your maintainers to agree on a contribution process that fits your project’s governance (for example, using a shared workspace for community maintainers).

We know this is a significant change for some open source maintainers and contributors, and we’re committed to providing clear guidance and migration paths so you can continue to collaborate in Bitbucket Cloud.

Stay tuned for additional updates we will be making soon.

Thanks

[Ulrich Kuhnhardt _IzymesCo_]

Here is an idea that keeps everyone happy:

Disable outside forks by default and let workspace admins enable it via a setting. 

Atlassian has a few public repos like Atlassian Connect Express that have benefited from developer community contributions. 
I find it hard to believe that Atlassian doesn’t see the value of community contributions AND at the same time shipping enterprise features. A simple checkbox and an IF statement in the backend doesn’t sound hard to implement 

[Stefan Prelle]

For that to NOT being a stupid idea, find means that open source projects can have additional users in a workspace without needing to pay for that. Without that, you force every open source project to leave Bitbucket.

[Neill Magill]

I think the issue with killing off pull requests for people outside of the main workspace for open source projects is that it makes reviewing the changes from those contributors much harder, the pull request tools are very valuable for giving good feedback on the changes that people are making; the use of patches will make this much more challenging.

[JAY PRAKASH SAH]

Hi @Adam Rouman

Which team should I submit a request to in order to unlink the fork relationship? My older workspace is no longer active, and I need to make my current workspace the parent one.

[Eric Gruss]

Please give us the option of just severing the fork instead of moving it back to the parent as that would be a cleaner option in many of our cases.

[mispr]

We have hundreds of repositories, forked from a template repo that served its purpose back in the day. We wanted to archive this repo, but this is not possible in Bitbucket Cloud: https://jira.atlassian.com/browse/BCLOUD-18018.

We then decided to create a separate "archive" workspace, to move these repositories out of our active workspace, to clean up, and to avoid unnecessary overhead in 3rd party tools that scan / use our workspace.

Does this mean we need to move all of these archived repositories back to our active workspace?
Because that's just not feasable right now.

We should be able to sever the connection from these forked repositories and their parents in the other workspace.

[Adam Rouman]

Hi Everyone, 

Thanks for the feedback. We understand this is an adjustment to your development processes. Therefore, we wanted to let you know we are listening and will have more updates to share in January. This will include additional details about your options for managing existing cross workspace forks and the timeline for when cross workspace forks would be automatically migrated.

[Andreas Filler]

I would highly appreciate to be able to disconnect the fork on my own. Like someone else already wrote, there are a lot of reasons why a fork is legally and by purpose forked to another workspace and it would be terrible if it would fall back with all the changes done in the meanwhile to the original one. A lot of work would be given to people who should have/see it. It would be comparable to a data breach.

tl;dr: I don't welcome this change at all and think there are much more relevant things to improve in Bitbucket, but if you would give us admins the possibility to unlock the repos from their parents it's an "acceptable" change.

[Bryant Boatright]

@Adam Rouman Tacking on another request to let the owner of the fork sever the connection to the parent.

I understand the change is beneficial to Bitbucket/Atlassian, but am frustrated that the baseline resolution is moving the fork into the parent workspace w/o opt-in from the fork owner.

It seems as though the baseline resolution should be to sever the tie between fork and parent while presenting the option of allowing the fork owner to move the fork into the parent workspace.