Code hosting migration

Azure DevOps → GitHub

Move Azure Repos and supported pull-request metadata into GitHub while separately planning Boards, Pipelines, Artifacts, permissions, identities, policies, service connections, and changes made after the final snapshot.

Typical timeline18–35 business days80–145 hours active work

Statusneeds review

Source testedAzure DevOps documentation reviewed 2026-07-19

Destination testedGitHub documentation reviewed 2026-07-19

Last reviewed2026-07-19

Sources3

Before you migrate

Should you make this move?

Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.

Current platform

Azure DevOps

Reasons to stay

Repos, boards, pipelines, artifacts, and enterprise controls are tightly integrated
Repository-centered workflows keep code, review, and automation close together

Reasons to leave

The interface and administration model can feel heavy outside Microsoft-centric organizations
Advanced governance and automation can become configuration-heavy

New platform

GitHub

What gets better

The largest developer ecosystem combines collaboration, automation, and public discovery
Repository-centered workflows keep code, review, and automation close together

What gets worse

Enterprise planning and governance can require several overlapping GitHub products
Advanced governance and automation can become configuration-heavy

Best of the move

GitHub: The largest developer ecosystem combines collaboration, automation, and public discovery. This removes a major source-side concern: The interface and administration model can feel heavy outside Microsoft-centric organizations.

Worst of the move

What you lose: Repos, boards, pipelines, artifacts, and enterprise controls are tightly integrated. What you inherit: Enterprise planning and governance can require several overlapping GitHub products.

01At a glance

Know the shape of the move.

Transfer outcome12 features audited

Clean1

Partial7

Manual2

Lost2

Mapping route9 of 9 fields have a destination path

SourceAzure DevOps9 mapped fields

Automatic2

Transform4

Manual3

Unsupported0

DestinationGitHub9 supported paths

This timeline assumes

Up to 100 repositories, 500 GB of Git data, and 250 users
Administrators control both platforms, identity mapping, DNS, registries, and every repository integration.
A representative repository set is migrated into an isolated destination organization first.
The source remains read-only until developers and automation pass one complete release cycle.
The migration team records evidence for every blocking verification check.

02Loss matrix

What survives the move.

“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.

Item	Outcome	Impact	What happens	Mitigation
Azure Repos and supported pull-request metadata	partial	critical	GitHub Enterprise Importer supports Azure DevOps Cloud repository data, but not Azure DevOps Server directly.	Inventory the source version and pilot repositories with large or unusual pull-request histories.
Repository permissions	lost	critical	GitHub explicitly does not migrate Azure DevOps repository permissions.	Create organizations, teams, IdP groups, and rulesets before production access.
Azure Boards, Pipelines, Artifacts, and service connections	manual	critical	These services are separate from the repository migration and may be retained, integrated, or migrated independently.	Give each service an approved keep, integrate, rebuild, archive, or retire decision.
Post-snapshot changes	lost	critical	GitHub’s Azure DevOps importer does not support delta migrations.	Halt writes during production migration or record and replay every approved delta manually.
Git repositories and commit history	clean	critical	Git source, branches, tags, and commits can move through supported importers or mirror pushes.	Compare refs, commit graphs, default branches, submodules, signatures, and shallow state.
Pull or merge requests	partial	critical	Metadata migration depends on the selected importer and supported source version.	Pilot open, closed, merged, draft, forked, and large requests.
Issues, comments, and discussions	partial	high	Coverage, formatting, attribution, timestamps, and cross-links vary by migration path.	Preserve source IDs and URLs and reconcile representative conversations.
Users and contribution attribution	partial	critical	Email and username differences can create placeholders or migration identities.	Freeze an identity map and reclaim or annotate unmapped activity.
Git LFS and large binaries	partial	critical	Git history can move while LFS objects, package blobs, and releases require separate transfer.	Inventory object counts and compare hashes after migration.
Branches, tags, and protections	partial	critical	Refs move more easily than approval, push, merge, and signing policies.	Recreate rules before developers receive write access.
CI/CD pipelines and secrets	manual	critical	Pipeline syntax, runners, caches, artifacts, environments, and secret stores differ.	Translate and rehearse every active build and release workflow.
Packages, containers, and releases	partial	high	Registries and release assets do not necessarily follow repository data.	Copy immutable artifacts and update package coordinates and credentials.

03Field and feature mapping

Where each thing goes.

