Issue Summary

After migrating repositories from Bitbucket Server/Data Center to Bitbucket Cloud using BCMA, the repository size shown in Bitbucket Cloud is often significantly smaller than what was reported on-prem. This is expected due to how Bitbucket Cloud calculates and displays repository size; however,  BCMA currently does not warn or educate users about this difference, which can lead to confusion and support tickets regarding perceived data loss.

Problem Statement

• Bitbucket cloud’s “Repository size” in the UI only measures: The packed Git data (the .git object store).
After garbage collection and compression
• It excludes: Pipelines artifacts, Downloads, Wiki data, Git LFS objects (tracked separately as LFS storage)
• On Bitbucket Server/Data Center, the size typically reflects: Repository data plus temporary/cached data, Old packfiles and loose objects. 
Sometimes, LFS content is stored alongside the repository.

As a result, the same repository history can appear much smaller on Bitbucket Cloud than on Server/DC. While this is normal and expected, migrators are not informed of this behaviour in BCMA, so: * They may assume data is missing or something went wrong in the migration

• They may open support cases to validate the migration
• It erodes confidence in the migration outcome

Proposed Solution

Add an explicit warning / informational message in BCMA to explain that:
1. Bitbucket cloud repository size is calculated differently and is often smaller than the size seen on Server/DC.
2. Bitbucket Cloud’s size metric: Represents packed Git data only (after compression and GC) and excludes Pipelines artifacts, Downloads, wiki data, and Git LFS objects (these are tracked separately)
3. This difference is expected and does not indicate data loss, as long as the migration completes successfully.
Suggested UX Touchpoints

Workaround

Content matching can be accomplished by performing a comparison between the two environments by one of the following methods

• Cloning the same repo from the server and cloud and then comparing the local clone results.
• Run a git clone --mirror against both cloud/server and compare without working directories being considered
• Run git clone --all for the same repo in both environments, and compare the <repo>/.git/objects folder sizes.