Migration Plan
Plan the Org Layout
Plan the Org Layout
Open Plan the org layout from the Migration Plan journey, under Organize. This is where you name the GitHub orgs repositories in the plan land in. The sandbox organization, where the plan lives, is never a destination.
Each destination org is one of:
- Planned — only in the plan, under the GitHub name it will have
- Created — GitHub has an org with that name, and CodeCargo is not installed on it yet
- Connected — linked to a CodeCargo organization in the same GitHub enterprise, with CodeCargo installed
The list is soonest needed first. Each org shows its purpose, its owner, whether it is the building block home, how many repositories it takes, the date it is first needed and why, and whether its GitHub name is free, taken, or not yet known. A name that was free and is now taken by something other than the created org is called out — choose another name. If GitHub cannot answer a later check, the last result stays.
The plan has one building block home. Making an org the building block home takes the role from whichever org had it.
Opening the page
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.
Add or Change an Org
Add a destination org by the GitHub name it will have, and optionally a purpose and an owner. A name is 1 to 39 letters, digits, and single hyphens, and it does not start or end with a hyphen. CodeCargo checks the name on GitHub as you add it.
- If no GitHub account has the name, the org stays planned and the name is free.
- If the name is a GitHub org in your enterprise that already has CodeCargo installed, the destination org links to it and starts connected.
- Any other name a GitHub user or org already has is taken. So is a name whose enterprise CodeCargo cannot tell yet.
The plan refuses a name it already has, the sandbox organization's name, and a CodeCargo organization already linked to another of the plan's orgs.
While an org is planned, you can rename it. A new name is checked the same way. Changing only the capitalization keeps the name the plan already knows. A linked org's name is its name on GitHub — unlink it to plan a different one. Once GitHub has created the org, the name stays. Install CodeCargo on it to connect it.
Change the purpose or the owner at any time, or clear either one.
Link, Unlink, or Remove
Link a destination org to a connected CodeCargo organization in the same GitHub enterprise. It becomes connected and takes that organization's GitHub name. Repositories already assigned to it stay assigned. The page lists the organizations you can link to.
Unlink it under a new planned name, different from the linked organization's name. Under its own name it would be linked again. Repositories stay assigned. If the new name already belongs to an installed organization in your enterprise, that organization is linked instead.
Remove a destination org to take it off the plan. Projects and repositories sent to it go back to having no destination of their own. Nothing is deleted on GitHub or in CodeCargo. The plan refuses the removal while a destination rule still sends repositories to it, and names the rules in the way. Change or delete those rules first.
From Planned to Connected
CodeCargo checks a name when you add it, rename it, or unlink under a new name, and checks planned names again about once an hour.
A planned name keeps the first check that found it free. It becomes created when a later check finds a GitHub org with that name that was created after the name was free. The row includes a link to install the CodeCargo GitHub App on that org. It becomes connected once that org is in the same GitHub enterprise and CodeCargo is installed there. On github.com, that enterprise is confirmed only after the app is installed.
If CodeCargo is no longer installed on the linked organization, the destination org reads as planned again until CodeCargo is back or you unlink it.
Copy the request hands whoever creates orgs in your enterprise what to create.
Migration Plan
Follow the plan journey, the recommended next step, and the summary of what is left.
Plan Repositories
Filter the plan's repositories and assign them to a destination org, a wave, or both.
Migrating Repositories
Connect a source and copy repositories to GitHub.
What a linked org still needs
Before waves move repositories into a linked destination org, that org shows a checklist for each source connection that sends them. The checklist is headed by the connection's name. A met step is ticked. A step that is not met yet shows a dot. When only some of it is done, the label says how much is left.
An org that is not linked shows no checklist. Its state already says what to do next.
An unmet step links to the page in that organization where you fix it:
- Connections — link the source, or inventory the repositories that are not inventoried yet
- Import — import pipelines that are not imported yet
A missing GitHub App service connection is made in the source, so that step has no page in CodeCargo. It names the projects that still need one. A long list names the first few and how many more.
Which steps appear depends on the source. For Azure DevOps, the checklist covers the link, the inventory, imported pipelines, and a GitHub App service connection on each project that rebinds.