Deprecation of Forked Repositories Outside the Parent Workspace

[Shipley_ Samuel]

I'm an open source Drupal developer and have been forced to use Bitbucket a few times in the past. Honestly, I'm not sure why people choose it over GitLab or even GitHub for that matter, I assume they must like Jira and think the integration is beneficial to projects. Thankfully, I've not had to use Jira in years! :)

Since Bitbucket chose to kick open source to the curb and suggested we go back to a patch-based workflow, I'll be pushing to move all government projects away from Bitbucket and suggest others look at their competitors as well. This is a perfect reason why it's SO important to prevent vendor lock-in and not become dependent on internal integrations. This will likely end up imploding projects and causing a mass exit from Bitbucket similar to the exit we seen when Microsoft bought Github many years ago. 

[Jonathon Woolf]

I have to say, I'm confused.  I use several Bitbucket repositories, but I didn't create any of them and to be honest I've always treated them as something of a black box: as long as they work I don't mess around with them.  Only one of them is showing this warning, I guess because it was forked from another workspace but the others weren't.  I don't have access to that parent workspace and have no idea how I could get it.  

Is there a way to sever the connection between the two and leave this fork right where it is?  It sounds like there will be a way to do this, but will it be ready before the Feb 26 deadline?  If not, what else can I do to stop the repo from being merged with its parent workspace?  

[Jared]

Perhaps it's been answered already and I've missed it...but I would really love to know what happens in situations like ours where the original workspace has been sunset and is no longer available.

We need clear answers on how this will affect our access.

[Adam Rouman]

Thank you to everyone who has engaged with this post so far. Based on the feedback we have received, I wanted to provide a clear update (also pinned to the top of this post) on what is happening with forked repositories to other workspaces:

1. This post/update only applies to cross workspace forked repositories. Forked repositories within the same workspace are not affected by this. We will be updating this message in product to only show on cross workspace forked repositories only.
2. Atlassian will NOT be moving any forked repositories into the parent workspace on your behalf. Because of the security and reliability updates we are making to our platform, we plan to, however, automatically break the forked repository relationships. Once forked repository relationships are broken, all pull request functionality will remain as normal/expected.
   1. Please note: Cross-workspace PRs that have already been created will be able to be viewed and merged. You will not be able to create a cross-workspace PR from the fork to the parent if the relationship is broken, but will be able to continue creating PRs from child to parent if both repositories exist in the same workspace.
3. The above change will occur On July 1, 2026. On this date, we will also be removing the ability to create new cross workspace forks. We previously communicated this would be removed February 27, 2026, but are now extending this to July 1, 2026. We want to give enough time to manage outstanding forks and update your software development workflows as needed.
4. If you would like to break the forked repository relationship to the parent repository, you can do so today by contacting support. If you are a repository admin and would like to do this yourself, we are building a self-serve feature to support this. The feature will be available soon and I will update this post again once available.
5. What does this mean for support for our open source workflows?
   • Public repositories remain available – your open source projects can continue to be public, cloned, and browsed as before.
   • 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).

Again, thank you for your feedback and please reach out if you have additional questions.