Migrate Your Repositories To Github: Detailed Guide

There are many options you have if you want to switch from GitHub products, such as from GitHub Enterprise Server to Cloud, or from other code hosting platforms, such as GitLab. When this happens, you'll want to take your work with you, such as your code, code history, or all your past conversations and collaborations.

GitHub offers a wide variety of tools to help you with these migrations and that provide different levels of fidelity. We compiled best practices and some examples so you can start your migrations as soon as possible.

Github Migration: Best Practices

The first thing you should consider before starting the migration is to define what you want to migrate and when. Once this is clear, you must determine where the data is going to be moved from. Depending on the size and complexity of your business, there may be several different code hosting platforms in use.

And of course, you need to be clear about which GitHub product you're migrating to: your migration destination.

Build A Basic Inventory

Once you have these two points clear, you must specify what data you need to migrate.

Create a migration inventory with a list of all the repositories in their migration sources that you are migrating. This should collect data such as: name, owner, URL, last updated timestamp, number of pull requests, number of emissions.

Whatever approach you choose for your inventory, take note of the process you followed or the commands you executed. Once you have the list of repositories, you can choose which one to migrate. It will also be the perfect opportunity to evaluate and eliminate those that are not necessary, which will greatly simplify the migration.

Measure Sizes

Once you have your basic migration inventory, collect information about the size of your repositories. If they are large, they can make the migration longer and limit the tools available.

If you use Git as a version control system, not only large files are imported, but also the history of the repository. To continue, you will need to add the following data to the inventory for each repository: the largest file size (blob) and the total size of all files (blobs).

If, on the other hand, you use a different version control system or the files are not tracked by one, you will first need to move the repositories to Git. And then use git-sizer to get this data.

Decide The Type Of Migration

When deciding what type of migration to choose, you should consider the needs of your company and the tools available. In fact, different strategies can be chosen depending on the type of repository.

The Three Approaches To Do This Are:

• Source Snapshot: The current state of the code is migrated, without any revision history. It is possible for all sources and targets, even if the code is not yet tracked in a version control system.

• Source and history: The current state of the code and its history are migrated. Only possible if changes are tracked in Git or a version control system that can be converted to Git before migration.

• Source, history and metadata: the current code, its revision history and collaboration history are migrated. It requires specialized tools that are not available for all migration paths.

Design The Organization Structure

Each repository belongs to an organization, which are shared accounts where companies and open source projects can collaborate on multiple projects at the same time.

This is why it is so important to define the most effective structure for each organization and repository after the migration. This design can maximize collaboration and minimize administrative burden, or create silos and unnecessary expenses.

The recommendation they make from GitHub is to minimize the number of organizations and structure it according to one of five archetypes.

Take A Test

Before continuing with planning, it is very useful to perform a test migration that includes all your repositories.

This test will allow you to verify that the chosen tools work for your case, that they meet your requirements, you will better understand what data is migrated and what is not, as well as the time the migration will take.

Planning Pre- And Post-Steps

There will be some data or configurations that you will have to do manually. The steps necessary to do so will depend on each specific circumstance, but the most important steps are:

• Inform your users about the timing of the migration.
• Set up user accounts for the computer.
• Send instructions to update local repositories pointing to the new system

You must also take into account the post-migration steps:

• Inform users that the migration is complete.
• Link the activity to users at its origin destination.
• Dismantle the migratory origin.
• Continuous Integration (CI) and Continuous Delivery (CD) Migration

If you're already moving between GitHub products, you'll be using GitHub Actions for CI/CD and there won't be much to do as the workflow files in your repositories will be migrated automatically .If, on the other hand, you don't use GitHub Actions, the situation is more complicated. You will need to verify that the CI/CD provider supports GitHub and connect it to the new organization and repositories.

However, if you want to switch to GitHub Actions, it is not recommended to do so at the same time as migrating your repositories. It's best to wait until you're done and migrate the CI/CD as a separate step.

Team And Permission Management

If you migrate collaboration history or metadata, you'll need to link user activity to their new identities in the migration destination. The attribution process is what will allow you to do this .You will then be able to create your teams and add team members before migrating your repositories. You can manage them through your identity provider (IdP), linking your devices to IdP groups.

Github Migration Partner

When migrating, you can opt for a self-service migration, in which you plan and execute your own migration, without any professional support from GitHub. However, the best option is to trust a professional in the field where you can benefit from the knowledge and experience of an expert.

If you need to have a specialized partner and you don't know who to choose, we give you several reasons to choose Plain Concepts:

• We are the first partner in Spain accredited by GitHub.
• We have been working in the Agile culture that is a reference in the DevOps community for more than 17 years.
• We have a specialized team made up of more than 350 senior engineers in App Innovation and DevOps.
• Accredited as AMMP.
• DevSecOps with MVPs.

You will get numerous benefits, such as: the key points of migrations and pitfalls to avoid, training of your staff for upcoming migrations, documentation on the migration process and, finally, the migrated repositories.

If you want to start the migration now, don't wait any longer to contact us and our team of experts will be happy to help you get it started.