How to export Bitbucket repositories with pull requests and comments

Why is a git clone not enough?#

A git clone of a Bitbucket repository carries commits, branches and tags, but not the review layer around them. Pull request titles, descriptions, reviewer approvals, inline comments, tasks and build statuses are stored by Bitbucket itself, outside the git objects your engineers push.

For an AI developer, that review layer is much of the value. It shows what a reviewer objected to, how the author responded and which version was finally merged. Plan the export as two linked pulls: git for code and history, the API for review records, joined by commit hashes. Comments without diffs are hard to read, and diffs without comments are only code history.

Which Bitbucket product are you exporting from?#

Bitbucket Cloud and Bitbucket Data Center, along with older Server installs, expose pull requests through different REST APIs with different paths, pagination and authentication. A script written for one usually fails on the other, so settle this first.

Check history as well as the current host. Repositories that moved from Server to Cloud, or into Bitbucket from another Git host, may have arrived without their older pull requests and comments, because migrations do not always carry review history. If the old system is still running, export from it before it is switched off.

Step table: mirror clone plus API pulls#

The export runs in seven steps, and only the second touches git. Run everything from one controlled machine with a resumable script that writes one JSON file per pull request, so a rate-limit pause or dropped connection restarts where it stopped instead of from the beginning.

Use a dedicated read-only credential scoped to repositories and pull requests, following Atlassian's current authentication guidance, which has changed over time. Store the output in company storage with access limited to the people preparing it.

Which pull request and comment fields should you keep?#

Keep the fields that reconstruct the review conversation and link it to code, and drop presentation data such as avatar links and rendered HTML. Personal identifiers stay in the working export for now; they are replaced with consistent pseudonyms during preparation, not deleted, so one reviewer's comments still read as one person.

• 1Pull request: ID, title, description, state, close reason, created, updated and closed timestamps.
• 2Branches and commits: source and destination branch names, source and destination commit hashes, merge commit hash.
• 3People: author and reviewer account IDs, each reviewer's approval or changes-requested status.
• 4Comments: comment ID, parent ID for threaded replies, author ID, body text, created and updated timestamps, deleted flag.
• 5Inline anchors: file path, line numbers and the commit the comment was attached to, so outdated comments still point somewhere.
• 6Tasks and statuses: open and resolved tasks, plus build and check results reported by CI.
• 7Links out: Jira issue keys found in titles, branch names and commit messages, kept as plain text for later joining.

What gaps catch teams out?#

Deleted source branches are the most common gap. Many teams delete a branch when its pull request merges or is declined, so the commits of declined work disappear from the mirror. The pull request diff pulled through the API may be the only surviving copy, which is why step six matters.

Force pushes cause a second gap. Inline comments attached to commits that were later rewritten become outdated, and their line anchors no longer match the final diff. Keep them with their original commit hash rather than dropping them; the back-and-forth around a rewrite is often the most instructive part of a review.

Images pasted into comments, links to external CI systems and comments on forks sit outside the main calls. Decide early whether each is in scope, and record the decision rather than leaving it to whoever runs the script.

Older Bitbucket Cloud repositories may also have used the built-in issue tracker and wiki, which pull request descriptions often reference by issue number. Atlassian announced that both would be removed on August 20, 2026, with issues exportable as a ZIP package holding a db-2.0.json file and an optional attachments folder, and wikis exportable by cloning their separate repository. Confirm whether that content was exported or moved to Jira before you rely on those references.

Illustrative: exporting a long-running Bitbucket workspace#

Illustrative: a fictional logistics software vendor runs Bitbucket Cloud for its main products and still has a Bitbucket Server instance for a retired desktop product. The CTO wants both histories reviewed before the old server is decommissioned.

The team inventories both systems, takes mirror clones, and pulls pull requests in every state with comments, activity and diffs. Reconciliation shows that the Cloud workspace lost the review history of repositories migrated years earlier, while the old server still holds it. The vendor exports from the server first, then keeps the server read-only until the export is checked. The final package joins both sources by commit hash and lists which repositories carry review history and which carry code history only.

How SourceX approaches a Bitbucket export#

SourceX treats the export as part of the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The first conversation needs only metadata, such as repository names, years of history and approximate pull request counts. No clone or export leaves the company during the fit check.

During preparation, exported comments are scanned for secrets and personal details as well as the code, since tools such as TruffleHog scan chats, wikis and logs as well as Git. The export method, counts and commit hashes are recorded as provenance in the SourceX Evidence Packet, and large exports stay in the seller's own storage until delivery is approved.