How to migrate Azure DevOps from one organization / tenant to another?

Organizations occasionally need to reorganize their Azure DevOps (VSTS) cloud environments due to mergers, acquisitions, tenant consolidation, or governance changes. In these situations, development teams may need to migrate projects and data from one Azure DevOps organization to another.

While both environments may already be cloud-based, the migration process is rarely straightforward. An Azure DevOps organization contains deeply connected artifacts such as repositories, work items, pipelines, and test assets. Moving these components without disrupting development workflows requires careful planning and the right migration strategy.

This guide explains why organizations perform **Azure DevOps (Cloud) organization migrations,** the challenges involved, and the steps required to complete the migration while preserving development history and traceability.

Why organizations need to move Azure DevOps projects between organizations

Several scenarios require teams to migrate DevOps environments from one organization to another within Azure DevOps (VSTS).

• Tenant consolidation: Large enterprises often operate multiple Azure DevOps organizations across different business units. **Consolidating these environments** improves governance, reporting, and standardization.
• Mergers and acquisitions: After a merger or acquisition, engineering teams may work in separate DevOps organizations. Moving projects into a unified environment allows teams to align development workflows and infrastructure.
• Organizational restructuring: Development teams sometimes move across departments or subsidiaries. In such cases, projects must be migrated to the appropriate Azure DevOps organization.
• Security and identity alignment: Enterprises may migrate DevOps environments to align with centralized identity platforms such as Microsoft Entra ID, ensuring consistent access policies and compliance controls.

These scenarios make Azure DevOps tenant migrations a common requirement for enterprises operating at scale.

What needs to be migrated in Azure DevOps

An Azure DevOps environment contains multiple artifacts that are connected to each other. Migrating them individually without preserving relationships can break development traceability. Key components typically involved in a migration include:

-Work items: Work items capture requirements, user stories, tasks, and defects. Their revision history, attachments, and comments must be preserved to maintain development context.

• Git repositories: Repositories contain source code along with commit history, branches, and pull requests. Maintaining repository integrity is critical for development continuity.
• Boards and backlogs: Teams rely on boards and backlog structures to manage work. These elements must remain intact after migration to avoid workflow disruptions.
• Pipelines: Build and release pipelines automate CI/CD processes. Migrating them ensures that deployment workflows continue operating in the new environment.
• Test plans and Test cases: QA teams depend on test artifacts linked to development work items.
• User permissions: Access control and activity history depend on correct user mapping between the source and target organizations.

Maintaining links between commits, work items, builds, and tests is essential to preserve development traceability.

Common challenges in Azure DevOps organization migration

Migrating DevOps environments between organizations introduces several technical and operational challenges like:

• Preserving work item history: Organizations often need to retain full revision history, attachments, and comments for compliance and audit purposes. Incomplete migrations can result in missing history or attachments, which disrupts reporting and governance.
• Maintaining Artifact Relationships: Azure DevOps connects multiple artifacts across the development lifecycle:

—-Work items linked to commits

—- Pull requests connected to code reviews

— -Builds triggered by repository updates

If these relationships break during migration, teams lose visibility into how requirements connect to code changes and deployments.

• Identity mapping issues: ADO relies on identity management systems for user access and activity tracking. When projects move to another organization, user identities from the source environment must correctly map to users in the target environment. Incorrect mapping can result in historical work appearing assigned to unknown users.
• Process template differences: Azure DevOps supports different process models, each with unique workflows and work item structures. If the source and target organizations use different process templates, migration tools must translate these differences to ensure workflows continue functioning correctly.
• Pipeline dependencies: Pipelines often depend on service connections, agent pools, and external integrations. Failing to migrate these dependencies can cause pipelines to fail after the migration.

Migration Approaches for Azure DevOps Organizations

Organizations typically adopt one of several approaches when migrating DevOps environments.

• Manual migration: Small teams sometimes attempt to recreate projects manually in the target organization. This method involves exporting repositories and manually rebuilding work items, pipelines, and permissions. However, manual migration is time-consuming and often results in broken relationships between artifacts.
• Script-based migration: Some teams use custom scripts and APIs to migrate data between organizations. While this approach offers greater control, it requires deep knowledge of Azure DevOps APIs and significant testing to ensure data accuracy.
• Automated enterprise -grade migration platforms: Large DevOps environments often rely on automated migration platforms that preserve relationships between artifacts.

Enterprise -grade migration solutions such as **OpsHub Migrator for Microsoft Azure DevOps (OM4ADO) initially funded by Microsoft** help organizations migrate repositories, work items, and pipelines within Microsoft landscape with your data and history intact and with zero downtime and no disruption.

Step-by-Step Azure DevOps organization migration process

A structured migration plan helps ensure minimal disruption and no downtime to development activities.

Step 1: Assess the source environment

Begin by analyzing the existing Azure DevOps organization.

Identify:

• Projects and repositories
• Work item types and custom fields
• Pipelines and service connections
• User accounts and permissions

Understanding the current environment helps teams anticipate migration challenges.

Step 2: Define mapping rules

Mapping determines how artifacts move from the source organization to the target organization.

This includes mapping:

• Work item types
• Users and identities
• Custom fields
• Project structures

