Key takeaways
- Azure DevOps shows no total size: call GET /_apis/git/repositories with a vso.code token and add up each size in bytes, or read size-pack from git count-objects -vH on a clone.
- git clone --mirror copies every branch, tag and commit; Git LFS objects sit outside the repository and are fetched separately with git lfs fetch --all.
- Work items export from Boards > Queries with Export to CSV, which needs Project Administrators membership or View project-level information set to Allow, and the file holds only the columns you add.
- You don't need to export anything to apply: have your size in GB, your years of history and your Repos and Boards user count ready, and the data vendor anonymizes the records before any AI lab sees them.
01
What is Azure DevOps data, and why do AI labs and data vendors buy it?
The short answer
Azure DevOps data is the stored history of a company's software work in Microsoft's development service: the code in its repositories, the changes made to it, the pull requests where colleagues reviewed those changes, and the work items that asked for them. AI labs (companies that build and train AI models) and data vendors (companies that anonymize business records and package them for those labs) buy a copy because the links between a request, the code that answered it and the review around it show how a team ships software.
What an Azure DevOps organization records
Azure DevOps is Microsoft's service for building software as a team. A company's organization is its account, and it holds projects, each of which gathers the code and the planning for one product. Two parts matter most here: Azure Repos, which stores code in Git (the tool most software teams use to save versions of their code), and Azure Boards, which tracks tasks.
- Repository
- A project's folder of code together with the complete history of every change made to it.
- Pull request
- A proposal to merge one line of work into the main code, where colleagues read the change, comment on it and approve it.
- Work item
- One tracked piece of work in Azure Boards, such as a user story (a feature described from the customer's point of view), a task or a bug.
- Area path and iteration
- Two fields on a work item: the area path names the part of the product it belongs to, and the iteration names the time period (a sprint) in which the team planned to finish it.
Why linked code and work items teach an AI model something
An AI model learns by studying a very large number of examples and finding the patterns in them, and those examples are called training data. Azure DevOps lets a team attach each commit and pull request to the work item that prompted it. That joins a user story, the code written for it and the review of that code into one connected record, and fields such as state, area path and iteration show when each step was planned and finished.
AI labs now want to train AI agents, software that carries out a job step by step, and turning a written request into reviewed code is a job they care about. A data vendor can turn anonymized story-and-code pairs into worked examples that an agent studies like an answer key. The full mechanism is in AI training data: why AI companies want your company's data.
How Azure DevOps fits into a dataset
Azure DevOps is usually one app among several in a company's dataset, alongside chat, email and documents. Companies are paid $100K to $2M or more per dataset, according to micro1, the data vendor we typically refer companies to. The price covers the whole dataset, not each app on its own, and what your data is worth explains what moves it.
02
Where does Azure DevOps show how much data you have?
The short answer
Azure DevOps has no screen that shows a total size. Microsoft's way to measure a repository is to run git count-objects -vH on a clone and read the size-pack line, and Microsoft's Git Repositories REST API reports every repository's compressed size as a number of bytes. You add the repositories up and report the total in gigabytes (GB).
How to measure with the REST API
The steps below total every repository in the organization. A REST API is a web address that a script can call to read data, and a token is a password-like key that proves who is calling. The person who runs this needs permission to read code in each project.
- Create a personal access token that includes the
vso.codescope, which lets it read source code and its metadata. - For each project, call the address below with that token. It returns a list of the project's repositories.
- Add up the
sizefield of every repository. It holds the compressed size in bytes, so convert the total to GB.
GET https://dev.azure.com/ORG-NAME/PROJECT-NAME/_apis/git/repositories?api-version=7.1Microsoft documents this call in its Repositories - List reference, and it returns each repository's compressed size in bytes.
How to measure one repository with Git
To check a single repository, clone it, open a terminal in the clone and run git count-objects -vH. Its size-pack line gives the repository's size, and Microsoft's Git limits page uses that same line to define repository size.
What your permissions decide
Reading repository sizes needs permission to read code in each project, so a person who can't see a project can't count it. Counting work items needs less than exporting them: to export, you must be in the Project Administrators group or have the View project-level information permission set to Allow.
Why the total leaves out work items
Work items are a separate data set from code. The repository sizes cover Git only, so if you plan to include Azure Boards, note the number of work items from your queries beside the size in GB.
03
What should you know about your Azure DevOps data before you apply?
The short answer
Have three facts ready: the total size of your repositories in GB, how many years of history they cover and how many people in your organization work in Repos and Boards. They go into the data manifest, the written summary of which apps hold your records, how many years each covers and roughly how much. Applying shares no data, and you don't need to run an export first.
The size in GB
Report the total repository size in GB, from the REST API sizes or from the size-pack values of your clones. If you plan to include work items, mention their count too, because it is separate from the size of the code.
The years of history
The years of history come from the date of the oldest commit across your main repositories. Running git log --reverse on the default branch lists the oldest commit first.
The number of seats
Count the people in your organization who use Repos and Boards, the two parts that hold the code and the work items. People who only use other Azure DevOps features, such as pipelines, are not part of this count.
What you don't need to do first
You don't need to export anything to apply, and you don't need to clean or scrub a repository. The data vendor anonymizes the records before anyone else sees them, and nothing moves until a lawyer-reviewed license is signed. The application, the intro call and each later step are laid out in how to sell your company's data.
04
How do you export your full Azure DevOps history?
The short answer
Make a mirror clone of every repository with git clone --mirror to capture each branch, tag and commit, then export work items to CSV from a query in Boards. There is no single button that exports the whole organization, and a work item file holds only the columns you add to the query.
Step 1: copy the code and its history
- For each repository, run
git clone --mirrorwith its URL. This copies every branch, tag and commit. - A repository that keeps big files in Git LFS (Large File Storage, which stores large files outside the normal history) needs one more command,
git lfs fetch --all, run inside the mirror. - Compress the folder into a
.zipor.tar.gzfile so it is easy to move.
Step 2: export work items to CSV
Microsoft's page on CSV export and import of work items describes the steps below. Exporting is open to Project Administrators, and to anyone whose View project-level information permission is Allow.
- In the project, go to Boards, then Queries, and open or create a query that returns the work items you want.
- Add every column you want in the file, such as state, area path, iteration and assigned person. The export holds only the fields that appear as columns.
- Select the actions icon, then Export to CSV, and save the file.
- Repeat for each project.
What each method captures
The two methods cover different data, and Git LFS needs its own step. The diagram shows the same four kinds of content for each.
Size limits that shape how you export
Microsoft's Git limits page sets 250 GB as the ceiling for a repository and recommends staying under 10 GB. A single file should stay under 100 MB, and one push can carry at most 5 GB. Git LFS objects live outside the repository and are not counted against that push cap, so they have to be fetched on their own with git lfs fetch --all.
What Azure DevOps's export leaves out
A clone holds Git data only, so work items, boards and pull request discussions come from other routes. The work item CSV contains just the fields you added as columns, which means a field you forgot is missing from the file and the query has to be run again. Add every field you want before you export.
Sources: Microsoft Learn, Git limits for Azure Repos, Repositories - List and Export, update and import work items with CSV files. Steps checked against these pages in November 2026.
05
What stays private when Azure DevOps data is licensed?
The short answer
The company chooses which projects and repositories are in scope, and the data vendor replaces names and other personal details with consistent stand-ins before an AI lab sees anything. The company keeps ownership of its code and work records, and the license covers defined material for a defined use.
You choose what is in scope
A company picks the projects and repositories it wants to license, so work on infrastructure, security or experiments can stay out. A history can also hold things nobody meant to keep, so the data vendor deletes records too sensitive to clean safely instead of anonymizing them.
Names are replaced before a lab sees them
Anonymization means replacing every detail that identifies a person, such as a name or an email address, with a stand-in that is the same every time it appears. In Azure DevOps, the details are mainly commit authors and the people named in work items and review comments. The link from story to code to review still reads in order, which is what a lab learns from. The method is in how company data is anonymized for AI training.
Ownership and payment
Licensing gives the buyer limited rights to a copy, while the company keeps ownership of the originals. The terms that matter, such as exclusivity, permitted use and deletion, are covered in data licensing. micro1 pays in full within 30 days of accepting the data, usually as a single payment.
Questions
Frequently asked questions
Where do I see repository size in Azure DevOps?
Not on any screen. Microsoft's Git limits page tells you to run git count-objects -vH on a clone and read the size-pack line, and the Repositories REST API returns each repository's compressed size in bytes in its size field.
Who can export Azure DevOps work items to CSV?
Anyone in the Project Administrators group, plus anyone granted the View project-level information permission. Importing needs a higher role, but you never import anything to apply.
Does Git LFS content count toward Azure Repos limits?
It doesn't count toward the 5 GB push limit, because Git LFS objects are stored separately from the repository. Fetch them with git lfs fetch --all so they are in your total.
Are pull requests included when we clone an Azure DevOps repository?
No. A mirror clone carries branches, tags and commits, so the discussion on a pull request stays in Azure DevOps and needs another route.
How big can an Azure DevOps repository get?
Up to 250 GB, though Microsoft advises staying under 10 GB. Each file should be under 100 MB, and one push can carry at most 5 GB.
Do we need to export Azure DevOps before we apply?
No. The application takes about two minutes and shares no data. You only need your total size in GB, your years of history and your seat count for the intro call, and the export comes later, after you sign the license.
What is Azure DevOps data worth to AI labs and data vendors?
Repository and work item history is priced as part of a whole dataset rather than on its own. Companies are paid $100K to $2M or more per dataset, according to micro1, and the price depends on the years of history and how completely the records show each job. What your data is worth explains the factors.
Bottom line
Know what is in Azure DevOps, then see what it is worth
You don't need to export anything to apply. Apply in two minutes, describe your records on the intro call, and micro1, the data vendor we typically refer companies to, prices the whole dataset and sends an offer 1–2 days later.
Not legal, tax or financial advice. Figures come from micro1's published pages and public reporting as of November 2026.