Software companies
How to export Azure DevOps work items, repos and pull requests
By SourceX Editorial · Updated
Short answer
To export Azure DevOps work items, repos and pull requests completely, pull three things separately: work items with their full revision history, a mirror of each Git repository, and pull request threads through the API. The rule that protects their value: keep every original ID, because IDs link each work item to the commits and reviews that resolved it.
Key takeaways
- A query exported to CSV or Excel captures current field values, not the revision history behind them.
- A repository clone keeps commits, branches and tags, but pull request discussions live outside Git.
- Original work item, commit and pull request IDs are the links; never renumber them in an export.
- Scan exported repositories, logs and review threads for secrets and personal details before they leave your control.
- Export and verify counts before decommissioning an Azure DevOps Server or ending a subscription.
What does a complete Azure DevOps export include?#
A complete Azure DevOps export includes work items with history, Git repositories, pull request threads, the project wiki and, where they matter, pipeline run records, each pulled by a different route. No single button produces all of them with their links intact, so plan the export as several jobs that share one ID scheme.
Treat the table as a starting plan and confirm each route against the current documentation for your version before the export window opens.
| Component | Typical export route | What it misses on its own | How to keep links |
|---|---|---|---|
| Work items, current fields | Query results to CSV or Excel | Revision history, comments and attachments | Keep the work item ID column |
| Work item history | REST API revisions or updates for each item | Nothing, if every item is pulled | Store raw JSON keyed by item ID |
| Work item relations | Relations returned with each item | Commit, pull request and build links if skipped | Keep artifact links exactly as recorded |
| Git repositories | Mirror clone of each repository | Review discussion and linked work items | Keep commit hashes unchanged |
| Pull requests | REST API for pull requests and threads | Code, if repositories are not cloned | Keep pull request IDs and iteration numbers |
| Project wiki | Clone the Git repository behind the wiki | Links to work items if pages are rewritten | Keep page paths unchanged |
| Pipeline runs | REST API for runs and logs | Source commit, if only logs are saved | Keep run IDs with source commits |
Why a CSV of work items is not enough#
A CSV of work items is not enough because it records where each item ended up, not how it got there. State changes, reassignments, priority edits and the discussion that show how a bug was triaged and fixed live in the item's revision history.
That history is the part with lasting value. For an internal retrospective, it shows how long items waited in each state. For an AI developer studying issue resolution, it shows the sequence of decisions between a report and a fix. A flat export of final values erases both.
Area paths and iteration paths deserve attention too. Teams rename and reorganize them over the years, and each revision records the path at that moment, so a current-value export can place an old bug in a team that did not exist when it was fixed. Check the current Azure DevOps documentation for your version, since Azure DevOps Services and older on-premises Azure DevOps Server releases differ in API versions and export options.
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
How to export work items with full history#
Exporting work items with full history means listing every item ID, including closed and removed items, then pulling each item's revisions, comments, relations and attachments into storage keyed by that ID. Work through it project by project so a failure in one does not stall the rest.
- List every project in the organization or collection, including inactive ones.
- Run a query that returns all work item IDs across types and states, including closed items.
- Check the recycle bin for deleted items that should be restored or recorded first.
- For each ID, pull the full revision list, the comment thread and the relations.
- Download attachments and record which revision or comment each belongs to.
- Save raw responses unmodified, then build any flattened tables from them.
- Compare item counts per project and type against the source before sign-off.
How to export repositories and pull requests together#
Repositories and pull requests have to be exported together because Git holds the code and commits while Azure DevOps holds the review conversation around them. A mirror clone captures every branch, tag and commit reachable from your refs; it does not capture reviewer comments, votes or the work items linked to a pull request.
Pull the record for every completed, abandoned and active pull request: title, description, author, reviewers and their votes, status, merge strategy, linked work items and each comment thread with its file path, line position and iteration. The iteration number places a comment against the version of the code it was written about.
Teams that squash-merge and delete source branches should take extra care. After a squash merge, the step-by-step commits of a review may survive only in the pull request's iteration record, so a repository mirror alone can show one combined commit where the reviewers saw several. Large organizations will also hit API throttling, so build retries and checkpoints into the export script.
Keeping links between work items, commits and reviews#
Links between work items, commits and reviews survive an export only if the original identifiers are kept and stored on both sides of each link. A work item records artifact links to commits, pull requests and builds; a pull request lists the work items linked to it; and commit messages often mention work item IDs in plain text.
| Link | Where it is stored | How to preserve it |
|---|---|---|
| Work item to commit | Artifact link on the work item; ID mention in the commit message | Keep commit hashes and the raw link values |
| Work item to pull request | Artifact link on the work item and the pull request's linked items | Export both sides and reconcile them |
| Parent and child items | Hierarchy relations on each work item | Keep the relation type and both IDs |
| Pull request to build | Status and policy records on the pull request | Keep pipeline run IDs with source commits |
| Mentions in discussion | User and item references inside comment text | Map user IDs to role labels and keep item IDs |
What to check before the export leaves your control#
Before an Azure DevOps export leaves your control, scan it for secrets and personal details, because repositories, pipeline logs and review threads all collect credentials and names over time. A connection string pasted into a pull request comment is as exposed as one committed to code.
Open-source secret scanners help. Gitleaks detects passwords, API keys and tokens in Git repositories and files, though its README now describes it as feature complete, with future releases limited to security patches. TruffleHog scans Git and other sources, including chats, wikis and logs, and can check whether a credential it finds is still live. Rotate anything a scan confirms, then redact it in the archive.
Personal details need their own pass: identity records with names and email addresses, customer names in work item titles, and screenshots attached to bug reports. If you migrate to another tracker at the same time, also build a crosswalk file mapping every old ID to its new one, so the archive and the new system can still be joined.
Illustrative: retiring an on-premises Azure DevOps Server#
Illustrative: a fictional construction estimating software company has run an on-premises Azure DevOps Server since its first release and is moving engineering to a cloud Git platform. The migration plan moves active repositories and open work items only.
Before the server is shut down, the CTO has the team export every project: work items with revisions and comments, mirror clones of all repositories including retired products, pull request threads with iterations, the wiki and pipeline runs for the main branches. Original IDs are kept, and a crosswalk links migrated items to their old numbers.
A secrets scan finds old credentials in pipeline logs, which are rotated and redacted. The company keeps the server's database backup too, but the readable export is what the team actually uses later, when an old customer escalation resurfaces and again when leadership asks which engineering history might be worth licensing.
How SourceX uses an engineering export#
SourceX starts with metadata, not files: the fit check asks which systems hold your engineering history, how many years remain accessible and how work items, commits and reviews connect. Nothing from Azure DevOps is shared during that assessment.
If you proceed, the SourceX five-step transaction moves through Supply, Rights, Preparation, Approval and Delivery. Large repository archives stay in your own storage or ship on encrypted drives, and the SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization for what is delivered.
Frequently asked questions
Does migrating from Azure DevOps to GitHub keep pull request history?
Not always in full. Migration tools usually move repositories reliably, but pull request discussions, work item links and history may move partly, arrive as plain text or stay behind, depending on the tool and options chosen. Export the full record from Azure DevOps first and keep it alongside whatever the migration produces.
Is a database backup of Azure DevOps Server enough as an archive?
A database backup preserves everything, but it can only be read by restoring it onto a compatible server version, which gets harder as versions age. Keep the backup, and also keep a readable export of work items, repositories and pull requests that does not depend on running the server.
What about projects that still use TFVC?
Team Foundation Version Control history is structured differently from Git, with changesets rather than commits. Projects on TFVC need either a conversion to Git that preserves history or a separate export of changesets and their linked work items. Decide before the server is retired, since both routes need it running.
Should test plans and pipeline runs be exported too?
Export pipeline runs where they connect to commits and incidents, because a failed build linked to a fix is useful history. Test plans matter less for most purposes, but keep them if your team used them to track regressions. Review logs for secrets before they leave your control.
Who should own the export?
An engineering manager or platform engineer who knows the organization's structure should run the export, with the CTO signing off on scope. Someone outside the team will not know which inactive projects, renamed areas or retired repositories hold the history worth keeping.
Sources
- Gitleaks is an MIT-licensed tool for detecting secrets such as passwords, API keys and tokens in git repositories, files and stdin; its README states it is feature complete and future releases will be security patches only. Source
- TruffleHog scans sources including Git, chats, wikis, logs, object stores and filesystems, and for secrets it can classify it can log in to confirm whether the secret is live. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.