The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | Foundations |
| Maturity | N/A |
| Content Last Reviewed | 2025-04-07 |
Thanks for visiting this category direction page on Importers in GitLab. This page belongs to the Import and Integrate group of the Foundations stage and is maintained by the group's Product Manager, Magdalena Frankiewicz (E-mail, Calendly).
This direction page is a work in progress, and everyone can contribute:
A typical organization looking to adopt GitLab already has many other tools. Artifacts such as code, issues, and epics may already exist and are being used daily. Seamless transition of work in progress is critically important, and a great experience during this migration creates a positive first impression of GitLab. Solving these transitions, even for complex cases, is crucial for GitLab's ability to expand in the market. Instilling confidence in users that their data will be migrated quickly and with maximum care is of utmost importance. Supporting GitLab's objectives of driving first order growth, accelerating customer value, and enabling customer-focused innovation, the Import and Integrate group is focused on making imports reliable and performant at any scale. Large-scale moves to GitLab should be significantly easier and ultimately reach a first-class experience level.
Our focus areas for improvement include:
Ease of use Customers looking to import their data sometimes struggle to find the place in GitLab where they can initiate imports. Once found, the user interactions are not always intuitive, and the flow is not fully user-friendly. Improving the user experience in this area will make our importers more lovable.
Reliability A portion of our current issues are related to the solution's reliability. Imports don't always succeed, and when they fail, there is little guidance for users on steps they can take to remedy the failure. We are working on making our importers more reliable so that our customers can have confidence in the migration process.
Scalability and performance Large organizations looking to move possibly hundreds or thousands of projects from tools like GitHub or Bitbucket to GitLab, or from self-managed GitLab instances to GitLab.com or GitLab Dedicated, need to be able to do so efficiently and reliably.
The Import and Integration group is primarily focused on:
Our roadmap for the upcoming year (rolling 12 months) is focused on three main initiatives:
1. Strengthen customer confidence with migration by direct transfer General Availability Migration by direct transfer has been available as a Beta feature, but many enterprise customers avoid using it due to internal policies requiring GA products for mission-critical systems. We plan to bring Direct Transfer to GA status in Q2 FY26, providing enterprise customers with the assurance they need while delivering a smoother, more reliable migration experience. Work includes:
2. Enable migrations between offline GitLab instances PubSec and highly regulated customers often maintain GitLab instances in offline environments. Currently migration by direct transfer require internet connectivity, making it difficult for these customers to move data between instances. By implementing support for semi-automated migrations between offline instances in Q3 FY26, we'll address the needs of these customers.
3. Enable imports from various third-party providers We're working on defining a standard data format and providing tools for contributors to build compatible importers outside of GitLab's main codebase. This will allow us to support imports from a wider range of platforms without increasing our maintenance burden.
Engineering-led Initiative: Standardizing Importers
In parallel with our product-led initiatives, our engineering team is working on standardizing importers to improve consistency, security, and performance by creating reusable components. This will:
In Q2 we're working to strengthen customer confidence by bringing migration by direct transfer to General Availability.
Simplify and speed up contribution and membership mapping after imports Mapping user contributions after migrations was a manual, time-consuming process that must have beeen done through the UI one user at a time. For organizations with hundreds or thousands of users, this was a significant bottleneck. We've implemented bulk CSV-based mapping to dramatically reduce the effort required to preserve user contributions during migrations. This enhancement benefits not just migration by direct transfer between GitLab instances but also third-party importers, including those for GitHub, Bitbucket Server and Gitea. This work has been delivered in Q1 FY26.
Given our focus on the initiatives above, we are not currently prioritizing:
The Import and Integrate group is not focused on the ability to regularly back up and restore your GitLab data, for example nightly backups of all your data. For more information on this use case, please see the Backup and Restore category direction page.
BIC (Best In Class) is an indicator of forecated near-term market performance based on a combination of factors, including analyst views, market news, and feedback from the sales and product teams. It is critical that we understand where GitLab appears in the BIC landscape.
This table provides a quick overview of what GitLab importers exist today and which most important objects they each support. This list is not exhaustive and the detailed information can be found on the Importers documentation page.
| Import source | Repos | MRs | Issues | Epics | Milestones | Wiki | Designs | API * |
|---|---|---|---|---|---|---|---|---|
| Group and project migration by direct transfer | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Group migration with export files (deprecated) | ➖ | ➖ | ➖ | ✅ | ✅ | ➖ | ➖ | ✅ |
| Project migration with export files | ✅ | ✅ | ✅ | ➖ | ✅ | ✅ | ✅ | ✅ |
| GitHub | ✅ | ✅ | ✅ | ➖ | ✅ | ✅ | ➖ | ✅ |
| Bitbucket Cloud | ✅ | ✅ | ✅ | ➖ | ✅ | ✅ | ➖ | ✅ |
| Bitbucket Server | ✅ | ✅ | ❌ | ➖ | ❌ | ➖ | ➖ | ✅ |
| Gitea | ✅ | ✅ | ✅ | ➖ | ✅ | ➖ | ➖ | ❌ |
| Git (Repo by URL) | ✅ | ✅ | ➖ | ➖ | ➖ | ➖ | ➖ | ✅ |
| Manifest file | ✅ | ✅ | ➖ | ➖ | ➖ | ➖ | ➖ | ❌ |
| FogBugz | ➖ | ➖ | ✅ | ➖ | ➖ | ➖ | ➖ | ❌ |
* This column indicates whether this importer is accessible via API, in addition to the UI.
While our long-term goal is to provide all the GitLab importing capabilities needed by our customers in our application, we recognize that specific migration scenarios may require additional support. GitLab Professional Services team uses the Congregate tool to orchestrate user, group, and project import API calls to help customers automate scaled migrations. With migration by direct transfer reaching GA status, we'll be able to enhance the capabilities of Congregate and provide a more reliable and scalable migration experience for our largest customers.
For complex migrations, especially for large enterprise customers moving to GitLab Dedicated, we recommend engaging with our Professional Services team to ensure a smooth transition.
If you have feedback on our importers, please share it on our feedback issue. Your input helps us improve these tools for everyone.