How to export data from Bitbucket before a contract ends
Git history, LFS objects, and pull request, comment, issue and wiki data can leave Bitbucket through documented paths, but Pipelines variables and some metadata cannot be read back, so they must be recorded or re-created by hand. This matters whether you face a Data Center renewal, a notice that Atlassian has stopped selling new Data Center subscriptions, a decision about the Hybrid License, or a lock-in concern about Bitbucket Cloud. Start the export work while you still have full administrative access and a contract in force. This section explains what leaves, what does not, and what to confirm first. The rest of the page covers repository cloning with LFS, API limits for pull request history, Pipelines and wiki gaps, and a pre-exit checklist. Atlassian's current documentation decides final behavior for your plan, so verify each step against it.
Repository content is the easiest part. A mirror clone (git clone --mirror) captures every branch and tag, and LFS objects need a separate fetch (git lfs fetch --all) run against the same repository, otherwise large binaries arrive as pointer files. Pull requests, comments, reviews and issues come through the Bitbucket Cloud REST API, which allows 1,000 requests per hour for most resources. A busy workspace with years of review history can take many hours of paced requests, so start early and schedule the job across days. Pipelines variables are a different case: secured values cannot be read back through the interface or the API, so inventory every secret, record its owner, and plan to re-enter it in the target system. Wikis are stored as a separate Git repository in Bitbucket, so confirm that yours is included in your mirror plan.
Before the contract ends, build a written inventory of repositories, LFS usage, pull request volume, wikis, Pipelines variables, webhooks and user mappings. Then choose a target that matches the data. GitLab's import documentation covers Bitbucket Cloud and Bitbucket Server sources, so a GitLab target can bring in more than Git history. Gitea has no Bitbucket importer in its migration code, and Forgejo's dump-repo command does not list Bitbucket as a source, so for those targets, plan a Git mirror for history and a separate, tested export for metadata. Run a full trial import into a non-production instance, compare counts and spot-check reviews, and keep the Bitbucket export archive as a record. Ask Atlassian, in writing, how long your data stays accessible after the end date and what export support is included.
Export data from Bitbucket by data type, method and limit
This table maps each kind of Bitbucket data to the method that extracts it, the format you end up with and the documented limits that shape the job. Read it as a checklist: the Git history moves easily, while API-based data depends on rate limits and Cloud repository size. Confirm Data Center export options with Atlassian for your version before you plan around them.
| Data type | Export method | Output format | Documented limit |
|---|---|---|---|
| Git repository history | Clone or mirror the repository with Git | Bare Git repository with all branches and tags | Cloud repositories are capped at 4 GB |
| LFS objects | Fetch large files with the Git LFS client | LFS object store alongside the Git history | Confirm LFS transfer and storage limits in Atlassian's Cloud documentation |
| Pull requests and comments | Bitbucket Cloud REST API, paged requests | JSON records, one per pull request and comment | 1,000 requests per hour for most API resources |
| Issues and wiki | Clone the wiki Git repository; issues need a Cloud API export or a platform importer | Git repository for the wiki; JSON or custom files for issues | Wiki follows the repository size cap; the 1,000 requests per hour limit applies to issue calls |
| Repository and project metadata | Bitbucket Cloud REST API for names, permissions, branches and settings | JSON records to map into the target forge | 1,000 requests per hour for most API resources |
| Pipelines variables | Not readable through the API after they are set | Re-enter manually in the target CI system | Secured values cannot be read back, so record them from your own secret store |
How Bitbucket API rate limits shape a bulk export
Bitbucket Cloud allows 1,000 requests per hour for most API resources, and that ceiling decides how a pull request export is scheduled. A repository with a long review history cannot be fetched in one pass. Each pull request list page, each pull request, and each comment page costs a request, so the export has to be paged, spread across hours or days, and designed as a long-running job. Plan for retries after throttled responses, and write a checkpoint after each completed page so a failed run resumes where it stopped instead of starting over.
The request count grows with three things: the number of comments per pull request, the number of repositories in the workspace, and the nested resources attached to each pull request, such as activity, commits and diffs. A pull request with hundreds of comments can cost more requests than dozens of quiet ones. Before you schedule anything, count your own volume: list the repositories, sample the pull requests in each, and multiply the pages you expect to fetch by the number of nested calls per item. Confirm the current limits in Atlassian's API request limits documentation, since your account type and endpoints can change the outcome.
The limits also apply on the receiving side. The GitLab and Gitea importers call the Bitbucket API themselves when they pull pull requests and comments, so a platform import is subject to the same hourly budget as your own script. Running your export and an import against the same workspace at the same time will compete for one allowance. Ask the target platform's team how its importer handles throttling and whether it resumes after an interruption, and schedule the import into a window you have measured rather than assuming it will finish in one run.
What does not export from Bitbucket and the workaround for each
Repository content moves relatively easily, but several categories of Bitbucket data arrive without their secrets, history or permissions. Each card below names one of these gaps, the workaround that closes it and the team that has to act before the contract ends.
Pipelines secured variables
Secured repository, workspace and deployment variables cannot be read back through the API or the interface once they are saved. Export the variable names and their intended usage from your pipeline files, then re-enter the values in the target CI system and rotate each credential so the old value is no longer valid. Platform engineering owns this step, with the application teams confirming which values their deployments need.
Pipeline run history and logs
Build logs, step timings and past pipeline runs stay in Bitbucket and do not come across with the repository. If an audit, incident review or customer contract needs proof that a release was built and tested, export the relevant runs to your own storage before the contract ends. Compliance and security leads should decide which runs must be kept and for how long.
Passwords, two-factor secrets and personal keys
User passwords and two-factor authentication secrets are never exported, so every account must be recreated or reset on the target forge. Personal SSH keys and access tokens also need to be reissued by their owners, since the old keys are tied to Bitbucket. Identity administrators should plan a sign-in path for each user, and developers should register new keys before the cutover date.
SSH keys and deployment access keys
Deploy keys, repository access keys and SSH keys configured for build servers or external systems stay behind in Bitbucket. Each consuming system must be given a new key pair on the target forge, and the old public key should be removed once the new one is confirmed. Operations teams should inventory every system that clones or pushes to a repository, because a missed integration fails silently until its next run.
Jira links and Jira-held issue data
Links from commits and pull requests to Jira issues, and the issues themselves, belong to Jira rather than Bitbucket. Unless you export Jira projects separately, the target forge will hold repository text that points to issues that no longer resolve. Decide whether issue history moves, stays in Jira as an archive, or is linked by a reference table, and confirm this with the Jira administrator before cutover.
Workspace and project permission models
Workspace roles, project permissions, branch restrictions and group memberships do not map one-to-one to GitLab, Gitea or Forgejo. Record who holds each role and each branch protection rule, then recreate them on the target and test that protected branches reject direct pushes. Repository owners and the security team should sign off the permission list, since errors here are the easiest to miss.
Run a complete Bitbucket export in the right order
This sequence moves code, review history, wiki content and pipeline configuration out of Bitbucket in an order that keeps each copy checkable against its source. Each step ends with a comparison you can rerun before the contract ends.
Inventory repositories, LFS usage and sizes
List every repository in the workspace or project, including forks, archived repositories and any with Git LFS enabled. Record the size of each repository, the count of LFS objects and the total storage used, using the Bitbucket admin views or the API. Check the totals against the Bitbucket storage pages before you go further, because repository size limits on Bitbucket Cloud affect which copy method will work. The output is a signed-off inventory that every later step is compared against.
Freeze settings and record branch permissions
Agree a change freeze with the teams that push to these repositories, and export the current branch permissions, default branch, merge checks, user and group access, and webhook configuration to files. Store the files in controlled storage with the export date. Confirm that the exported permission list has the same number of rules as the live settings page for each repository. This record is what you will re-create on the new forge, since Bitbucket permissions do not move automatically.
Mirror all Git refs and LFS objects
Run a bare mirror clone of each repository, which copies every branch, tag and ref, then fetch the LFS objects with the git-lfs tooling into the same controlled storage. Compare the branch and tag counts in the mirror with the Bitbucket branch list, and verify LFS objects by checksum against the pointer files in the repository. Keep the mirror as the authoritative Git history, because pull requests and comments are not contained in it and need the separate steps below.
Export pull requests, comments and issues in batches
Use the Bitbucket Cloud or Data Center REST API to page through pull requests, their activity, comments, reviewers and any issues, writing each page to a file with its cursor. Bitbucket Cloud limits most API resources to 1,000 requests per hour, so schedule runs across a window, store the last cursor, and resume rather than restart. Compare the total pull request count per repository against the Bitbucket list filtered by state, and confirm that comment counts on a sample of pull requests match the source. Record any items that return errors for later follow-up.
Export wiki repositories
Each Bitbucket repository with a wiki has its own Git repository for the wiki content, so clone that repository as a mirror in the same way as the code. Check that the page count and the latest commit hash match the wiki view in Bitbucket. Attachments stored in the wiki may need a separate check, so list them and confirm their file counts against the source before you mark this step complete.
Capture pipeline configuration and variable names
Copy the bitbucket-pipelines.yml file from each repository's default branch and from any branch that carries a different pipeline definition. Export the list of Pipelines repository and workspace variable names, marking which ones are secured. Secured variable values cannot be read back through Bitbucket, so record which secrets must be re-entered in the new platform by the owning team. Confirm that the list of variable names matches the Bitbucket settings page for each repository.
Archive a final snapshot and verify it
Run the mirror and API exports once more after the freeze, then archive the mirrors, LFS objects, JSON or CSV exports, permission records and pipeline files together with a manifest of file names and checksums. Store the archive in at least one location outside the Bitbucket account, and test that a sample repository can be restored or imported into the target forge. The step is complete when the manifest reconciles with the inventory from the first step and the sign-off names the person who accepted the archive.
Which export path applies to Bitbucket Cloud or Data Center
Bitbucket Cloud is hosted by Atlassian, so you export through Atlassian's interfaces and APIs rather than from a server you control. The main constraints are request budgets and repository size. Bulk pull request and comment extraction runs through the REST API, and Bitbucket Cloud allows 1,000 requests per hour for most API resources, so large workspaces need a throttled script that resumes after a pause. Repository size also matters for clones. Bitbucket Cloud enforces a 4 GB repository limit, and Free workspaces have a 1 GB total storage limit, so a repository near either ceiling needs a plan for moving history in pieces.
- REST API budget: Plan extraction of pull requests, comments and issues across several sessions, and record the cursor for each collection so a restart does not repeat calls.
- Repository limit: Confirm each repository's size before cloning, since a repository at or near 4 GB may fail to transfer cleanly.
- Free workspace storage: A Free workspace with a 1 GB total storage limit should be exported before any plan change, because the total is the constraint, not each repository.
- Pipelines variables: Secured variables cannot be read back through the API, so record their names and rebuild their values from your secrets owner.
- Wikis and LFS: Clone wikis and LFS objects as separate Git operations and verify object counts afterward.
Before relying on any of these limits, confirm current values with Atlassian, because plan terms can change.
Bitbucket Data Center runs on your own infrastructure, so export options depend on the version you have installed and on how your administrators configured backups. Atlassian's documentation for your exact release defines which server-side export, backup and migration tools are available, and whether they cover repositories, pull requests, attachments and the search index. The data sits in your datacenter, which means your team controls the access path, but it also means your administrators must run the export and verify the result.
- Version-specific tooling: Identify the exact installed Data Center version and read the export and backup documentation for that release before planning.
- Repository access: Clone repositories from the server over SSH or HTTPS using an account with read access to every project, and confirm that archived or personal repositories are included.
- Database and filesystem backups: Ask your administrators whether a full backup covers the shared home directory and database, since Git objects and metadata are stored in separate places.
- Pull request history: Confirm with your administrators whether pull request and comment data is available through the REST API or only in a database dump, because the two paths require different handling.
- Attachments and LFS: Verify that LFS storage and attachments are part of the backup scope.
Confirm all of these steps with Atlassian and your Bitbucket administrators before scheduling the export.
Atlassian's journey-to-cloud guidance states that Bitbucket Data Center continues beyond 2029 and that existing customers receive a Bitbucket Hybrid License covering Data Center and Cloud. The license does not move your data. A Hybrid License tells you what you are entitled to run, but repositories, pull requests and pipelines still live on a specific instance, and that instance determines the export path. Organizations that run both products often find that some repositories were migrated to Cloud and others remained on Data Center, so the export inventory must cover both.
- Instance inventory: List every repository, its host (Cloud or Data Center), and the owning team before choosing an export method.
- Split data types: Record separately which instance holds pull requests, pipelines, wikis and attachments, since one repository may have code on one instance and reviews on another.
- Entitlement is not location: Confirm with Atlassian which of your workspaces and instances the Hybrid License covers, and do not assume that a Cloud workspace inherits Data Center data.
- Cutover timing: Freeze pushes to each repository during the final export so that history from both instances does not diverge.
- Renewal records: Keep license and entitlement documents with the export plan so the contract end date is traceable.
Confirm the instance map with your Atlassian account team before the first export run.
What to plan before the Bitbucket contract ends
A Bitbucket exit rarely fails on the Git history. It fails on the things around it: an end date nobody confirmed, credentials that stop working on cutover day, and Pipelines nobody mapped. Each card below is one item to settle before the contract ends, so the export runs on your schedule rather than the vendor's.
Confirm end date and notice terms
Get the end date, notice period and data return terms from Atlassian in writing, for your exact product and contract. Context: Atlassian announced on September 8, 2025 that it is sunsetting its Data Center products by March 28, 2029, and its journey-to-cloud page says Bitbucket Data Center continues beyond 2029 with a Bitbucket Hybrid License for existing customers. Read the current terms yourself, since these dates may not match your contract.
Run a full test export
Before the final cutover, export every repository, including LFS objects, pull request history and comments, to a staging instance on the target platform. Time the run and log every failure. Bitbucket Cloud's API allows 1,000 requests per hour for most resources, so large pull request histories will need a planned, throttled run rather than a single pass.
Restore and verify on the target
An export proves little until it restores. Load the export into a clean target, then check commit counts, branch heads, tags, LFS pointers and a sample of pull request threads against the source. Use the Forgejo or GitLab import tooling as the restore path for each source type, and record what did not come across so you can decide how to handle it.
Keep a read-only source archive
After cutover, keep the Bitbucket source in read-only mode for a defined period and retain a full export as an offline copy. Confirm with your legal and records team what must be retained, and keep the archive in storage you control. Do not rely on the vendor to hold this data for you after the contract ends.
Set the retention period for exports
Decide how long exported code, pull request discussions and attachments are kept, and who can access them. Exports often contain personal data from reviewers and commenters, so retention should match your data protection obligations. Document the decision and the deletion date before the export is created, so it is not left to whoever runs the job.
Map users, groups and permissions
Bitbucket workspace roles, project permissions and branch restrictions do not map one to one onto GitLab, Gitea or Forgejo. Build a table that links each Bitbucket user and group to a target account, and recreate branch protection rules explicitly. Confirm your identity provider integration before cutover, so accounts and access are not created by hand.
Reissue credentials and webhooks
Every integration that talks to Bitbucket holds a token, an SSH key, an app password or a webhook URL. Inventory them, rotate them on the new platform and update CI jobs, deployment scripts and chat notifications at the same time as the cutover. Old credentials left active after exit become an access risk, so revoke them on the source as well.
Set the date Pipelines are replaced
Bitbucket Pipelines variables cannot be read back through the API, so the values must be re-entered from your secret store, not copied from the old platform. Set a firm date by which each pipeline is rebuilt as a GitLab CI/CD, Forgejo Actions or Gitea Actions workflow, and run old and new pipelines in parallel until the new ones pass.
How to verify the export is complete before cutover
Run completeness checks before you switch teams to the new forge, and treat them as evidence for a sign-off rather than as proof that nothing is missing. For each repository, compare the commit count and the branch and tag lists between the Bitbucket source and the target, using git rev-list --count --all and git for-each-ref on both sides. Then confirm that every LFS pointer in the working tree resolves to a stored object on the target, for example by running git lfs fsck in the restored clone and by fetching a sample of large files through the new LFS endpoint. Missing LFS objects are the most common silent gap, because the Git history can look complete while binary assets are absent.
Reconcile the pull request and comment side separately, because it does not travel with Git. Build a source-side report from the Bitbucket API for each repository: pull request counts by state (open, merged, declined), reviewer approvals, and inline comment counts. Compare those figures with what the import tool or your migration script produced, and record any difference with its cause, such as deleted comments, deleted users who now show as placeholders, or pull requests skipped for a reason the importer logged. Spot-check a handful of threads with inline comments and reviews, especially on long-running branches, and confirm that the wiki pages render and that their internal links resolve. Confirm which fields your importer maps and which it drops before you trust any count.
Keep the exported data, the checksum manifests and the reconciliation reports in one dated archive, and record who checked each item and who signed off on cutover. Your own acceptance criteria decide what counts as complete, including how much history loss is tolerable and which repositories are retired instead of moved. The checks here reduce the risk of a silent gap but do not replace those criteria, and an independent review by someone who did not run the export is worth requesting before you close the Bitbucket account.
How long does it take to export data from Bitbucket, and what do you need to provide?
What makes a Bitbucket export take longer or shorter?
The biggest drivers are repository count, total size including LFS objects, the volume of pull request and comment history, and how many API calls the export needs. Git history itself moves quickly with a mirror, so the time goes into everything around it. Pull requests, reviews, comments and wiki pages are read through the API, which Bitbucket Cloud limits to 1,000 requests per hour for most resources, so a large history can run for many hours or days if it is paced to stay under that limit. Data Center installations are governed by the server's own configuration, so the throughput depends on your infrastructure. Ask the provider to show the request count it expects per repository before agreeing to a schedule.
Can our own engineers run a Bitbucket export without outside help?
Yes, for a small, simple estate. Cloning repositories with git clone --mirror and pushing them to a new forge is routine work for any engineer who knows Git. The harder parts are the platform data: pull requests, inline review comments, issues and wikis need a platform importer or a scripted API pass, and each importer has its own gaps. Teams that have many repositories, long review histories or LFS-heavy projects often find that the scripting, rate-limit handling and verification take more time than the copy itself. Decide early which artifacts you must keep, then test the export on two or three representative repositories before you commit to the full run.
What do we need to provide before an export starts?
A short list of inputs makes scoping faster and avoids rework:
- Administrator access to the Bitbucket workspace or Data Center instance, plus a token or app password with read scope for repositories, pull requests and wikis.
- A list of workspaces, projects and repositories to include, with owners for each.
- A decision on retention: which pull request history, comments and attachments must be kept, and for how long.
- A decision on permissions: whether branch rules, reviewer groups and user mappings must be recreated in the target forge.
- Access to the target environment, including hosting location, storage capacity and the identity provider that users will sign in with.
Also confirm whether any repositories contain regulated or personal data, because that affects where copies may be stored during the transfer.
What happens to Bitbucket Pipelines, variables and secrets during an export?
Pipeline definitions in bitbucket-pipelines.yml are ordinary files and move with the repository. Repository and deployment variables, especially secured ones, cannot be read back through the API once stored, so they must be re-entered in the new platform from the source of truth, such as your secrets manager or the owning team's records. Treat this as a rotation exercise: generate new credentials where possible instead of copying old ones. Build the inventory of variables before the export starts, because the team that set each value may no longer be available later. Any pipeline that depends on a Bitbucket-specific feature will need rewriting for the new CI system.
How does the cost of an export split between staff time, storage and infrastructure?
Most of the cost is people. Engineers or consultants plan the scope, script the API pulls, handle rate limits, map users and permissions, and verify each migrated project. Storage is a smaller, recurring item: the target needs disk for Git objects, LFS content, attachments and backups, and temporary space while transfers run. Infrastructure covers the servers or cloud accounts that run the job, plus any network egress from the source. Staff time is largely one-time, while storage and backups recur. The main levers are repository count, LFS volume and how much history you keep. Ask for each component to be quoted separately so you can see where the effort sits.
What should a written quote for a Bitbucket export include?
A written quote should follow a written scope, so ask for the inventory the work is based on: repository count, total size, LFS volume, pull request and comment counts and the wiki and issue data to be moved. It should list the deliverables, such as mirrored repositories, migrated review history, a user and permission map, a variable inventory and a verification report. Ask which steps are fixed and which depend on rate limits or the source platform's behavior, and how retries and failed items are handled. Confirm who holds backups during the transfer, what acceptance checks apply and what support follows the cutover. DeployOpen does not publish a price list, and a quote follows from that written scope.
How DeployOpen works on this
DeployOpen treats a Bitbucket export as a fixed-scope engagement inside your own infrastructure. We agree in writing which repositories, pull request history, wiki and issue data move, where they land, and how the result is checked before anyone switches off the source.
How we scope
- Inventory repositories, LFS usage, pull request volume and wiki or issue data before any export starts.
- Confirm which Bitbucket Cloud or Data Center contract dates and API rate limits shape the export schedule.
- Agree in writing the target platform, hosting location, Pipelines variables handling and acceptance criteria.
How we build
- Mirror Git history and LFS objects to the target forge, then verify commit counts and branch heads.
- Script pull request and comment extraction through the Bitbucket API within documented rate limits.
- Document which Pipelines secrets must be re-entered manually, since Bitbucket does not expose them for reading.
How we hand over
- Deliver a written migration record listing what moved, what was skipped and why, with verification results.
- Provide runbooks for re-creating branch permissions, webhooks and integrations in the target platform.
- Keep a retained archive of the source export so audit and records requests can be answered later.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Confirm with us whether a retainer should cover the target platform's upgrade path and security patches.
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list.
