Move Repositories

Move Repositories

Move repositories is the first stage of a wave page. It copies the wave's repositories into their destination orgs: you prepare a draft migration in each org, then start, retry, or stop the move from the wave.

This stage shows how long the move is expected to take, the repository expected to take the longest, and the move window. It also shows the expected time for each destination org. See How Long a Move Takes.

The stage lists the wave's repositories and where they land. It counts how they move, including Migrate again, Needs a fix, Dry run pending, and Not copied yet. Needs a fix is a dry-run copy that needs a fix. Dry run pending is queued or still copying. Not copied yet has not been copied. Finish that copy on Dry Run. It also counts repositories that use Git LFS, and repositories not checked for Git LFS yet.

Prepare the Move

Prepare the move saves a draft repository migration in each destination org. The draft is owned by that org and copies from the sandbox's source connection and inventory, under the names the plan predicts. The destination does not need its own source connection or inventory. The draft is named for the wave, such as Plan wave 1: Data platform. A destination gets more than one draft when its repositories come from more than one Azure DevOps organization or GitLab group, or do not fit in one migration. Those add a part, such as (2 of 3).

Preparing is refused, naming each org and why, until every destination is ready for the move. Readiness is the To do list on Plan the Org Layout. For the move, that is whether each source is connected and inventoried in the sandbox.

A repository is left out of the draft when:

• the predicted name is used twice, or is already taken there
• it is already migrated there
• the migration's preview blocks it
• a migration there has already started and does not hold it

A repository a dry run in the sandbox is still copying is already in a migration. The move cannot take it until that copy finishes.

Prepare again updates the same drafts and removes a draft the wave no longer uses. Settings on a draft stay, including whether to stamp custom properties and the default visibility. A draft that copies from the destination's own Azure DevOps connection cannot change connection: preparing again deletes it in that org and drafts it again from the sandbox's connection. Settings on the deleted draft do not carry over. A migration that has already started is left alone, and keeps copying from the connection it started on. If it still holds a repository the plan now sends somewhere else, move that repository back in the plan before preparing again.

You cannot remove the wave, or a destination org, while one of these migrations still holds repositories.

Git copy has to be available in every destination org this wave moves into. Preparing is refused otherwise, and names every such org at once. Contact that org's CodeCargo administrator. Start the move and Retry check again, because Git copy can stop being available after you prepare. Stop the move does not.

Under How the move is going, a migration that copies with Git copy reads Git copy or Git copy, Actions kept off beside its number. Starting one draft from Migration Assistant → Repositories → Migrations opens on the GitHub importer or Git copy that draft was saved with. You can choose the other there. Choosing Git copy is refused when that organization does not have it. Start the move on this page uses what was saved on each draft.

While the wave uses Git copy, the estimate includes Creating repositories. See How Long a Move Takes.

Start, Retry, or Stop the Move

From the wave, start, retry, or stop the move in every destination org at once. Open Migration Assistant → Repositories → Migrations in that org for a repository's detail, or to start or retry that one draft on its own, with the same permission as preparing.

Start the move starts every draft still waiting. Its dialog asks for a GitHub token for each destination org that has a draft to start, and one source token: an Azure DevOps token, or a GitLab access token. With more than one destination org, Use the same token for every org is on, so one GitHub token covers them all. Turn it off to paste one under each org. One GitHub token covers every part of that org. The tokens need what starting a migration needs: see Stage 3 and What Differs by Source. A destination that has already started is left alone. A draft whose repositories were all left out or skipped is left alone, and no token is asked for it.

After the checks pass, each destination starts on its own. One that is refused stays as it was and says why. The others still start.

Start the move is refused when the move is not prepared, the plan changed since you prepared it (prepare it again), a destination is not ready, the move was abandoned, or nothing is left to start.

Stop the move stops every running destination. Repositories not yet handed to GitHub are not started, and copies already in progress finish. Copy stopped repositories again with Retry N failed.

Retry N failed copies again repositories that failed, were refused before they could copy, or were stopped, in each destination whose migration has started. Each one reuses the tokens it started with. If one no longer holds them, the others still retry, and the Retry dialog asks for new tokens for that org. A destination still stopping waits until copies in progress finish.

If a start is not confirmed in time, that destination may have started. Open it in its org to see where it stands. Start or retry again to hand off a destination still Validating.

Copying from GitLab

A wave can move GitLab projects into its destination orgs. Prepare the Move works the same way for GitLab, from the sandbox's GitLab connection and inventory. Preparing is refused until the group is connected and inventoried there.

Start the move asks for a GitLab access token and one GitHub token per destination org. One GitLab token covers every destination and every part. Requirements match Copying GitLab Projects to GitHub. If the GitLab token or a destination's GitHub token is refused, nothing starts. Retry reuses the tokens the move started with.

When a Repository Is Disabled