Source	Destination	Method	Notes
Azure DevOps repository	GitHub repository	automatic	Preserve stable source URL and default branch.
Git branch and tag	Git branch and tag	automatic	Compare all refs after import.
Pull or merge request	Destination pull or merge request	transform	Depends on selected metadata importer.
Issue and comment	Destination issue and comment	transform	Preserve author, timestamp, ID, and URL.
Source user	Destination identity	manual	Freeze an identity map before migration.
Branch protection	Destination ruleset or branch restriction	manual	Rebuild before write access.
CI pipeline	Destination workflow	transform	Review every generated or translated step.
Package, release, or LFS object	Destination registry, release, or LFS object	transform	Copy binaries and compare hashes.
Group, team, or permission	Destination organization, team, and role	manual	Apply least privilege.

04Before you begin

Make the move recoverable.

Backup procedure

Create the source-of-truth backup

Preserve Azure DevOps data, configuration, and operating evidence before any destination write.

Inventory and export Azure DevOps repositories, metadata, users, permissions, pipelines, packages, releases, webhooks, and settings.
Mirror every Git repository and fetch Git LFS objects.
Record counts by repository, ref, pull request, issue, user, package, and integration.
Hash archives and migration manifests.

Proof to capture: A signed manifest reconciles every scoped record class, runtime dependency, export file, count, and hash.

Transformation · Platform inventory tools and migration workbook

Repository and identity manifest

Preserve repository scope, Git refs, users, and metadata ownership.

Inventory source values and exceptions.
Define explicit destination mappings.
Reject unmapped critical records.

Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.

Transformation · Official importer, CI converter, and verification scripts

Workflow and integration conversion

Rebuild delivery and connected services safely.

Normalize encoding, dates, identifiers, and blanks.
Run a representative pilot.
Reconcile accepted, rejected, and transformed rows.

Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.

05Handle with care

The things most likely to hurt.

These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.

Migration

A code-only move is mistaken for a metadata migration

criticalpossible likelihood

Git refs exist while pull requests, issues, users, or settings are missing.

Consequence: Collaboration and control history disappears.
Mitigation: Choose and verify the required migration fidelity explicitly.

Stop if: Any required metadata class lacks a supported path.

Cutover

Both platforms accept writes

criticalpossible likelihood

Developers or bots push and update work in both systems.

Consequence: Repositories and release state diverge.
Mitigation: Freeze source writes and change remotes in one controlled window.

Stop if: Any unapproved source writer remains active.

Access

Permissions or secrets are over-broad

criticalpossible likelihood

Migrated users or automation receive more authority than intended.

Consequence: Code, packages, or production systems are exposed.
Mitigation: Apply least privilege before opening repositories.

Stop if: An unauthorized test identity can perform a protected action.

06Precise timeline

Do the work in this order.

Estimate forUp to 100 repositories, 500 GB of Git data, and 250 users

Total elapsed18–35 business days

Active work80–145 hours

BufferAdd time for Azure DevOps Server, many pull requests, TFVC, large packages, Pipelines conversion, or Enterprise Managed Users.

Days 1–3Inventory and decisions2–3 days

Days 3–5Backup and reconcile1–3 days

Days 5–12Map and pilot3–8 days

Days 10–20Final delta and switch1–5 days

Days 12–40Observe and close3–10 days

1
Days 1–3 · inventory
Inventory and decisions
6–12 hours active2–3 days elapsedOwner review waiting
- Inventory Azure DevOps data, features, users, domains, and integrations.
- Approve scope, owners, mappings, and exclusions.
Depends on: Azure DevOps and GitHub administrator access
Stop / go checkpoint
Export?
Go when: Every critical item has an owner and disposition.
Stop when: Consent, billing, access, or system ownership is unclear.
2
Days 3–5 · backup
Backup and reconcile
5–10 hours active1–3 days elapsedExport processing waiting
- Create immutable exports and configuration evidence.
- Reconcile counts, totals, and hashes.
Depends on: Approved inventory
Stop / go checkpoint
Transform?
Go when: Source totals and export manifests agree.
Stop when: Any critical dataset or configuration is absent.
3
Days 5–12 · pilot
Map and pilot
10–35 hours active3–8 days elapsedDestination processing and review waiting
- Configure GitHub and transform representative data.
- Run a pilot containing normal records and every critical edge case.
Depends on: Verified backup
Stop / go checkpoint
Scale?
Go when: Pilot mappings, behavior, access, and evidence pass.
Stop when: Any critical check fails or produces unexplained variance.
4
Days 10–20 · cutover
Final delta and switch
5–25 hours active1–5 days elapsedDNS, import, or sync propagation waiting
- Freeze production writes in Azure DevOps.
- Apply the final delta, switch ownership, and run blocking checks.
Depends on: Passed pilot and approved rollback
Stop / go checkpoint
Open production?
Go when: Counts reconcile and one destination system owns production.
Stop when: A source writer remains active or a blocking check fails.
5
Days 12–40 · observe
Observe and close
3–18 hours active3–10 days elapsedOperating-cycle evidence waiting
- Monitor one complete operating cycle.
- Sign the verification report and close rollback only after stability.
Depends on: Verified cutover
Stop / go checkpoint
Close rollback?
Go when: No trigger occurs during the agreed observation period.
Stop when: Data, access, delivery, routing, or business results regress.

