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 and move to cloud without disruption
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
Salesforce captures customer-facing activities while Jira manages engineering execution. Integrating the systems reduces manual handoffs and improves transparency across teams. This guide covers architectural considerations, mapping strategies, and integration best practices.
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
See side by side comparison
July 20, 2026
share this post:
Direct answer: An Azure DevOps migration is the process of moving work items, version control history, test data, pipelines, and project configuration from one Azure DevOps or TFS environment to another.
This can mean moving from an on-premises server to the cloud, combining several instances into one, splitting a single instance into several, or moving projects within the cloud itself. Each of these is a different scenario with its own planning steps.
Each Azure DevOps migration scenario involves different data types, migration volumes, and source or target systems, so a single migration plan rarely works well for every case.
Understanding which scenario applies to your situation is the first step in planning a migration that keeps history, traceability, and team productivity intact.
These are the 6 scenarios teams run into most often when planning an Azure DevOps or TFS migration:
Each is covered below, including when it applies, what needs to be preserved, the main challenge, and how it is typically handled.
Direct answer: This scenario moves projects from an on-premises TFS server to Azure DevOps Services in the cloud, while keeping work items, test data, pipelines, and version control history intact.
When this happens
What needs to be preserved
Main challenge
Moving a large volume of historical revisions to the cloud without breaking the links between work items, code changes, and test assets.
How it is typically handled
A guided, UI-based migration tool connects directly to the TFS server and the target Azure DevOps organization, maps process templates and user identities, and transfers data while both environments stay usable. Teams can migrate directly to Azure DevOps without first upgrading TFS to a newer on-premises version, and the target organization does not need to be empty before migration starts.
Direct answer: This scenario consolidates multiple Azure DevOps (cloud) or TFS environments into a single instance, typically after a merger, acquisition, or internal restructuring.
When this happens
What needs to be preserved
Main challenge
Reconciling different process templates, field structures, and naming conventions from multiple sources into one consistent target without losing history.
How it is typically handled
Migration tools convert the varied source formats into one consistent target structure and support template changes as part of the move. Fields, users, and processes are mapped before the final cutover, and the migration is validated in stages so issues surface before they affect production data.
Direct answer: This scenario divides a single Azure DevOps or TFS instance into multiple separate instances, often needed when a business unit is spun off, restructured, or requires an isolated environment.
When this happens
What needs to be preserved
Main challenge
Extracting a clean subset of projects without leaving broken references behind in either the source or the target environment.
How it is typically handled
Selective, project-level migration moves specific projects to a new or already active target instance, so the rest of the source environment is left untouched. Because the target does not need to be empty, the split projects can land directly in an existing organization.
Direct answer: This scenario transfers projects between two Azure DevOps cloud organizations, or between two tenants, while preserving work items, change history, user identities, pipelines, and relationships.
When this happens
What needs to be preserved
Main challenge
Matching users and identity structures across two separate Microsoft Entra (Azure AD) tenants, since accounts do not automatically carry over between them.
How it is typically handled
One-to-one and many-to-one user identity mapping connects source accounts to the correct target accounts before migration starts. A guided UI platform lets teams configure and repeat the same migration setup across many projects and teams without slowing down either organization.
Direct answer: This scenario migrates projects between two on-premises Azure DevOps Server (Team Foundation Server) versions, keeping data integrity and full history intact while moving to a newer, supported release.
When this happens
What needs to be preserved
Main challenge
Handling schema and process template differences between TFS versions without causing downtime for active development teams.
How it is typically handled
Migration tools that support all Azure DevOps Server (TFS) versions from 2010 through 2022 move data between old and new on-premises collections directly, preserving cross-project links. The migration is validated in stages before the final cutover so teams can confirm data integrity before switching over.
Direct answer: This scenario moves projects from Azure DevOps Services back to an on-premises TFS environment, keeping history, traceability, and project relationships intact.
When this happens
What needs to be preserved
Main challenge
Some cloud-only features, such as certain widgets or pipeline types, do not have an exact on-premises equivalent, so they need careful mapping during the move.
How it is typically handled
Migration tools map cloud entities to their closest on-premises equivalents and run pre-migration checks that flag source data differences before they reach the target. The migration is staged and validated in phases rather than moved in a single pass, so issues are caught before the final cutover.
Each Azure DevOps migration scenario is different, but many of the underlying risks are the same. Whether you are moving from TFS to Azure DevOps Services, merging multiple instances, splitting projects, or migrating between cloud organizations, the migration has to protect the relationships between people, processes, code, work items, test data, and pipelines.
The most common challenges include:
These challenges are often the reason Azure DevOps migration becomes more involved than a simple data transfer. For a deeper breakdown of these risks and how to solve them, read our detailed guide on Azure DevOps migration challenges in 2026.
Once your scenario and the capability it needs are clear, the work left is turning that into a plan. These five steps cover what to do, and what tends to go wrong when a step gets skipped.
Run one project through the mapping and migration process before committing the rest. Teams that skip this step and go straight to a full migration are the ones most likely to discover mapping problems midway through, when they are harder to fix.
Get expert guidance for your Azure DevOps move
