State of GitHub migration tools

For some time I am working on migration projects from various platforms to GitHub. What I soon realized is the miserable state of the GitHub migration tools. It is easy to complain when you’re not involved in the development process and don’t know the priorities and decisions. Therefore, I would like to outline the current state of the migration tools and what we maybe can do better.

The “bad” parts

There a currently several migration tools, but they are fragmented by owner, purpose, tech stack and CLI commands.

First we have the three official GitHub CLI extensions for the migration from GitHub gh-gei, Azure DevOps gh-ado2gh and Bitbucket Server gh-bbs2gh to GitHub. This project is based on C# and dotnet and contains all necessary commands for a migration.

For the Bitbucket Cloud to GitHub migration there is the gh-bbc-exporter extension created by @katiem0. This extension is written in Go. The main purpose of this extension is to create an Bitbucket Cloud export archive. Since version 3.0.0 the extension also contains a command for the migration, but the command differs from the command of the gh-gei extensions.

And finally for the GitLab to GitHub migration there is the gl-exporter. This projects is a CLI based on Ruby 3.2.1. As the name says the main purpose is to create an GitLab export archive. The CLI provides no migration commands. This project is currently in a closed preview and only available for GitHub Partners. The biggest disadvantage of the gl-exporter is you can not install it directly as an GitHub CLI extension. You need either the Ruby stack or you build it as a Docker image, which is 1.51 GB in size at the end.

In summary, we can say the developer experience regarding migration tools is not the best.

The “good” parts

One of the good parts IMO is the Octoshift library, which is part of the gh-gei project. It serves as a foundation for the gh-gei, gh-ado2gh and the gh-bbs2gh extensions. This library could be easily reused for other platform extensions. The only part which must be provided is the export archive logic for a source platform.

How it could be

I can imagine that migration tools don’t have the highest priority at GitHub. Even the gh-gei project don’t seems to get much attention. The migration tools are predestined to be based on one tech stack and provide a consistent developer experience. A lot of the code base could be unified. The only custom part would be the export archive implementation for the source platform.

I have an idea ;)