No-code integration platform for rich bi-directional sync
Zero downtime migration to tool of your choice
Keep Historical Data, Without Slowing Down Your Tools
Migrate or restructure Azure DevOps Instances
Real-time, context-rich data lake for AI or analytics
By Role
Accelerate delivery with clear insights
Transform smarter with a connected digital thread
Confident transitions for every enterprise change
By Initiative
Modernize and move to cloud without disruption
Modernize legacy systems for a connected enterprise
Build a compliant digital thread for complex environments
Build the foundation for smarter AI
By Domain
No-code integration across teams & systems
Enable collaboration between IT, support & business teams
Connect PLM & engineering teams for smarter products
Ensure regulatory compliance from start to release
Explore the latest in technology and best practices
Success stories from the field
Actionable insights for your business challenges.
See solutions in action
Learn, plan, and execute with confidence
Official announcements and updates
Join discussions that drive results
Stay ahead with curated insights
Evaluate before you buy
Explore the latest in technology and best practices
Success stories from the field
Actionable insights for your business challenges.
See solutions in action
Learn, plan, and execute with confidence
Official announcements and updates
Join discussions that drive results
Stay ahead with curated insights
Moving between Azure DevOps organizations or tenants? This guide covers moves, merges, and splits, what migrates, your options, and the five stages to run it. OpsHub Migrator for Microsoft Azure DevOps (OM4ADO) supports it with history, user identity mapping across tenants, and delta migration, so teams keep working.
Azure DevOps migration moves projects between organizations, tenants, or projects and can include merging several sources into one target or splitting one source into several targets. It covers work items with history, comments, attachments, and links, plus test plans, pipelines, repositories, dashboards, area and iteration paths, users, teams, and groups. Options include Microsoft’s Data Migration Tool for Server-to-Services moves, a dedicated solution such as OM4ADO, or CSV export and import. The five stages are planning and scoping, mapping user identities, reconciling process templates, running a dry run with delta migration and cutover, and validating. A migration solution fits moves where history, traceability, and user identities must carry over while teams keep working.
Moving work from one Azure DevOps organization to another sounds like a copy job. It is not. The quick methods change work item IDs, reset dates, and drop links. A planned migration keeps the history, the relationships, and the people’s work intact.
Azure DevOps to Azure DevOps migration moves projects between two Azure DevOps Services organizations, where both the source and the target are in the cloud. If your source is still on-premises (TFS or Azure DevOps Server), that is a different path, covered in our TFS to Azure DevOps guide.
The migration comes in three types of move:
Project to project: One or more team projects move into another organization.
Organization to organization: All projects of an organization move into a different organization.
Tenant to tenant: The target organization sits in a different Microsoft Entra ID tenant, so sign-in and user identities change along with the data.
Any of these moves can also be a merge (several sources into one target) or a split (one source into several targets). Merges and splits have their own guides: How to merge Azure DevOps instances and How to split an Azure DevOps instance.
A change in the business usually triggers the move:
Three approaches are available. Each fits a different kind of move.
| Approach | What it fits | Points to consider |
|---|---|---|
| Microsoft Data Migration Tool | Moving one Azure DevOps Server collection into a new Azure DevOps Services organization | Microsoft documents it for Server to Services moves. Organization to organization is not among its scenarios. |
| A dedicated migration solution such as OM4ADO | Moves where history, links, test assets, and user identities must carry over, and the source stays in use until cutover | Set up through a graphical interface, with no code to write |
| CSV export and import | Moving a list of work items between projects | Microsoft documents only parent-child links on import. History is not carried over, and some fields (such as Effort) are ignored on import. |
For a closer comparison, see our ADO migration tool guide.
| Artifact | What migrates |
|---|---|
| Work items | Standard and custom work items, with history, comments, attachments, inline images, and user mentions |
| Relationships | Parent, child, and related links between work items |
| Test entities | Test plans, test suites, test runs, and test results |
| Pipelines | Build and release pipelines |
| Queries, dashboards, and widgets | Queries, dashboards, and widgets, with their configuration |
| Area and iteration paths | Area and iteration paths, mapped to the target |
| Users, teams, and groups | Users, teams, and groups, with user identity mapping across tenants |
| Repositories | Git repositories, and TFVC changesets with version history and changeset labels |
For a full side-by-side comparison of every tool, read best Azure DevOps migration solutions in 2026.
OpsHub Migrator for Microsoft Azure DevOps (OM4ADO) is a migration solution built for Azure DevOps and listed on the Microsoft marketplace. You set up the migration in a graphical interface, without writing code. It supports:
OM4ADO is purpose-built for Azure DevOps and listed on the Microsoft marketplace, and OpsHub has spent over two decades moving engineering data between systems without losing history or traceability.
A migration runs in five stages.
For a worked example, watch the Azure DevOps cloud-to-cloud migration video.
Merge: two sources can carry the same work item IDs, area paths, or team names, and these collide in the shared target. Decide up front whether incoming teams become separate projects or separate teams in one project. Build and release history does not combine cleanly. See the merge guide.
Split: move only the chosen parts without orphaning the links between them. For example, moving only active work items can leave their completed parents behind. See the split guide.
How do you recover from a partial failure?
A migration should retry the failed items and resume from where it stopped, without deleting what is already in the target. This way, a partial run is recoverable and not a loss.
The data is an easy part. What decides the outcome is whether history, relationships, and people’s work arrive intact, and whether teams keep working during the move. Settle the target structure, map identities, reconcile process templates, prove the plan with a dry run, and validate against the source before cutover.
This page is part of our wider guide, How to migrate across the Azure DevOps ecosystem.
Planning a move between Azure DevOps organizations or tenants? Talk it through with a migration engineer. Book a slot
It depends on the size and the stakes of the move. Building it yourself is mostly a cost of engineer time: setup, scripts, identity mapping, process template work, and fixing failures. A migration solution takes on that work, including the failure handling. This table shows when each route fits.
| Building it yourself fits when | A migration solution fits when |
|---|---|
| The move is small | You are moving many projects or many work items |
| Process templates are standard | Process templates are customized and differ |
| Source and target share a tenant | Source and target are in different tenants |
| Engineers know the Azure DevOps object model and have time | History and traceability must survive for audit or reporting |
| A short outage is acceptable | The source must stay in use during the move |
AI assistants can speed up the first draft of a migration script, but the script still runs against production data, so it needs a review, and responsibility for the result stays with your team.
Yes. A target does not need to be empty, though a clean target makes validation simpler.
Microsoft’s Data Migration Tool is documented for Azure DevOps Server to Azure DevOps Services moves. For organization to organization moves, teams use scripts or a dedicated migration solution such as OM4ADO.
The duration depends on four things: the volume of work items and repositories, Azure DevOps API rate limits, how different the source and target customizations are, and how much identity and process mapping is needed. A dry run on your own data gives the reliable timeline.
Yes, with OM4ADO. It can bring several source collections into one Azure DevOps organization. The full method is in the guide to merging multiple Azure DevOps or TFS instances.
Get a migration plan built for your estate.
Get a migration engineer to map your scope, risks, and approach in a free 30-minute session.
