Azure DevOps export of work items, repos and pipeline history: what a deep record looks like

What does Azure DevOps hold that an export needs to capture?

Azure DevOps keeps work items with their full state history, the repositories and pull requests those items link to, and the build and release pipelines that tested them. Older on-premises servers under the former TFS name often hold the longest histories, which makes them a strong sign when they are still readable.

This page is for fractional CTOs and technical advisers who meet this platform inside mid-size companies. It explains what to look for, which export questions to ask and where the exclusions sit.

Which records matter, and why

The standout item is work item history. Revision history shows an item moving from new to active to resolved, who touched it and what changed, which is the sequence of decisions an agent has to learn to imitate.

Why TFS-era servers can hold the deepest history

Companies that adopted Team Foundation Server a decade or more ago often kept the same collection running through upgrades. That produces long, continuous timelines, sometimes across several product generations.

• Ask whether the old server is still online or only a backup remains.
• A collection database backup is a different thing from an exported set of work items. Confirm that someone can restore it, and on what hardware and software.
• If the company moved to the cloud service, ask whether history moved with it or only the latest state of each item.

Use the GitLab history page to compare how a different platform stores the same chain of task, change and result.

Export routes: questions to ask, not promises

Coverage differs by route and version, so check Microsoft's current documentation for the exact environment.

A migration that maps only the latest state of each work item discards the history that makes the record useful. When a company is about to migrate, a native-format archive kept alongside is the safe move. The Pipedrive activity history guide makes the same point for a sales system.

How do you spot a company with a deep Azure DevOps record?

Look for signals visible in conversation, never in the records.

• Time: boards in daily use for several years, not recently created.
• Scale: multiple teams, release trains or products, consistent with 50+ full-time employees at peak (contractors excluded).
• Linking: work items linked to commits and builds as habit.
• Process maturity: defined states, area paths, approvals on releases.
• Owner: an engineering manager or platform lead who can describe retention and run exports.
• Rights: the company builds its own products, not primarily for named clients.

The more boxes ticked, the stronger the case for an introduction. The company fit checker offers a preliminary, non-binding screen on the whole business.

Exclusions to raise early

• Client work. Consultancies often run client engagements in their own organization. That content belongs to the clients unless they agree.
• Third-party code and packages inside repositories.
• Personal data that crept into bug descriptions and test data.
• Secrets in commits or pipeline variables.

SourceX and the company agree how these are handled before any work, and the company authorises delivery only after signing. Your role is to note whether the exclusions look large enough to change the picture.

What to say to a CTO or engineering head

The fractional CTO overview lists other moments when this comes up naturally, such as a platform review or a cloud migration.

How the introduction and rewards work

You introduce the company; SourceX qualifies it; the company completes a data inventory with help from the data inventory builder; price and terms are agreed; buyers review; and the deal closes before data is delivered. Partners earn 25% of the eligible platform fees SourceX actually collects from the referred company's licensing deals, capped at $100,000 per referred company, and only after the buyer pays and SourceX receives its fee. No reward is guaranteed, and the reward never reduces the company's proceeds. The who qualifies page lists the full baseline.

When to leave it alone

Skip companies whose boards were reset in a migration with no archive, whose repositories are mainly client-owned, or whose owner will not consider an exclusive license.

Next step

If you advise a company with a long-running Azure DevOps or TFS history, register as a partner and introduce the sponsor, or point them to sourcex.si/apply with your referral link.