Migration
Close Out
Close Out
Close out opens once the first repository has moved to its destination org, in the plan's sandbox organization. From here you make the Azure DevOps originals of moved repositories read-only, so no one keeps pushing to a repository that now lives on GitHub. You also confirm the last items CodeCargo cannot do itself: the final report sent, the sandbox archived on GitHub, and mannequins reclaimed in each destination org.
Opening Close out
You need the Migration Assistant manage permission. The Migration Plan is available on CodeCargo plans that include it. If you do not see it, contact your CodeCargo administrator.
Make Originals Read-Only
You do this one Azure DevOps organization at a time. Each original stays enabled. People can still read and clone it. Project Valid Users lose every write, so pushes to that original stop. The same job disables the Azure DevOps build definitions of that repository's pipelines that were migrated in its destination org. Pipelines that were not migrated keep running.
- Open Close out in the sandbox.
- Choose one Azure DevOps organization and which of its repositories to include.
- Give an Azure DevOps administrator's personal access token for that organization, then start. This is not the administrator token a move uses for disabled repositories: it also needs Build (read and execute).
CodeCargo takes on a repository only when its copy in the destination org exists, that copy is still found in GitHub, and something is left to do: the original is still writable, or a pipeline migrated from it still has an enabled definition. Anything else in the selection is left out:
- A repository that has not moved yet stays as it is.
- A moved repository whose copy is no longer found in GitHub stays writable, so there is still a copy someone can write to.
- An original that is already read-only, disabled, or gone, with no migrated pipeline still enabled, is left as it is. A disabled repository is not enabled.
Rewire, open references, and pipeline conversion do not have to be finished first. Close out shows them and does not wait on them.
CodeCargo checks the token before it changes anything, and forgets it when the job ends or when you stop the job. Give it again if you start again. The token needs Code (read), Security (manage), Identity (read), and Build (read and execute), and its holder has to be allowed to set permissions on the repositories. It does not need permission to disable a repository. Close out never disables or enables one. If that check fails, the start is refused and names the problem. Nothing is changed.
If a repository cannot be found in a project, refresh the inventory and start again.
When a start is refused
A start is refused while that organization already has a job running. Wait for it to finish, or stop it first. It is also refused when the plan, or the repositories left to make read-only, changed since you listed them. Check the list and try again. If none of the selection is left to make read-only, the start says why.
In the sandbox you need to be a member who can migrate repositories to start or stop this.
Starting reports how many selected repositories it did not take on: not moved yet; already read-only, disabled, or gone, with no migrated pipeline still enabled; or moved, but no longer found in GitHub.
While It Runs
Each repository it took on is waiting, being made read-only, read-only, already disabled, gone from Azure DevOps, or failed. CodeCargo confirms the change before it counts a repository read-only, so a large organization takes a while.
- If someone else changed a repository's permissions for Project Valid Users after CodeCargo read them, that repository is left as it is and marked failed. Start again to make it read-only as it stands now.
- A repository Azure DevOps refuses, or will not show, fails on its own. The rest continue.
- A repository Azure DevOps no longer lists counts as gone.
Stop the job when you need to. Originals already made read-only stay read-only. Starting again takes on the rest, including any that failed.
A job ends when every repository it took on is finished, when you stop it, after 24 hours, or when Azure DevOps rejects the token. After 24 hours, or after the token is rejected, start again for what is left.
When the Step Is Done
Done when:
- Azure DevOps originals read-only - how many of the repositories with a destination. An original already disabled counts, and one gone from Azure DevOps counts as done. See the N left lists the rest.
- Mannequins reclaimed in each destination org.
- Sandbox org archived on GitHub.
- Final report sent.
You confirm the last three. They are not required until every repository with a destination has moved. The step needs you when a repository failed, when a moved original is still writable and no job is running for its Azure DevOps organization, or when every repository has moved and a confirmation is due.