How to Migrate From CodeCommit

ICYMI

AWS recently announced that they will no longer be onboarding new customers for a number of services. Potentially one of the most painful being CodeCommit. While shuttering projects that aren't up to snuff isn't out of the ordinary, the suddenness with which they delivered this might be.

Luckily for you, you found this article. Where I'm going to show you how to quickly and easily migrate your code away from CodeCommit and to another source control service provider.

Prerequisites

Ensure you're setup with a source control provider. The most common choices on the market are Github, GitLab, and BitBucket. At minimum you'll need to make an account with the provider of you're choice.

Once you've completed that you'll need to make a repository with your new provider to house your code. Whichever provider you've chosen will have guides made that you can follow for this step. If you had any special repository configuration (e.g. branch protections) you may want to consider setting them up now.

The only caveat I have to add here is to ensure you don't commit to the new repo. We will be migrating our branches and their history to the new provider. Committing to your new provider before migrating will almost certainly cause conflicts (particularly to your main/master branch).

Getting Started

Before we get into the meat and potatoes, I want to outline our problems.

1. Moving all the contents of our repository from one remote repository to another

• "moving house".

1. Updating all local repositories to use the new remote

• Make sure all our friends know we've moved.

1. Updating automated systems to use the new remote

• Make sure the government knows we've moved.

As promised, I've made a repo with some shell scripts to help make this easier.

Moving House

Now let's get down to business.

To start ensure:

• your CLI is in the cloned helper repo

• you have the absolute path(s) of the repo(s) being moved

• you have the url(s) of the new remote repo(s)

From there you can plug all the above into either

$: bash main.sh /full/path/to/repo ${newRemoteUrl} ${newRemoteName}

Or if you have many repositories that need moved:

$: bash many.sh ${newRemoteUrl} ${newRemoteName}

Ensure you answer yes to both of the questions (pushing to the new remote and replacing origin in your local repository.)

This initial run of the scripts will add the new remote to your local repository and push your version of the history. It runs a git fetch so it should be up-to-date as long as you have an active internet connection. You then will have the option to update your local repository's origin remote to the new remote.

Updating Your Friends

Now ensure everyone working on the repo(s) also updates their local. Make sure everyone pushes any branches that they may have worked stored on locally. Then have them copy the previous step with one change.

Answering no to the push question

$: bash main.sh /full/path/to/repo ${newRemoteUrl} ${newRemoteName}

$: bash many.sh ${newRemoteUrl} ${newRemoteName}

Now on these later runs the script will add the new remote, but will not push to the new remote. Again as part of the script they can follow precedent and decide if they want the new remote to replace CodeCommit as origin.

Updating the Authorities

For this last step, you may be able to use the scripts I've provided, depending on your CI/CD architecture. But this bit likely will be out of scope and up to you to make the changes. If you run into issues, there are tons of amazing people who would love to help on

• re:Post

• AWS StackOverflow Collective

• The Support Center within your AWS account

• Many other platform and tool specific forums

Conclusion

Having to migrate Git providers can be an absolute nightmare with long tail consequences. Hopefully, with these scripts and the framework I've outlined you can make short work of what can be a daunting task.

Best of luck and hope this helps!

Find me on Mastodon | LinkedIn | Github | Substack