How to Migrate From CodeCommit
A short guide on how to migrate away 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"
Updating all local repositories to use the new remote
Make sure all our friends know we've moved.
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
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!
