Migrating Git

If you want to change your system landscape, you might want to move your git repositories (repos) as well. However, there are always challenges and questions that you will need to think through and clarify in advance. We’ve been there and done that, and now we would like to share some of our experiences.

The Situation

From time to time and for reasons obvious only to themselves, IT people will decide to move their software environments even though they are working perfectly. They do this despite the fact that it contradicts the most important basic principle of operations: “If it works, don’t touch!” It really is worth taking this motto to heart.

Of course, there can be reasons for you wanting to take this step: for example, you would like to build your own environment or change providers because the new solution is better. If it’s meant to be, then it’s meant to be.

And, of course, a version control system is perhaps the most important part of all modern environments. Single source of truth, as they often say. This is where all changes to the system are stored in a traceable manner. So, with a well-designed system, you can follow important and reasonable rules, you can respond well to different needs in different branches … Git is clearly important, as you can see.

And as it has become a sort of standard, we’ll carry on talking about Git now. Admittedly, the author has still seen Subversion in use, but he also remembers times when Robbie Williams was a member of a teenage boy band.

The Task

When changing environments, Git has to move as well. You simply migrate the entire structure, and after a quick configuration update, everything can continue as usual: developers can continue developing their applications, operators can maintain their configurations, colleague Jenkins can do all the tasks assigned to him in an automated way. Sounds easy, doesn’t it?

It’s a Trap

As you can probably guess, the answer is “yes and no” at best, but it is more likely to be “NO!!!”. With one of our customers, we solved the task quite smoothly, but getting there was everything but easy.


One important question up front was what had to be moved in the first place. If you have more than 100 repos in a system, it is possible that some of them are already somewhat outdated. You don’t even need them anymore because they have grown historically and long sunk into oblivion. Another question is exactly what content to migrate from these repos: the latest state of the code changes stored by Git, or all versions? This might be interesting for historians. Or for auditors, should these systems be important.


Interesting question, don’t you think? Where should the files go? Well, into the new Git, and that’s it. Or not?

Er … no. The move might give you the opportunity to change the somewhat outdated system and create a new project and repo structure.

Does such a structural reform necessarily have to take place during a move? In this specific case, it did. The new environment was also supposed to provide a new structure. And we solved the task, everything ended up where it belonged.


It would have been really simple to just import the repos using the solutions built into the new system. You’re probably not surprised to hear that it didn’t work that way: “We copied the address and clicked *Next*” would not be worth writing about.

So, we designed a general solution that met all requirements.

After creating the new structure, clarifying the individual components, getting the necessary permissions, deciding whether the newly created repos should only contain the last status of the main branch or also all existing branches including history … after consulting with the responsible colleagues whether certain mechanisms set up for validating the individual commit messages could be switched off for a short time (and whether referenced ticket numbers could be reassigned in the new structure), everything worked quickly and smoothly thanks to our solution.

And this can also be repeated successfully in similar cases.


It is not impossible to migrate a Git repo. But implementing a version control structure with all its details in a new environment is something completely different. Are you looking for a solution for the latter? We are happy to share our experiences with you. And we’d like to emphasize one thing: to create something useful, you need to consider many things in advance. And we know what factors can affect the desired result.

Git Schulung

In our Git training, admins and opsies learn to collaborate efficiently with colleagues via Git, manage Git repositories, and troubleshoot issues that arise on their own.

The following two tabs change content below.

Gergely Szalay

IT Consultant at ATIX AG
Gergely Szalay arbeitet als IT Consultant, Schwerpunkt Kubernetes. Er verfügt über langjährige Erfahrungen im Application Support.