Clear mapping rules ensure that migrated data remains meaningful in the new environment.

Step 3: Run test migrations

Before migrating the entire system, perform pilot migrations using smaller projects.

Test migrations help validate:

• Data completeness
• Relationship integrity
• Pipeline functionality
• User access permissions

Identifying issues during pilot runs reduces risk during the final migration.

Step 4: Execute the migration

Once validation is complete, execute the full migration. Organizations often temporarily pause development activity to ensure that data remains consistent during the migration process. Data is typically migrated in batches while monitoring system performance.

Step 5: Validate the target environment

After migration, teams must verify that the target organization reflects the original environment.

Validation should confirm:

• Work item counts match the source system
• Attachments and revision history remain intact
• Links between artifacts are preserved
• Pipelines run successfully

Thorough validation ensures the new environment supports ongoing development activities.

ADO tenant to another ADO tenant migration

Five steps to migrate Azure DevOps (Cloud) from one tenant / organization to another with OM4ADO

How to migrate from an Azure DevOps organization to another in 5 easy steps

**Drop us a line to request a free personalized demo for your ADO-to-ADO migration use case.**

Final thoughts

Migrating projects from one Azure DevOps organization to another is more than a simple data transfer. The process involves preserving development history, artifact relationships, and identity mappings across environments.

Organizations that approach the migration with careful planning, structured testing, and automated tools can successfully move their DevOps environments without disrupting productivity.

For enterprises undergoing tenant consolidation, mergers, or governance changes, a well-planned Azure DevOps organization migration ensures that development operations remain stable while the organization evolves.

For teams planning large-scale Azure DevOps organization migrations, solutions like **OpsHub Migrator for Microsoft Azure DevOps can help streamline the transition while maintaining data integrity. Let’s discuss.**

Frequently asked questions (FAQs)

Q1. How can I move Azure DevOps work items and test plans to a new subscription or organization without affecting work item IDs?

Ans.1) When migrating Azure DevOps Services (ADO) work items and test plans to a new subscription in another region, preserving Work Item IDs may not be possible in either approach. However, here are a couple of ways you can handle the migration, making sure data is preserved and traceability is maintained.

• CSV import and export: This works for small scale.History, Comments and attachments may not be preserved. There’s usually some downtime. During this period, you won’t be able to update or create new data in old projects.
• Live Migration with enterprise tool: You can migrate work items, test artifacts, pipeline, builds and other project related data along with the history, comment, attachment/images, links, rich text along with the mentions. Additionally, you can also perform the selective migration like test plans or work items with specific tags form specific project. You can migrate the original work item ID in a custom field for reference. Also, keep doing your work while the data moves in the background.

You can explore **OpsHub Migrator for Microsoft Azure DevOps (OM4ADO) cobuilt with Microsoft**. It has migrated to and from Azure DevOps Services and Server over the last decade.

Q2. Is it possible to clone an entire Azure DevOps project from one organization to another?

Ans 2. Yes, it’s possible to clone or migrate projects, including work items, queries, and dashboards, from one Azure DevOps organization to another. When planning such a migration, here are some key considerations:

• Downtime and disruption: Minimizing or eliminating downtime to ensure teams can continue working during the migration process.
• Data integrity: Ensuring all project elements such as work items, repos, pipelines, and test assets migrate without any loss or corruption.
• Customization and complexity: Handling custom fields, workflows, and other unique configurations smoothly.
• Support and flexibility: Access to robust support throughout the migration to address any unexpected challenges.

Migration approaches:

• Azure DevOps rest APIs: Custom scripts can be used to export and import Work Items, Queries, and other configurations. This provides flexibility but requires significant effort to maintain relationships, dependencies, and history.
• Azure DevOps migration tool: This tool helps migrate work items and artifacts but may require extensive configuration and have limitations, such as not supporting dashboards or pipelines.
• Migration tools on Marketplace: **OpsHub Migrator for Microsoft Azure DevOps (OM4ADO) **provides a Live++ migration method ensuring zero downtime and no disruption to ongoing work while supporting high fidelity migration including history, attachments, pipelines, dashboards, and user permissions. Migrate the projects without worrying about data loss, downtime, or complex configurations.

Q3. How can we migrate Azure DevOps projects to a new company tenant after an acquisition while keeping project data and user mappings intact?

A few things are worth thinking through before starting the migration:

• Downtime planning: Many teams prefer phased migrations so development work can continue during the transition.
• User identity mapping: Source tenant users must be mapped to accounts in the new tenant so work item assignments, comments, and history still show the correct authors.
• Process templates and custom fields: The destination tenant should support the same work item types, workflows, and custom fields to avoid data mismatches.
• Scope of migration: Decide whether to move only work items or also repos, pipelines, test plans, attachments, and linked artifacts.
• Relationship continuity: Links between work items, commits, builds, and tests should remain intact to preserve traceability.

OM4ADO which is co-built with Microsoft supports tenant-to-tenant migrations while preserving links, comments, and attachments and more. It enables phased or complete migrations, supports reverse sync, and helps move projects without downtime, disruption, or data loss.

**Feel free to reach out to our migration engineers for an initial discussion on migration planning.**