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. 

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?” Of course, there can be many reasons, starting from licensing and fee issues, to technical considerations and knowledge base of our staff. 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. 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.”

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.

The next steps are 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.

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.

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

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:

Restore Backup - GitProtect

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:

Restoring data with GitProtect

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. 

GitProtect UI

Destination section - GitProtect

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. 

Comments are closed.

You may also like