Bitbucket to GitLab Migration in a Few Simple Steps
Last Updated on July 15, 2024
Even in ancient times it was known that the world changes. Our lives, culture, and languages develop on a daily basis. Even colors on the map switch from time to time. Of course, the technologies around us are also developing. Our needs and expectations are also replaced with another ones. And that is what today’s post is about. It’s about the reasons and the need for changes, and, what’s more, about how to take some specific steps to do so.
Sometimes the effects of our previous decisions drag on us. Decisions that we might not even have had control over. There could be many reasons for that, and a lot of them are connected with the development of new technologies at the forefront. Although one can also look for a lack of knowledge or context, which ultimately leads to a wrong decision. Or, perhaps, there is no mistake, simply new better products and systems are developed. Does it open more opportunities for us?
Let the SVN version control system serve as an example. Once omnipresent, it served its purpose well. However, when Git appeared, it turned out that in many cases the new VCS is simply better and worth using. Choosing a technology for new projects is not problematic, but what about the migration of the entire existing repositories? This is exactly the type of change that carries some risk, but also opens up new opportunities.
Git hosting services
Similarly, we may need to change the Git hosting service that our project uses. Nowadays, this type of service is more than just a simple Git repository hosting one. The option to support Pull (or Merge) Requests are standard, but CI/CD tools to automate our workflow are now also dominant. The whole DevOps trend, although not the newest after all, is now being heavily exploited. And that’s a very good thing, because it opens a lot of opportunities for us, both in terms of the speed of our solution delivery to customers, and the level of security and risk minimization.
If you encounter issues, consider using a GUI-based import tool as an alternative approach for importing in Bitbucket Cloud. The Bitbucket importer is particularly useful for importing issues/pull requests and creating new namespaces if they don’t exist. The import process involves transferring data from one platform to another, including importing issues, pull requests, and repositories while handling scenarios like matching user email addresses and creating new namespaces if required.
💡 Building a workflow that meets our requirements and expectations allows us, for example, to create a backup after each action in our pipeline. On this topic, I recommend an article: The new era of DevOps.
Reasons for migration
It is also worth asking ourselves the fundamental question – “why do we want to perform a migration from one hosting service to another?” Improvements in Bitbucket Cloud and migration from Atlassian to GitLab can be significant factors. Of course, there can be many reasons, starting from licensing and fee issues, to technical considerations and knowledge base of our staff.
Importing projects from Bitbucket Server due to the fact that the Atlassian stopped supporting its server versions is another reason to migrate from Bitbucket to GitLab. Let’s not forget that popular services, though they are similar, have slight differences when we take a better look at them.
Bitbucket vs GitLab
Bitbucket certainly wins when it comes to the topic of integration with many popular tools. Jira, Bamboo, Crucible or Jenkins – this is a collection of popular applications with which Bitbucket integrates directly and easily. On the other hand, there are also purely subjective aspects. For example, personally I could never convince myself of the GUI of this service and always found it better to work with competitor services.
Are you switching to a DevSecOps operation model? Remember to secure your code with the first professional GitHub, Bitbucket, GitLab, and Jira backup.
GitLab, on the other hand, has always been relying on the aforementioned CI/CD aspect, and it does it well. It also excels in importing and matching pull requests from Bitbucket to GitLab. Building, testing and deploying code here can be automated very easily, which speeds up the work of our developers and ensures less risk of software bugs. Let me post one sentence from the GitLab documentation:
“This iterative process helps reduce the chance that you develop new code based on buggy or failed previous versions. With this method, you strive to have less human intervention or even no intervention at all, from the development of new code until its deployment.”
Additionally, GitLab ensures that the repository public access settings are retained during the import process from Bitbucket Server.
How to migrate a repository
We can divide the entire migration process into several stages:
- preparation
- cloning
- saving
During the preparation process we need to make sure that our repository contains the most current information. All the work done so far should be integrated. Then all tags and other necessary metadata should also be fully up-to-date. Basically, this is the most difficult stage and it is completely on our side. During this stage, matching users in the GitLab user database with Bitbucket Server user’s information is crucial for user assignment.
The next steps are git cloning and saving. During cloning, it is very important to retrieve all branches and tags. Here I recommend using the –mirror flag, which will take care of this. If the namespaces do not exist, the importer creates new ones or imports repositories under the user’s namespace if the namespace is taken.
After cloning, set the appropriate address of the new repository and simply push our copy to it. And that’s it. Of course, the last step is to configure the repository in the new service properly and make the project available to our developers, but this step should be taken after the actual migration is completed. Ensure that your personal access token is correctly configured for authentication when downloading or cloning LFS objects.
This entire process, of course, theoretically boils down to just the following few steps:
- git clone –mirror < GitLab_repo_address>
- git remote rm origin
- git remote add origin < GitHub_repo_address>
- git push –mirror
When importing features from other platforms, the project creator’s role is essential in ensuring a smooth transition. Searching for or matching user profiles with confirmed email addresses in the GitLab user database is necessary to find such user profiles.
User assignment by username, email address, and author information is a feature under development and involves matching users in the GitLab user database with the Bitbucket Server user’s details during the import process.
Cross-over data recovery
However, you can perform migration even faster and easier, and above all, more securely. Using the capabilities of the GitProtect.io software, and here I mean the cross-over data recovery feature, which can help easily perform such a migration.
If we have both Bitbucket and GitLab accounts added and authorized in the application, the migration is really easy and fast.
We should start with finding the backup to be used for our migration. Then, on the right side of the screen you can see the “Restore” function button:
The next step is to select a destination. Go to the “Restore to” section, where you can select any (previously added) organization on Bitbucket, GitHub or GitLab:
And that’s it! Performing such an operation will finally allow us to see the migrated project in another git hosting service. In this case, we performed a Bitbucket to GitLab migration, and you can see the final result below.
Conclusion
Keep in mind that every operation carries more or less risk, so you need to be prepared and always have an up-to-date backup in case something goes wrong. I recommend using third-party backup tools. Why? Let’s see, it automates your backup process and allows you to follow 3-2-1 backup rule – which is a golden standard in the backup world. All turnkey backup features that GitProtect.io provides. including long-term retention, replication, incremental and differential backups – everything in a bulk helps to withstand the outage and recover the data fast. And, if it’s needed, you can easily migrate your data from one git hosting service to another, e.g. from Bitbucket to GitLab.
[FREE TRIAL] Ensure compliant DevOps backup and recovery with a 14-day trial🚀
[CUSTOM DEMO] Let’s talk on how backup & DR software for DevOps can make your migration process smooth and secure
