CodeCommit Repository Detected: Migrating Off a Deprecated Git Host

In July 2024, AWS quietly stopped onboarding new customers to several developer tools, CodeCommit among them. There was no splashy deprecation banner and no hard shutdown date, but the message between the lines was clear: CodeCommit is in maintenance mode. Existing repositories keep working, but you will not see new features, and AWS is steering customers toward third-party Git providers instead.

If Lensix raised the cicd_deprecated check on your account, it found at least one CodeCommit repository in your AWS environment. This post explains what that means, why hosting your source on a frozen service is a long-term risk, and how to move off it cleanly.

---

What this check detects

The CodeCommit Repository Detected check, part of the Lensix cicd_checks module, scans your AWS account for any repositories provisioned in AWS CodeCommit. CodeCommit is a managed, private Git hosting service that AWS launched in 2015. The check fires whenever it finds one or more repositories, regardless of how active they are.

You can confirm what the check found with a quick CLI call:

aws codecommit list-repositories --output table

If that returns repository names, those are the ones flagged. To see when each was last touched:

for repo in $(aws codecommit list-repositories --query 'repositories[].repositoryName' --output text); do
  echo "Repo: $repo"
  aws codecommit get-repository --repository-name "$repo" \
    --query 'repositoryMetadata.{Name:repositoryName,LastModified:lastModifiedDate,DefaultBranch:defaultBranch}' \
    --output table
done

---

Why it matters

A deprecated source control service is not the same as a leaking S3 bucket. Nothing breaks tomorrow. The risk is slower and more structural, which is exactly why teams tend to ignore it until it becomes painful.

No new features and shrinking ecosystem

CodeCommit never matched the developer experience of GitHub or GitLab. It has no pull request review tooling worth speaking of, no built-in CI runners, no marketplace of integrations, and no code search across repos. Now that it is frozen, that gap will only widen. Modern workflows like merge queues, required status checks tied to rich review, and AI-assisted code review are simply not coming.

Integration rot

Third-party tools, IDE plugins, and SaaS platforms prioritize the providers their customers actually use. As CodeCommit usage declines, expect first-class integrations to thin out. You end up building and maintaining custom glue code for things that are one-click elsewhere.

Hiring and onboarding friction

Almost every engineer knows the GitHub or GitLab pull request flow. Very few have used CodeCommit. Every new hire pays a small tax learning an unfamiliar, less capable tool, and that tax compounds across a team.

Migration gets harder the longer you wait

Git history migrates cleanly. The hard part is everything wired around the repo: CodePipeline triggers, CodeBuild source stages, IAM policies, Lambda hooks, and approval workflows. The more automation you build on a deprecated foundation, the larger and riskier the eventual migration becomes.

---

How to fix it: migrating off CodeCommit

Migration breaks into three parts: move the Git data, repoint your CI/CD, and decommission the old repo. Below is the path for moving to GitHub, but the same shape applies to GitLab or Bitbucket.

Step 1: Mirror the repository

First, get a complete copy of the source repo including all branches and tags. A bare mirror clone is the safest way to capture everything.

# Clone the CodeCommit repo as a bare mirror
git clone --mirror \
  https://git-codecommit.us-east-1.amazonaws.com/v1/repos/my-service \
  my-service.git

cd my-service.git

Step 2: Create the destination repo and push

Create an empty private repository on your new host first. With the GitHub CLI:

# Create an empty private repo on GitHub
gh repo create my-org/my-service --private --confirm

# Push every branch and tag from the mirror
git remote add github [email protected]:my-org/my-service.git
git push github --mirror

The --mirror push transfers all refs: branches, tags, and notes. Verify the result by cloning the new repo fresh and checking your branch list and recent commits match.

Step 3: Repoint CI/CD source stages

This is the real work. Find everything that reads from the CodeCommit repo. If you use CodePipeline, your source stage references the repo directly. Replace it with a GitHub connection using a CodeStar connection:

# Create a connection to GitHub (returns a connection ARN)
aws codestar-connections create-connection \
  --provider-type GitHub \
  --connection-name github-my-org

Then update the pipeline source action. In Terraform, a CodePipeline source stage shifts from this:

