Prepare Rewire

What is Prepare Rewire?

After migrating repositories from Azure DevOps to GitHub, whether through Migrating Repositories or with gh ado2gh, 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 five stages:

1. Review repository mapping - Confirm the map of Azure DevOps source locations to their new GitHub homes
2. Open PRs to update references - Scan repositories and open fix pull requests
3. Merge PRs - Review and merge the PRs
4. Run rewire - Rebind imported pipeline definitions onto their GitHub repositories in waves
5. Verify pipeline triggers - Check each rebind, restore pull request triggers, and preview-compile each definition

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

After those PRs merge, you rebind pipeline definitions in waves (Stage 4) and run a check-and-repair pass (Stage 5) that restores pull request triggers and preview-compiles each definition.

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 Repository Mapping

Migration Assistant builds an authoritative map of Azure DevOps source locations to their new GitHub homes. Repositories migrated from inside CodeCargo write their mapping the moment the copy succeeds; for repositories migrated with gh ado2gh, Migration Assistant traces each one's GitHub Enterprise Importer "Migration Log" issue. 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 recorded by an in-app migration or 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 recorded by an in-app migration, 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.

Each mapping includes a GitHub service connection for that Azure DevOps project. Connections are project-scoped — pick one that exists in the same project, and prefer the Azure Pipelines GitHub App connection over a PAT-based one when both are available.

If the GitHub copy of a repository will serve migrated pipelines but the Azure DevOps original must keep serving pipelines you haven't moved, mark it as a shared template so the original isn't decommissioned with the migrated consumers.

Stage 2 — Open PRs to Update References

Once mappings are confirmed, select the repositories you want to fix and click Open N PRs (the button counts the repositories you selected). 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. Each repository shows Opening PR while its pull request is created, then moves to Stage 3 with a link to the PR — 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.

Pipeline settings that aren't text in a file — service connections, variables, triggers, composed URLs, and template dependencies — are not included in update PRs. Dismiss a pipeline-setting item when you've handled it outside the PR or chosen not to; dismissing is the resolution, and a repository whose only remaining items are dismissed counts as done.

Stage 3 — Merge PRs

With PRs open, review them in GitHub as you would any other change, then return to the Prepare Rewire page and click Merge all 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 the update PRs are merged, Stage 4 lists imported YAML pipeline definitions that are ready to rebind onto their GitHub repositories. Classic pipelines and definitions on unmapped repos are omitted. Select any subset — or every ready definition — and generate a rebind script for that wave.

The script uses official gh ado2gh commands, prefills the GitHub service connection ID, and includes per-definition snapshots and rollback instructions. Already-rebound definitions are skipped, so you can re-run the script or generate another wave later without undoing work.

Skipped repositories don't count against readiness. The gate 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 those references instead of treating the wave as ready.

Stage 5 — Verify Pipeline Triggers

Rewiring a definition leaves its pull request trigger switched off, so the YAML pr: block is inert and PR builds will not fire. Stage 5 runs a check-and-repair pass that verifies each binding, restores those triggers, and preview-compiles the rebound YAML. Definitions that already set pr: none don't need a trigger repair.

Click Run check and repair and use Generate credentials file to download a ready-to-use .env file — it includes a fresh 24-hour token — then run the displayed Docker command. Results report back to the page.

The table tracks status per definition. Click a row to open the detail panel. Compile failures and other problems show as Needs attention with concrete next steps. The summary separates what needs attention from what settled in this wave.

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.

After the Migration