A repository disabled in Azure DevOps can still be copied. Opening it also needs an Azure DevOps administrator token, held by a project administrator. The Start and Retry dialogs ask for one token per Azure DevOps organization that has a disabled repository in the migrations you are starting or retrying. The description says how many need one. Start the move or Retry stays unavailable until every organization has a token.

Each organization is listed with those repositories, such as acmebank · 3 disabled repositories: payments, billing, and 1 more. A tip names the rest. With more than one organization, Use the same token for every organization is on; turn it off to paste one under each line. Use the Azure DevOps token above for this too uses the source token you already pasted, for every organization. Leave it off unless that token also meets the administrator token's requirements; the usual source token is read-only, so the start is refused. Create one and Requirements sit on the section when every organization's requirements match, and on each line when they do not.

If a repository is disabled after you loaded the wave, the start or retry is refused and that organization joins the dialog, with the reason under its field. Paste the token and try again. The organization leaves the dialog once those destinations have started or retried.

When that org's migrations archive disabled repositories' copies and the GitHub token is not an organization owner's, a warning under it says archiving a copy may be refused. The copy is then left unarchived, with a note. The warning does not block the start.

When Repositories Changed Since You Prepared

A repository can leave the wave, join it, or change destination after you prepare, even when you did not save a change to the plan. A fact change still waiting as a pending change does not count.

Start the move is refused until you prepare again. It says the wave's repositories changed since its move was prepared, and names what changed: repositories left the wave, a repository's destination changed, or a repository isn't in a migration yet. Prepare the wave again, then start. Preparing writes the repositories the wave has now into the drafts.

Retry is refused the same way when it would hand off a destination still Validating. A move that has gone further keeps the repositories it holds, and Retry does not refuse it for this.

A repository the prepare left out on purpose, one the destination had already migrated, and one an abandoned migration held are not treated as a change. A draft beside an abandoned migration still starts. A part whose prepare left every repository out reads No migration, not a refusal.

When Pending Changes Affect This Wave

On Move repositories, a note says how many pending changes affect this wave when any are waiting. The count includes a repository that would join this wave and one that would leave it.

Review the pending changes opens the pending changes card on Schedule Waves, on Assign, listing only those changes. The note's count and that list are the same.

The note asks you to review them before the wave starts. It does not hold up the move. You can leave a change waiting, and the repositories stay where they are until someone answers it.

How the Move Is Going

After you prepare a wave's move, the plan shows how it stands in the destination orgs. For the wave, and for each destination org's migration, you see that migration's number and status, and how many repositories have not started, are moving, have moved, failed, or were skipped. A destination split into more than one migration, such as (2 of 3), lists each one. Failures are grouped by why they failed. A paused migration is marked Paused.

The counts cover repositories that have a destination, and they add up.

• Not started - still waiting: in a draft, not yet taken by its migration, or with no migration saved (not prepared, deleted in that org, or abandoned).
• Moving - queued, preparing, or copying. A repository GitHub has finished copying still counts here until the migration finishes with it.
• Moved - copied into the destination, including one that destination has already migrated. That covers one this migration failed or skipped, and one another migration there copied.
• Skipped - left out of its migration, and not already in the destination.
• Failed - failed, aborted, or refused before it could copy. If the destination has already migrated it, it counts as moved instead.

The plan shows counts only. For a repository's detail, switch to the destination org and open Migration Assistant → Repositories → Migrations. That org's permissions apply there. See The Migration Run.

On the journey, the wave's step stays Upcoming, with Ready to move when, until the move is under way: a migration has started, or the move was prepared and no repository is still waiting to start. The list is then Done when. See Ready to Move When.

• In progress while a migration is copying
• Needs you when a repository has failed, or when nothing is copying and some repositories are still unmoved (skipped, not started, or held in a paused migration)
• Done when every repository with a destination has moved

A wave that also converts pipelines in the same window stays In progress after the repositories have moved, until those pipelines convert. Resume a paused migration from its page in the destination org.

What's Left on GitLab

On Move repositories, below the repository table, What's left on GitLab shows what this wave's repositories still point at on GitLab. It is there when the plan includes a GitLab group, once those repositories have copies in the sandbox, when some are left out of the count, or when some moved without a sandbox copy. Those were not read, and the panel says how many. Otherwise it is hidden.

It counts the references and the repositories they are in, such as 24 references in 5 repositories still point at GitLab. Counts by kind are listed under that line. CI includes, triggers, and needs counts what GitLab CI files include, trigger, or need from other projects. A count that finds nothing covers only copies the scan has read. Copies that were not scanned are named apart, because they may hold more. If none have been scanned yet, the panel says so.

It reads the sandbox's copy of each repository, which matches what moved unless someone edited it. With one GitLab group, See the full report opens that group's report. With more than one, the counts are added together, and each link is named for its group, such as See gitlab.com/acmebank's report. That report lists the group's migrated repositories, not only this wave. See Ready to Turn Off GitLab.

If the report could not be read, the panel says so and asks you to reload the page. It does not show an empty count in place of a report it could not read.