{
  "name": "Source",
  "actions": [{
    "name": "Source",
    "category": "Source",
    "owner": "AWS",
    "provider": "CodeCommit",
    "version": "1",
    "configuration": {
      "RepositoryName": "my-service",
      "BranchName": "main"
    },
    "outputArtifacts": ["source_output"]
  }]
}

to this:

{
  "name": "Source",
  "actions": [{
    "name": "Source",
    "category": "Source",
    "owner": "AWS",
    "provider": "CodeStarSourceConnection",
    "version": "1",
    "configuration": {
      "ConnectionArn": "arn:aws:codestar-connections:us-east-1:111122223333:connection/abcd-1234",
      "FullRepositoryId": "my-org/my-service",
      "BranchName": "main"
    },
    "outputArtifacts": ["source_output"]
  }]
}

Step 4: Run both in parallel, then cut over

Do not delete the CodeCommit repo the moment you push. Keep it as a read-only fallback for a sprint or two while the team confirms the new repo, CI, branch protection, and access work end to end. Make the old repo read-only so nobody accidentally pushes there:

# Deny pushes to CodeCommit via an IAM policy attached to developers
# Effect: developers can read but not write to the old repo
aws iam put-user-policy \
  --user-name dev-team \
  --policy-name deny-codecommit-push \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Deny",
      "Action": ["codecommit:GitPush", "codecommit:PutFile", "codecommit:MergeBranchesByFastForward"],
      "Resource": "*"
    }]
  }'

Step 5: Decommission the old repository

Once you have verified the migration and everyone is working from the new host, delete the CodeCommit repo.

# Optional: create an offline backup bundle first
git bundle create my-service-backup.bundle --all

# Delete the CodeCommit repository
aws codecommit delete-repository --repository-name my-service

---

How to prevent it from happening again

Once you are off CodeCommit, the goal is to stop anyone from quietly spinning up a new repo there or re-creating the dependency in IaC.

Block CodeCommit with a Service Control Policy

If you run AWS Organizations, an SCP is the cleanest guardrail. It prevents repository creation across every account, regardless of individual IAM permissions:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyCodeCommitCreation",
    "Effect": "Deny",
    "Action": [
      "codecommit:CreateRepository"
    ],
    "Resource": "*"
  }]
}

Catch it in code review with policy-as-code

Stop the dependency before it merges. A Checkov or OPA rule can fail any pull request that introduces an aws_codecommit_repository resource. A minimal Conftest policy looks like this:

# policy/codecommit.rego
package main

deny[msg] {
  resource := input.resource.aws_codecommit_repository[name]
  msg := sprintf("CodeCommit is deprecated. Do not create repository '%s'. Use GitHub or GitLab instead.", [name])
}

Wire that into your CI as a required check so no Terraform plan introducing CodeCommit can ever ship.

Keep the Lensix check running

Leave the cicd_deprecated check enabled even after migration. It acts as a continuous backstop: if someone creates a CodeCommit repo manually in the console, bypassing your IaC pipeline and SCP, Lensix surfaces it on the next scan instead of letting it linger for months.

---

Best practices

• Decide your target host once, organization-wide. Fragmenting across GitHub, GitLab, and Bitbucket per team multiplies your access management and CI overhead. Pick one and standardize.
• Migrate history, not just the latest snapshot. Always use git clone --mirror and git push --mirror so branches, tags, and full history come along. Blame and bisect are worthless without history.
• Re-establish branch protection on day one. CodeCommit's approval rules do not translate automatically. Configure required reviews, status checks, and protected branches on the new host before developers start pushing.
• Treat the migration as a chance to modernize CI. Rather than rebuilding CodePipeline around an external repo, evaluate the native CI of your new host. Fewer moving parts and fewer deprecated dependencies.
• Audit IAM and secrets. Remove CodeCommit-specific HTTPS Git credentials and SSH keys from IAM users once they are no longer needed. Stale credentials are a standing risk.
• Document the cutover. Write down the old and new URLs, the date of the read-only switch, and the deletion date. Future engineers tracing an old commit link will thank you.

CodeCommit being deprecated is not a fire drill, but it is a clock running quietly in the background. The teams that move deliberately now, while their automation footprint is small and the deadline is theirs to set, will spend a fraction of the effort that teams forced into a rushed migration later will. Treat the Lensix finding as the nudge to schedule it.