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
This guide explains how to maintain data integrity during Jira Cloud migrations, and Jira migration in general, using Jira Cloud Migration Assistant (JCMA) with OpsHub Migration Manager (OMM). It covers what moves, where integrity breaks, the checks that keep data accurate, and how the two tools work together.
Case study
Software solutions
OpsHub Migrator for Microsoft Azure DevOps
STAEDEAN, a global provider of industry-specific software embedded in Microsoft Dynamics 365 for life sciences, manufacturing and equipment rental, as well as data management solutions, needed to retire its last on-premise data centre without losing a decade of engineering history locked in TFS 2013. OpsHub Migrator for Microsoft Azure DevOps migrated projects, their full work item revision history, and TFVC source code into Azure DevOps Services with zero system freezes and zero rework after sign-off.
Projects migrated
Revisions preserved
Artifacts migrated
TFVC history
carried forward
Rework needed
post
migration
01
STAEDEAN's on-premise TFS 2013 environment held years of work item history and TFVC source code. Day-to-day development had moved to other platforms, while the environment was deliberately retained to preserve access to that history until a suitable migration path was available.
TFS 2013 predates modern Azure DevOps Services APIs. Native migration utilities from Microsoft require a recent on-premise version as the starting point, making a direct lift from TFS 2013 infeasible without first performing multiple costly upgrades.
Active Directory accounts on the TFS server have no automatic counterpart in Azure DevOps Services. Without a deliberate mapping, every work item revision, changeset, and comment would arrive in the target attributed to the wrong user.
STAEDEAN had a fixed deadline for decommissioning the on-premise environment. The migration needed to be completed and validated before that date so the remaining legacy workload could be retired on schedule.
Engineers still referenced the TFS environment for historical context. Any migration approach that required a system freeze or extended blackout would cut off access to that history exactly when teams might need it most.
Custom migration scripts built against TFS 2013 APIs would be working with aging endpoints and no built-in validation. One missed field mapping or broken revision chain could go undetected until it was too late to fix cleanly.
02
Purpose-built for the version gaps and identity boundaries that general-purpose tools cannot handle
Each of the three Azure DevOps projects mapped directly to its corresponding project in the target cloud organization, preserving project boundaries, field structures, and internal relationships exactly as STAEDEAN's teams know them.
TFVC repositories for all three projects migrated with complete changeset history intact, up to 5,000 changesets and under 1 GB of source code, so the development record stays traceable for audits, rollbacks, and institutional knowledge.
A user mapping between on-premise Active Directory accounts and Azure DevOps Services identities was prepared and imported before migration began, keeping authorship and change attribution correct across the identity boundary.
The source environment remained fully available throughout the migration. Engineers retained reference access to the original TFS instance at all times, with no freeze period and no risk of a gap where history exists in neither system.
OM4ADO connects directly to TFS 2013 and Azure DevOps Services without requiring version upgrades. Where native tooling mandates that the source be brought up to a recent on-premise release first, OM4ADO works across the full version range.
OM4ADO was deployed within STAEDEAN's own infrastructure. Credentials and data never left the customer's network, giving STAEDEAN full control over security and data residency throughout the engagement.
03
History-preserving, on-premise deployed, 100% under customer control
OpsHub migration layer
Non-disruptive
History-preserving
Dependency-aware
Work items migrate with full revision history. TFVC repositories carry forward complete changeset records. Authorship attribution preserved through identity mapping.
Source stays live and accessible. Engineers retain full read access to TFS throughout the migration, with the option to continue working without interruption.
Connects directly to TFS 2013 and Azure DevOps Services. No intermediate upgrades required, unlike native migration utilities that mandate a recent source version.
04
Ecosystem audit
OM4ADO deployment
Optimization & sign-off
Full structure and history preserved, across all projects
Projects
Artifacts
Up to 2,000 work items
Revisions
Up to 10,000
Change sets
5000
Source -to-target mapping
Work item (with full revision history) → Work item
TFVC repository (<1 GB) → TFVC repository
User identity mapping from on-premise Active Directory to Azure DevOps Services cloud accounts
06
Results at a glance
Projects migrated
Revisions preserved
TFVC history carried forward
Impact on business continuity
| Capability | Description | Migration Role |
|---|---|---|
|
Direct migration without
needing version upgrade |
Direct migration from TFS 2013 to Azure DevOps Services without
intermediate version upgrades |
Eliminated the multi-step upgrade path that native tools require, saving weeks of
effort and risk |
|
Work item migration with history |
Full migration of work items with complete revision history and field-level
mapping |
Preserved the development record so that historical decisions, state changes,
and context remain inspectable in the target |
|
TFVC source code migration |
TFVC repositories migrated with changeset history, preserving the full code
evolution record |
Maintained traceability for audits, rollbacks, and regulatory inquiries without
losing any development timeline |
|
Identity mapping |
Mapping between on-premise Active Directory and Azure DevOps Services
cloud identities |
Ensured every work item, changeset, and comment is attributed to the correct user in
the target system |
|
On-premise deployment |
Migration tool installed within the customer’s own infrastructure, not a third
party cloud relay |
Data and credentials stayed within STAEDEAN’s network perimeter,
meeting data residency and security requirements |
|
Template validation |
Automated comparison of source and target process templates before
migration configuration |
Field and entity mismatches caught and resolved upfront rather than discovered
mid-migration |
What was delivered
With the legacy projects safely in Azure DevOps Services, the on-premise environment and the data centre contract sustaining it no longer need to exist.
Years of work items, revisions, and source history are now accessible in the same platform engineers use daily, with authorship intact.
The source TFS environment stayed live and fully operational throughout the entire migration window. Teams never lost access to historical data.
OM4ADO bridged the gap from TFS 2013 to Azure DevOps Services directly. STAEDEAN avoided the cost, and timeline risk of multiple interim TFS versions.
A fixed, well-bounded scope of projects and defined artifact volume kept the engagement fast and predictable, aligned to STAEDEAN's deadline.
Automated template validation, monitored execution, and validation cycles ensured every revision, and changeset landed correctly the first time.
Delivered, live, and next steps
