Prepare Rewire

What is Prepare Rewire?

After running gh ado2gh to migrate repositories from Azure DevOps to GitHub, pipeline files and other repository content may still contain references pointing at Azure DevOps — hardcoded clone URLs, pipeline resource declarations, and .gitmodules entries. The Prepare Rewire flow finds those lingering references, proposes fixes, and delivers them as pull requests you merge before running gh ado2gh rewire-pipeline.

The flow runs in four stages:

1. Review Mapping - Confirm the map of Azure DevOps source locations to their new GitHub homes
2. Open Update PRs - Scan repositories and open fix pull requests
3. Merge - Review and merge the PRs
4. Run Rewire - Run the gh ado2gh rewire-pipeline command

Access the flow from the Migration Assistant dashboard by clicking Prepare Rewire on an Azure DevOps instance. You'll need the GitHub CLI with the ado2gh extension installed to run the final rewire command.

The References Filter

The page header includes a References filter that scopes every stage of the flow — rows, counts, panel summaries, and the contents of the update PRs you open. References are grouped into:

• Pipelines - References found in files the import registered as pipeline definitions for their repository
• Submodules - References found in a repository's .gitmodules file
• Other - Everything else, such as hardcoded clone URLs and scripts

Select any combination of these groups using the checkbox segments in the header, or click Show all to clear the filter. Your selection is carried in the URL as repeated refs parameters (for example, ?refs=pipelines&refs=submodules), so it deep-links, survives switching stages, and restores from a pasted link.

Opening update PRs while filtered doesn't disable the action. References outside your current selection are left out of the PR and marked as excluded, so a PR's contents always match what CodeCargo has on record. The confirmation dialog tells you how many references will be left behind before the PR opens, and those references stay visible afterward as excluded.

Stage 1 — Review Mapping

Migration Assistant traces each migrated repository's GitHub Enterprise Importer "Migration Log" issue to build an authoritative map of Azure DevOps source locations to their new GitHub homes. The mapping table shows:

• ADO project/repo - The source identifier (e.g. my-project/api-service)
• GitHub repository - The confirmed target
• Confidence - Authoritative when the target was read directly from the Migration Log; Manual when you entered or overrode it
• Origin - Why the mapping exists at all — for example, whether it was traced from the Migration Log or seeded by an earlier URL scan
• In use - Which imported pipelines reference this repository, so you can see why the entry is in the queue

Confidence and Origin answer different questions: Confidence describes how the target was determined and updates when you edit the mapping, while Origin records where the entry originally came from and never changes. Both columns are sortable.

For any entry that couldn't be resolved automatically, Migration Assistant suggests a target based on naming conventions. Only confirmed mappings are used when generating fix PRs.

Working the Review Queue

The Stage 1 table is a review queue. Filter pills above the table narrow it to a particular state — unconfirmed entries, for example — and each pill has a popover explaining what it covers.

Click any row to open a details panel with GitHub deep links to the source and target repositories, a target picker for correcting a suggested mapping, and an inline Unconfirm action. Unconfirming leaves the target as the current guess but returns the entry to the review queue until you confirm it again.

To confirm mappings, either check the specific rows you want and click Save, or click Save with nothing checked to confirm every confirmable mapping currently visible. The button label reflects which you'll get: it reads Save & confirm all (N) when there are confirmable mappings in view, or plain Save when there's nothing left to confirm.

Stage 2 — Open Update PRs

Once mappings are confirmed, select the repositories you want to fix and click Open Update PRs. Migration Assistant scans each repository for:

• Pipeline YAML - Both structural resource declarations and free-text ADO URL references
• .gitmodules - Submodule URLs pointing at Azure Repos
• Hardcoded clone URLs - Any remaining dev.azure.com references

Fix PRs are opened one per repository through a background queue, so large batches complete reliably even if you close the page. Rows in the table flip to show a PR link as each one lands — you don't need to refresh.

Skipping a Repository

Click Skip on a repository row to exclude it from bulk PR opening and from the Stage 4 readiness gate. Skipping is a durable, per-repository decision — a skipped repository shows a Skipped status and can be brought back at any time by unskipping it.

Excluding Individual References

Within a repository's reference list, untick individual references to leave them out of that repository's update PR. Excluded references are removed from both the PR diff and its description. If every reference in a repository is excluded, the repository behaves the same as a fully skipped one.

Exclusions persist across re-scans. If a re-scan changes the surrounding text, CodeCargo re-matches your exclusion automatically; any that no longer match are flagged as stale rather than silently dropped.

Stage 3 — Merge

With PRs open, review them in GitHub as you would any other change, then return to the Prepare Rewire page and click Bulk Merge to merge all ready PRs at once. The table tracks merge status per repository. Repositories where the PR cannot be merged (for example, due to branch protection or a merge conflict) are flagged for manual follow-up.

Stage 4 — Run Rewire

Once all fix PRs are merged, the Run Rewire command unlocks. Copy the displayed gh ado2gh rewire-pipeline command and run it in your terminal to complete the pipeline rewiring. The page shows the timestamp of the last reference scan so you can confirm the fixes are current before cutting over.

Skipped repositories don't count against the readiness gate — once every non-skipped repository's PRs are merged, Run Rewire unlocks even if some repositories remain skipped.

The gate itself always counts every reference, regardless of the References filter. If a filtered view looks clean but work remains outside your current selection, an advisory names the out-of-scope references instead of unlocking the command.

Exporting Rewire Data

Click Export in the page header at any point during the Prepare Rewire flow to download the current findings for sharing with teams outside CodeCargo. Two formats are available:

• Excel workbook - A single .xlsx file containing a read-me/legend sheet, a flat reference list, a repository summary, and the full ADO-to-GitHub mapping, with plain-English labels and styled, frozen, filterable headers so it's readable even by teams unfamiliar with CodeCargo.
• Stage CSVs - Separate downloads for the Stage 1 mapping table and the Stage 2 reference list, formatted as UTF-8 CSV so they open cleanly in Excel or any spreadsheet tool.

Both the mapping sheet and the reference list include pipeline provenance columns showing which imported pipeline — and its source path — referenced each entry, matching the pipeline tags shown in the on-screen tables. This lets you trace any mapping or reference back to the pipeline that surfaced it.