07The point of change

Cut over with a way back.

Go live

Cutover

Make GitHub the only production system without losing the final Azure DevOps delta.

Recommended window: A low-volume weekday morning with platform, data, DNS, and business owners available.

Freeze production writes and scheduled actions in Azure DevOps.
Export, transform, and reconcile the final delta.
Apply the approved delta to GitHub.
Switch domains, forms, integrations, sending, or sync ownership as applicable.
Run every blocking verification check and keep the source intact.

Proof to capture: GitHub owns production, totals reconcile, and every blocking check has durable evidence.

Return to safety

Rollback

Return production ownership to Azure DevOps without losing destination-era changes.

Deadline: Within seven days and before source data, plans, credentials, domains, or billing are changed.

Stop new writes and scheduled actions in GitHub.
Restore the prior Azure DevOps routing, forms, integrations, sending, or sync ownership.
Export the GitHub post-cutover delta.
Review and apply safe destination-era changes to Azure DevOps.
Run the same blocking checks against the restored source.

Proof to capture: Azure DevOps again owns production with current data and no duplicate destination action.

Rollback immediately when

Unexplained critical count or value variance
Missing or exposed critical data
Duplicate production action
Failed access, routing, delivery, or integration check
A critical feature has no safe destination replacement

08Verification report

Prove the migration worked.

Every blocking check must pass. Capture the evidence before cleanup begins.

ID	Check	Method	Expected result	Evidence
`V-01`Blocking	Repository and ref parity	Compare repositories, commits, branches, tags, default branches, submodules, and LFS.	Every scoped Git object is accounted for.	Git manifest.
`V-02`Blocking	Collaboration coverage	Compare pull requests, issues, comments, releases, wikis, and projects by source class.	Every required item is migrated or explicitly archived.	Metadata ledger.
`V-03`Blocking	Attribution mapping	Inspect active, inactive, bot, and external contributors.	Every required author has a destination or annotation.	Identity map.
`V-04`Blocking	Teams and repository rules	Test representative users and protected actions.	Least privilege and branch controls match policy.	Access report.
`V-05`Blocking	Build and release parity	Run representative workflows from identical commits.	Tests, artifacts, approvals, and deployments match.	Workflow evidence.
`V-06`Blocking	Packages, releases, and LFS	Compare counts, coordinates, sizes, and hashes.	Every required binary is present and retrievable.	Artifact manifest.
`V-07`Blocking	Connected services	Exercise each webhook, app, key, and notification.	One correct destination callback per event.	Integration log.
`V-08`Blocking	Single repository authority	Inspect developer remotes, bots, and source protections.	GitHub alone accepts approved writes.	Cutover checklist.

09Post-migration cleanup

Remove the scaffolding safely.

Safe after: One complete operating cycle, at least seven stable days, and owner sign-off on every blocking check.

Create final Azure DevOps exports and archive verification evidence.
Revoke temporary credentials, API keys, webhooks, and elevated roles.
Remove obsolete embeds, forms, jobs, integrations, and DNS records.
Keep the source intact through the approved retention window.
Cancel paid plans only after billing, legal, and recovery review.
Schedule the next GitHub backup, access, and migration-playbook review.

Sources and maintenance

Built to be reviewed.

Tested 2026-07-19. Next scheduled review: 2026-10-19.

GitHub: understand Azure DevOps migrationsAccessed 2026-07-19
GitHub: prepare an Azure DevOps migrationAccessed 2026-07-19
GitHub: migrate Azure DevOps repositoriesAccessed 2026-07-19

Know the shape of the move.

This timeline assumes

What survives the move.

Where each thing goes.

Make the move recoverable.

Create the source-of-truth backup

Repository and identity manifest

Workflow and integration conversion

The things most likely to hurt.

A code-only move is mistaken for a metadata migration

Both platforms accept writes

Permissions or secrets are over-broad

Do the work in this order.

Inventory and decisions

Export?

Backup and reconcile

Transform?

Map and pilot

Scale?

Final delta and switch

Open production?

Observe and close

Close rollback?

Cut over with a way back.

Cutover

Rollback

Prove the migration worked.

Remove the scaffolding safely.

Built to be reviewed.