This article refers to issues encountered with the process of migrating repositories owned by an organization from github.ncsu.edu to the GitHub Enterprise Cloud service.
GitHub has a document describing a number of different errors that might be reported when using git and ssh: https://docs.github.com/en/authentication/troubleshooting-ssh
One error not listed on that page is Error: Repository not found
After verifying in the web interface that repository does exists and you are using the correct git clone url for the project - and that you have authorized your ssh key - if you get that Error: Repository not found error, it’s then likely that your ssh client is sending the wrong ssh public key to GitHub, and GitHub is associating your git-with-ssh operation with the wrong user.
The best way to troubleshoot this is to run ssh -T git@github.com in a terminal window/shell session. You should see the following:
Hi unityid_ncstate! You've successfully authenticated, but GitHub does not provide shell access.
Seeing a different account is an indication that you are sending the wrong public key to GitHub. Check your ssh configuration settings on your platform for IdentityFile and IdentitiesOnly settings.
If you get the following error when trying to migrate your repositories:
[2025-02-25 13:41:08] [ERROR] unityid_ncstate does not have the correct permissions to execute CreateMigrationSource. Please check that: (a) you are a member of the TARGET-ORG organization, (b) you are an organization owner or you have been granted the migrator role and (c) your personal access token has the correct scopes. For more information, see https://docs.github.com/en/migrations/using-github-enterprise-importer/preparing-to-migrate-with-github-enterprise-importer/managing-access-for-github-enterprise-importer.
The most likely scenario is that you left off the workflow scope for the GitHub Cloud token. The two tokens have different recommended scopes, and the target token needs the workflow scope.
Git submodules allow you to embed one Git repository inside a parent repository as a subdirectory. However, they are pinned to a specific commit in a remote repo and git doesn't know how to update those paths for you after a migration. If you make use of submodules and you move those submodules, you will also have to update all of the submodule references in each of the repos that reference them. There are tools out there like https://github.com/austenstone/migrate-submodules that will do a "mass search and replace" and create a commit on the repo to update submodule references if the only change made was to move the repo from a github.ncsu.edu organization to a GitHub Enterprise Cloud organization.