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 28, 2026
share this post:
Every organization uses Azure DevOps differently. Over time, teams customize workflows, add fields, create work item types, and modify process rules to match how they plan, build, test, and release software.
These customizations improve daily operations, but they also make migration more complex.
Unlike the source environment, the target Azure DevOps Services (formerly Visual Studio Team Services) organization often has different processes, governance rules, or project structures. During migration, these differences must be identified and handled correctly.
Migration tools compare the source environment against the requirements and supported configurations of the destination environment. If significant differences are found, the migration may require additional mapping, remediation, or planning before it can proceed successfully.
This is especially common in organizations that have customized Azure DevOps over many years across multiple projects and business units.
Most organizations do not customize Azure DevOps simply for convenience. These changes usually reflect real business requirements.
Common reasons include:
Understanding why these customizations exist helps determine whether they should be preserved, simplified, or replaced during migration.
Not all customizations create migration issues. However, certain modifications tend to generate warnings more frequently than others.
Many organizations add approval states, review stages, or department-specific workflows.
When workflow transitions differ from what the destination environment expects, migration tools may flag inconsistencies that require review.
For example:
Custom rules associated with these transitions must often be evaluated before migration.
Organizations frequently customize field behavior.
Examples include:
When these rules differ between source and destination environments, migration validation may identify potential mismatches.
Some teams introduce work item types beyond standard User Stories, Bugs, Tasks, and Epics.
Custom work item definitions can require additional planning because equivalent structures may not exist in the destination environment
Organizations sometimes modify process settings that control work item behavior and visual presentation.
Although some of these changes may appear minor, they can still generate migration warnings that require remediation or mapping decisions.
Many organizations consider reverting projects to standard processes before migrating.
While this approach may reduce certain validation warnings, it is not always the best option.
Teams should consider:
In organizations with multiple projects and extensive customization, resetting processes can become a large initiative on its own.
The effort required to redesign workflows, retrain users, and validate business processes may outweigh the benefits of standardization.
This is one of the most common concerns during migration planning.
Organizations often need to preserve:
Removing process customizations without understanding their relationship to historical data can introduce additional complexity.
Before making process changes, teams should determine which information must remain available after migration and how that information will be preserved.
Manual remediation may be manageable in a small environment with a limited number of projects.
However, organizations frequently encounter challenges such as:
Reviewing and correcting every customization individually can consume significant effort and extend migration timelines.
As environments grow, migration planning often shifts from simply moving data to determining how that data will fit into the target environment.
In some situations, organizations choose not to standardize processes before migration.
Instead, they evaluate migration approaches that support mappings between source and destination configurations. This approach can help organizations move data while accommodating differences in workflows, states, and fields.
The suitability of this approach depends on the specific source environment, destination configuration, and migration requirements.
For many organizations, the goal is not to recreate a default process. The goal is to preserve business context while moving to Azure DevOps Services.
Organizations with customized Azure DevOps Server or TFS environments often need a migration approach that accounts for differences between source and destination configurations.
OpsHub Migrator for Microsoft Azure DevOps (OM4ADO), co-developed with Microsoft is designed for Azure DevOps and TFS migration scenarios and supports configurable mappings that can help organizations address common migration challenges associated with customized environments.
Organizations may need to map:
A mapping-based migration approach can help organizations handle differences between source and destination environments without first rebuilding every project around a default template.
Migration success is about more than moving records.
Organizations often need to preserve:
Maintaining this information helps teams continue working with the historical context they rely on for planning, auditing, and reporting.
Migration requirements differ across organizations.
Some teams prefer a phased migration strategy to reduce disruption, while others choose a one-time full lift and shift migration approach.
Evaluating migration options that support the preferred rollout strategy can help align technical execution with business goals.
Before beginning migration activities, organizations should review:
1. Custom fields: Identify fields that differ from standard Azure DevOps process definitions.
2. Workflow states and transitions: Document custom states and workflow rules that may require mapping.
3. Work item types: Review custom work item types and determine how they will be represented in the destination environment.
4. User identities: Plan how user identities will be maintained across systems.
5. Reporting dependencies: Identify reports, dashboards, and integrations that rely on customized configurations.
6. Historical data requirements: Determine which work items, attachments, comments, and relationships must be preserved.
A detailed assessment early in the project often reduces unexpected issues later in the migration lifecycle.
Process template customizations are one of the most common reasons Azure DevOps Server to Azure DevOps Services migrations become more challenging than expected. Workflow modifications, custom fields, work item types, and process configuration changes can all introduce migration complexities that require careful planning.
Before attempting large-scale process remediation, organizations should understand the role these customizations play in their environment and determine how historical information, user identities, attachments, relationships, and link traceability will be maintained after migration.
A well-planned migration strategy can help organizations move to Azure DevOps Services (formerly VSTS) while preserving the information and context their teams depend on.
Customized Azure DevOps migration made easier
