The Life Changing Magic of Migrating Github repositories with Transposit
Tags: softwaredevelopment, github, sql, api
Published: 2019-03-15 16:29:21

---
title: The Life Changing Magic of Migrating Github repositories with Transposit
published: true
tags: software-development,github,sql,api
canonical_url: https://blog.transposit.com/the-life-changing-magic-of-migrating-github-repositories-with-transposit-347298d14729
---
Written by Nina Yang


I’m not a hoarder. I just _happen_ to manage a ton of GitHub repositories all shoved into one organization. But we need all of these repositories, I swear!

To help developers easily interact with APIs, Transposit has built an assortment of connectors. Each connector lived in its own repository within a single GitHub org. But as our library of connectors grew, our org became more and more cluttered. It was time to [KonMari](https://konmari.com/) them and tidy up.

![](https://cdn-images-1.medium.com/max/1000/0*_YeVcr2A2i1ZzK2G.png)<figcaption>Photo credit: <a href="https://www.twotwentyone.net/nursery-dresser-organization/">twotwentyone.net</a></figcaption>

### **The goal**

Create a new GitHub org and migrate our ~100 connector repositories over to it. Do this quickly and comprehensively to minimize disruption to developers interacting with these connectors.

### **The implementation**

Of course I wanted to automate this — making processes like these straightforward was [one of the reasons we built Transposit](https://dev.to/ellieseoejung/automation-through-the-eyes-of-an-engineer-2560-temp-slug-7154227)! But I was still surprised by how simple it was to translate the task into code.

#### Step 0: Create a new GitHub org

I did this manually.

#### Step 1: Fetch the repository names from the existing org

![](https://cdn-images-1.medium.com/max/1024/1*bRpGPK4WKGlLR__Fedk6jQ.png)<figcaption>In Transposit, it’s one line of JavaScript</figcaption>

![](https://cdn-images-1.medium.com/max/1024/1*q88dG-BzL0DLsonCQGQj9Q.png)<figcaption>… or one line of SQL</figcaption>

One of the great features of Transposit is that it takes care of the OAuth dance and credential storage for the developer. After storing a client ID and secret it was just a few clicks to allow Transposit access to my GitHub account.

#### Step 2: For each connector repository, create its namesake in the new org

When we were crowding all our repos into one GitHub org, we used the prefix “app\_” to distinguish our connector repositories from other code (our main codebase and supporting projects). Thus, I could use this prefix to identify the correct repositories to migrate and then drop it because it was no longer needed.

I made an operation that created the new repo:

![](https://cdn-images-1.medium.com/max/1024/1*ofAINd4aFhPelj7WKJ_4lg.png)<figcaption>This operation can be invoked as “this.create_repo_in_org”</figcaption>

My main operation applies it to all repos with the “app\_” prefix:

![](https://cdn-images-1.medium.com/max/1024/1*VGF1YanI94vBqVZixhQkvg.png)<figcaption>Not bad for &lt;20 lines of code.</figcaption>

I hit the “Run” button, and off it went.

#### Step 3: Realize that I’ve accidentally created all the new repositories as public and run a fix

Some of our connectors are open source, and some are still a work-in-progress and not _quite_ ready to be public. Whoops. Fortunately, with Transposit it was simple to change them back to private.

![](https://cdn-images-1.medium.com/max/1024/1*YYysFV0v6PVHBCY6UG8Blw.png)<figcaption>Whew!</figcaption>

#### **Step 4: Migrate repository contents**

I used a python script to copy the repository contents into their new homes. **However** , while writing this blog post I discovered that GitHub provides an actual [repository transfer API](https://developer.github.com/changes/2017-11-09-repository-transfer-api-preview/) I could’ve used which would have taken care of this step, and combining it with Transposit would’ve made the process even easier. Welp… good information for next time.

#### **Step 5: Notify my team to update their local repository remotes to point to the new org**

I wrote another script to do this. Again, it would’ve been better to use the repository transfer API, which will warn you about the updated remote _and_ still push to the new repository.

#### Step 6: Delete the old repositories

![](https://cdn-images-1.medium.com/max/1024/1*LyunFasxPvCv-obM1simxw.png)<figcaption>Look familiar?</figcaption>

### The end

There are other ways this migration could’ve been done. I could’ve manually transferred ownership of all the repos via the GitHub UI, but that would’ve taken forever. I could’ve done the migration using raw requests to the GitHub APIs, but that would’ve required poring over API and authentication documentation, and would’ve created more opportunities for error. There are also GitHub-specific CLIs that would have achieved the same outcome, but necessitated learning syntax that I was not likely to use again.

With Transposit, I used JavaScript and SQL to complete the migration in a few hours. The details of my API calls were abstracted away and I got to focus on the logic of my implementation rather than the minutiae of the setup steps. The process was quick and efficient and now all of our repositories are in their proper place.

Your use case might be different, but your sentiment of wanting to build without getting sidetracked in tedium could be the same. Maybe [Transposit](https://www.transposit.com/) can spark joy for you too.

* * *