Cannot change Bitbucket Cloud workspace binding after repository migration to new workspace

SonarQube Cloud
,
1

ALM used: Bitbucket Cloud
CI system used: Bitbucket Cloud Pipelines
Scanner: sonar-maven-plugin 5.2.0.4988
Languages: Java

Problem:
We migrated our Bitbucket repositories from workspace `Sahara` to a new workspace `goat-int`.

Our SonarCloud organization (key: editec, Team plan) is still
bound to the old workspace Sahara.

In Organization Settings → Organization binding we see:
“The path to this Bitbucket workspace changed to
Bitbucket”

Clicking “Update path” shows:
“Refreshing the ALM bindings is only available for GitLab”

In Project Settings → Repository binding we only see repositories
from old workspace Sahara - new workspace goat-int repos
are not available.

**Additional context:** I also have a second SonarCloud organization (key: `goat-int`, Free plan) which is properly bound to the new Bitbucket workspace `goat-int`. When I try to import repositories there, they show as “Already imported” because they are already bound to the `editec` organization. So I’m completely stuck: - `editec` (Team plan) → bound to old workspace `Sahara`, cannot change - `goat-int` (Free plan) → bound to correct workspace, but repos show “Already imported” and cannot be imported again Is there any way to either: 1. Update the `editec` org binding to point to `goat-int` workspace, or 2. Release the projects from `editec` so they can be imported into `goat-int`?

**Additional note about workspace type:** The old Bitbucket workspace `Sahara` appears to have been a personal/private workspace, while the new workspace `goat-int` is a proper team/organization workspace. This may be relevant because the SonarCloud organization `editec` shows avatar URL: https://bitbucket.org/workspaces/mchaddah/avatar/ which looks like a personal Bitbucket account, not an organization workspace. So the original binding may have been to a personal account rather than a proper team workspace, which could explain why the migration path is not straightforward.

**Goal:** We would like to resolve this without losing existing project data (analysis history, issues, quality metrics) and without having to recreate all projects from scratch. We have 13+ projects in the `editec` organization on Team plan and recreating them all would result in significant data loss and effort. Is there any way to handle this migration gracefully on your end?

Thank you.

2

Hello.
Can anyone help me sort this out please?
@ganncamp , @Colin

3

Hey @Yurii_Yelkin, welcome to the Community! There is a documented workaround to unbind a Bitbucket-bound org and re-bind it to another ALM (in your case, to another Bitbucket workspace). Could you give this a try?

4

@andres Thanks for the workaround suggestion!

We’re checking internally whether we can get the workspace owner to remove the SonarQube Cloud app from the old Bitbucket workspace, since that requires access we don’t currently have ourselves.

In the meantime, is there any alternative way to unbind the organization from your side, without requiring the app removal from the Bitbucket workspace? We’d like to explore all options in parallel since this is currently blocking our CI/CD pipelines.

5

Hey @Yurii_Yelkin, there’s no way. With the current implementation, the source of truth for the binding lives on Bitbucket side, on the app installed on the workspace.

Just a note: you said your pipelines are blocked. However, normally this is not something related to the organization or project binding. Could you explain a bit more in which way are your pipelines blocked?

6

Understood, thanks for confirming @andres .

To clarify the pipeline issue: our Bitbucket Pipelines run sonar-maven-plugin, and on pull request analysis it fails with:

[ERROR] Could not find the pullrequest with key '87'

This happens because the scanner auto-detects the PR via Bitbucket Cloud Pipelines env variables and tries to look it up through the Bitbucket API in the old (bound) workspace, where that PR/repository no longer exists - the repos were physically migrated to a new workspace.

Branch analysis (e.g. on develop) works fine since it doesn’t require this PR lookup. So the failure is specifically tied to PR decoration relying on the old workspace binding.

7

Okay, I understand, thanks for the clarification. Unfortunately you will have to carry out the un-binding workaround, there’s no other known workaround.