BCMA known issues

1

Only one migration can be run at a time. You may encounter errors if you attempt to run more than one migration simultaneously.

2

Whilst migrating to an existing workspace with permissioned users is possible, there is a risk that migrated users will inherit any default workspace permissions from that workspace. This may result in users that previously couldn’t read or write to a repository to now be granted those permissions.

To avoid this risk, our recommendation is to migrate to a new, blank workspace where default permissions have not been configured.

3

The BCMA does NOT support Bitbucket Data Center at this time. If you use DC, it is possible to reduce your cluster to a single active node and then run the BCMA but attempting to run it while multiple cluster nodes are active can potentially lead to multiple issues. We are looking to resolve these issues in a later release.

4

You will need to create a new Workspace or use one that was created as opposed to using a workspace named after your own user account (created automatically for each user in Bitbucket Cloud) as the default workspace has limited functionality.

Renaming a default workspace does not convert it into a full team/shared workspace.

5

Bitbucket Cloud identifies unique repositories by looking at the combination of the workspace slug and the repository slug, meanwhile, Bitbucket Server uses the Project Key and Repository slug. This means that in server, you can have the same repository name/slug exist in multiple projects, but not within the same project. Since Cloud doesn’t look at the project key when computing uniqueness, it will consider these repos as duplicates of one another and will preventing you from migrating them into your new Cloud workspace.

To address this, you will need to ensure that the name/slug is unique throughout the entire server instance before you can migrate them or migrate a subset and rename them once they are in the cloud before migrating the second set.