DEV Community: Dr. Ankita Mehta

How Canvas Credit Union consolidated multiple Azure DevOps projects into a single cloud environment: Lessons for 2026

Dr. Ankita Mehta — Wed, 03 Jun 2026 10:41:31 +0000

Moving from Azure DevOps Server to Azure DevOps Cloud is often viewed as a straightforward migration project. In reality, the challenge becomes much larger when multiple projects, years of historical data, and separate teams are involved.

Canvas Credit Union recently faced this scenario while modernizing its development ecosystem. The organization wanted to move away from an on-premises Azure DevOps Server (TFS) environment and consolidate multiple projects into a single Azure DevOps Cloud project without losing visibility, history, or traceability.

Here's what engineering and DevOps teams can learn from the initiative.

The problem with siloed project environments

Over time, organizations often create separate Azure DevOps projects for different teams, business units, or initiatives.

While this approach may work initially, it can eventually lead to:

Limited visibility across teams.
Fragmented reporting.
Duplicate administrative effort.
Difficulty tracking work across projects.
Reduced portfolio-level insight.

Canvas wanted to eliminate these barriers and create a more connected development environment.

The migration objectives

The modernization initiative focused on four primary goals:

Move to Azure DevOps Cloud: The organization wanted to take advantage of cloud-based capabilities while reducing infrastructure management overhead.
Preserve historical information: Years of project data needed to remain accessible after migration.
Maintain traceability: Relationships between work items and historical records had to be preserved.
Consolidate projects: Multiple Azure DevOps Server projects needed to be merged into a single Azure DevOps Cloud project.

How the migration was executed

Canvas partnered with OpsHub and used OpsHub Migrator for Microsoft Azure DevOps (OM4ADO) to perform the migration.

The migration approach prioritized continuity and data preservation. Rather than forcing teams to pause development activities, the migration was completed without downtime.

This enabled teams to continue working while project data was consolidated and transferred.

Results

More than half a million records preserved: Historical information accumulated over several years was successfully migrated.
Better visibility across teams: A single Azure DevOps Cloud environment provided a consolidated view of work across digital and IT functions.
Faster reporting and decision-making: Teams gained easier access to information required for planning, reporting, and Agile execution.
Reduced complexity: Managing one consolidated environment simplified administration and improved overall efficiency.

What stands out from this migration

One of the most interesting aspects of the project is that modernization and consolidation happened simultaneously.

Many organizations treat these as separate initiatives:

Move to the cloud.
Consolidate projects later.

Canvas combined both efforts into a single initiative while maintaining continuity and preserving traceability.

Customer perspective

“OpsHub migration tool facilitated the entire migration process in a non-disruptive manner. Most importantly, it helped us provide a holistic view of our portfolio of work and projects across all our digital and IT teams and still allowing the individual teams to focus on their respective tasks to complete development effortlessly. Our project gained traction within the span of a few months.”

Mike Ranson
AVP of IT – Enterprise Solutions
Canvas Credit Union

Final takeaway

Cloud migration projects often focus on moving data from one environment to another.

Canvas Credit Union's experience demonstrates that the bigger opportunity may be using migration as a catalyst for consolidation, improved visibility, and better portfolio management.

When executed correctly, organizations can modernize their Azure DevOps environment while preserving historical context, maintaining traceability, and enabling teams to continue working without interruption.

Looking for a migration strategy for a similar use case? Let’s talk.

Splitting Azure DevOps into two organizations in 15 days (Real-world case study, 2026)

Dr. Ankita Mehta — Tue, 02 Jun 2026 14:08:54 +0000

The problem

A cybersecurity company needed to split its Azure DevOps environment into two separate organizations as part of a corporate restructuring.

This wasn’t a simple migration. It was a data split with dependency preservation.

What needed to happen

6 Azure DevOps projects had to be divided
Work items had to be assigned to the correct new organization
Nothing could be lost: Comments, Attachments, History and Links between items
No downtime allowed during migration

Why this is tricky

If you’ve ever worked with Azure DevOps migrations, you know the complexity comes from:

Linked work items
Cross-referenced dependencies
Historical audit trails
Custom fields and relationships

Splitting makes this even harder because you’re not just moving data—you’re separating connected systems.

Data Migration Tool used: OM4ADO

The team used OpsHub Migrator for Microsoft Azure DevOps (OM4ADO).

It helped with:

Work item filtering and routing logic
Dependency-preserving migration
Metadata retention
Safe execution without disrupting active development

What happened during migration

12,700 work items processed
Full history and attachments retained
Dependencies remained intact
Data cleanly split across two organizations
Completed within 15 days

Outcome

Both new Azure DevOps environments were fully operational with:

Clean data separation
No broken links
No missing history
No downtime impact

Takeaway

If you are dealing with Azure DevOps restructuring, the hardest part is not migration-it’s keeping relationships intact while splitting systems cleanly.

OM4ADO handled exactly that.

Planning a similar migration? Let’s talk

The Essential Guide to Application Data Migration

Dr. Ankita Mehta — Tue, 02 Jun 2026 10:17:49 +0000

If you're working within the ALM ecosystem, you've likely faced a familiar problem: how to move to better tools without losing years of historical data, relationships, and traceability.

This guide walks through how application migration supports DevOps adoption while maintaining data continuity across systems.

Why application data migration matters more than it seems

At a basic level, application data migration means moving data from one system to another.

But in real enterprise environments, it's much more than that.

You're not just moving data, you're preserving:

Business context
Historical traceability
Compliance records
Team workflows

The challenge isn't just can the data move?
It's can it move without breaking how your teams work?

Moving everything blindly adds cost and risk, while moving too little breaks continuity. The balance is where most migrations succeed or fail.

Why migration becomes harder in enterprise systems

Enterprise applications are rarely simple. Data is deeply linked, and systems behave differently.

Here’s where complexity shows up:

Different data structures require transformation
Relationships between records must be preserved
Large datasets increase the risk of errors
Systems often remain active during migration

This combination makes migration more than a simple transfer.

Not all data needs to move

One of the biggest mistakes in migration is trying to move everything.

In practice:

Active data should move
Recent data should be evaluated
Historical data can often be archived

Reducing migration scope simplifies execution significantly.

Treat migration as a cleanup opportunity

Migration is not just about replication. It’s a chance to improve how systems work.

For example:

Replace over-custom workflows with standardized ones
Remove unnecessary fields
Align inconsistent templates
Automate manual processes

You don’t want to carry existing inefficiencies into your new system.

Comparing migration approaches

Enterprises select migration strategies based on business impact rather than speed alone.

Big Bang migration

Everything moves at once.

Fast
High risk

Phased migration

Data moves in stages.

Lower risk
More coordination required

Continuous synchronization

Both systems stay aligned during migration.

Strong continuity
Requires better tooling

Zero downtime vs zero disruption (they are not the same)

These terms are often confused.

Zero downtime → system stays available
Zero disruption → users don’t feel the migration

A system can be online and still disrupt users. That distinction matters.

Why teams move beyond scripts and basic tools

Basic approaches like scripts or native import tools can work, but they don’t scale well for complex migrations.

Enterprises typically need:

Data discovery and assessment
Flexible mapping and transformation
Continuous sync
Validation and reconciliation
Support for user continuity
Repeatable processes

This is where specialized platforms come in.

How modern migration actually happens

Modern migration is not a single event.

It happens in stages:

Discovery
Mapping
Test migration
Validation
Synchronization
Final cutover

Cutover is just the final step, not the whole process.

What makes enterprise migration different

At scale, migration is defined by how well it preserves reality, not just data.

That includes:

Attachments
Comments
Relationships
Hierarchies
Historical context

It also means keeping teams productive during the transition.

Where OpsHub comes into the picture

For complex migrations, organizations often evaluate whether they need a platform rather than a tool.

OpsHub focuses on:

Low-disruption migration
High data fidelity
Phased execution
Support for multiple systems

It’s suited for environments where traceability and continuity matter.

Key Takeaways

Migration is not just technical work.

It directly impacts:

Compliance
Productivity
Traceability
Modernization speed

Successful migrations:

Define scope clearly
Choose the right approach
Validate continuously
Avoid disrupting users

What to do next

If you're planning a migration:

Identify what data matters
Decide what needs transformation
Plan for user continuity
Select a migration model carefully

For complex environments, it’s worth evaluating platforms designed for enterprise migration.

FAQs

Q1) What is application data migration?

It is the process of moving data between systems while preserving context, structure, and relationships.

Q2) What is zero disruption migration?

It allows teams to continue working without interruption during migration.

Q3)When do you need a migration platform?

When data is complex, large-scale, or requires strict compliance and traceability.

Q4) What should you evaluate before buying?

Mapping flexibility, validation capability, scalability, and continuity support.

Q5) Why consider OpsHub?

When migration needs to preserve traceability and minimize disruption across systems.

Tosca and Jira integration: Why your QA and dev workflows still feel disconnected in 2026

Dr. Ankita Mehta — Tue, 26 May 2026 13:25:52 +0000

If your team uses:

Tricentis Tosca for testing
Atlassian Jira for development

You’ve probably seen this:

QA-Testing team finishes testing.
Dev team doesn’t see it.
Someone copies data manually.

This vicious error-prone cycle goes on.

The real problem is not the tools. It’s the communication gap between them.

Without integration:

Bugs get logged twice
Status updates don’t match
Devs miss test context
QA spends time chasing updates

What a good Tosca – Jira bidirectional integration looks like

When Tosca and Jira are connected:

Test execution updates Jira automatically
Bugs are created from test failures
Status transitions / updates flow both ways
Testing context (Comments, attachments, etc.) stays linked to issues

Key considerations before integrating Tosca and Jira

Before diving into how to best integrate Tosca and Jira, let’s look at the essential factors to consider:

1. Ensuring data consistency: Make sure that test results, defects, and statuses stay aligned across Tosca and Jira, minimizing discrepancies that could impact testing or development progress.

2. Maintaining traceability: Preserve the relationships between test cases, executions, and Jira issues for end-to-end traceability. This ensures that testing activities are linked to the corresponding development tasks.

3. Handling errors and sync failures: Check how the integration handles synchronization failures and retries. The system should automatically recover from disruptions, ensuring continuous data flow.

4. Mapping test data and workflows accurately: Map Tosca test entities with Jira issue types and workflows, ensuring that the data retains its meaning and context when transferred between systems.

5. Managing security and access controls: Ensure proper data access controls and permissions are in place to maintain secure and accurate data synchronization between the two systems.

How to integrate Tosca and Jira bidirectionally?

This guide uses OpsHub Integration Manager (OIM) to demonstrate the integration process. OIM simplifies Tosca–Jira synchronization by providing an external, no-code integration set up data integration solution that integrates both tools without modifying them.

How OIM works:

Synchronizes test cases, executions, defects, and more.
Maintains relationships, attachments, comments, and inline content across both systems.
Supports bidirectional synchronization for seamless, real-time updates between Tosca and Jira.
Includes built-error handling and retry mechanisms for smoother operation.

Learn more about how OIM facilitates Tosca – Jira bidirectional integration in near – real time.

Step-by-step Tosca–Jira integration with OIM

Here’s a step-by-step guide to setting up the Tosca–Jira integration with OIM:

Step 1: Set up the system connections

Add Tosca as the source system and Jira as the target system.

Validate authentication and connectivity to ensure seamless communication between the two systems.

Step 2: Define what data to sync

Map Tosca test cases, test steps, and executions to Jira issues such as bugs, tasks, and stories.

Choose which entities need to be synchronized to ensure relevant data flows between systems.

Step 3: Map fields and workflows

Align fields such as status, priority, and ownership between Tosca and Jira.

Map test execution results to Jira issue fields to maintain consistency.

Step 4: Set up sync logic

Choose whether to implement two-way or one-way synchronization based on your needs. Define how updates will flow between Tosca and Jira and set rules for conflict resolution.

Step 5: Configure execution settings
Set the sync frequency or define event triggers to control when updates happen. Define processing intervals to ensure timely data flow.

Step 6: Activate and monitor the integration

Start the integration process. Monitor synchronization status and use retry mechanisms to resolve any issues.

Book a demo slot to see OIM-led Tosca and Jira integration

Real-world scenario: QA and development teams working together

Without Tosca–Jira integration:

QA manually executes tests in Tosca
Bugs are logged in Jira manually
Status updates are shared via email.
Test coverage isn’t visible to development teams.

With Tosca–Jira two-way integration:

Test execution results in Tosca create or update Jira issues automatically.
Developers track defects directly in Jira, while status updates flow back to Tosca.
QA and development teams work with consistent data and avoid manual updates.

What makes bidirectional Tosca–Jira integration so valuable

Expected outcomes

No duplicate defect creation: Automatically update Jira issues with test results.
Visibility into test results in Jira: Get test coverage and defect status directly in Jira.
Consistent status across both systems: Ensure the most recent status updates are reflected in both Jira and Tosca.
Traceability: Maintain traceability links between test cases, defects, and requirements.

Warning signs to watch out for

Manual updates between tools: When updates require manual input between systems.
Inconsistent test results: Missing or incomplete test result data between systems.
Broken links between test cases and defects: When relationships break during migration or sync.
Relying on spreadsheets or emails: If you are still using these methods to track testing and defects, it’s a sign that integration is lacking.

Conclusion

Tosca and Jira are essential for QA and development workflows, but when they operate in isolation, it leads to inefficiencies and missed opportunities. A real-time, two-way integration between Tosca and Jira ensures that test data, defects, and requirements are kept aligned, improving collaboration and reducing manual work.

When done right, integration becomes part of the workflow, not an added task. The result is a faster, more efficient development cycle with reliable, consistent data.

If you’ve set up Tosca–Jira integration before, what was harder-mapping test data or keeping everything in sync? Let’s talk.

When one company becomes two: The hidden engineering challenge behind Azure DevOps restructuring in 2026

Dr. Ankita Mehta — Tue, 19 May 2026 04:28:07 +0000

Corporate restructuring usually gets discussed in terms of finance, leadership, legal entities, or branding.

What rarely gets attention is the operational reality engineering teams face when one organization suddenly becomes two.

Because splitting a business also means splitting delivery pipelines, work management structures, sprint histories, traceability links, test assets, repositories, workflows, permissions, and years of institutional knowledge embedded inside engineering systems.

And unlike a branding exercise, engineering restructuring cannot tolerate ambiguity.

If the wrong work items move to the wrong environment, teams lose visibility. If histories disappear, audits become harder. If dependencies break, delivery slows down. If downtime is introduced, development operations stall at the exact moment the business needs stability most.

This is where enterprise restructuring becomes a systems engineering problem.

A recent restructuring initiative at Vistrue illustrates this challenge clearly.

The problem nobody talks about in enterprise restructuring

As part of a strategic business transformation, Vistrue split into two independent entities:

Vistrue
Transcendent

This was not just an organizational separation.

It required a complete bifurcation of Azure DevOps environments so both companies could operate independently without inheriting irrelevant data, workflows, or engineering noise from each other.

At first glance, this may sound straightforward:

“Just move the projects.”

But Azure DevOps environments are deeply interconnected ecosystems.

The challenge was not moving data.
The challenge was separating years of operational complexity without breaking delivery continuity.

The migration involved:

Work items
User stories
Bugs
Tasks
Meta entities
Project templates
Workflow states
Custom fields
Histories
Attachments
Relationships
Dependencies
Area paths
Revision chains
And all of it had to be divided accurately between two future organizations.

Why restructuring migrations are fundamentally different

Most migration discussions focus on moving from one platform to another:

Jira to Azure DevOps
TFS to Azure DevOps
Server to Cloud

But restructuring migrations are different. The challenge is not replacing a platform. The challenge is selectively separating operational reality.
That creates a very different set of engineering requirements:

1. The migration cannot behave like a bulk export

In restructuring scenarios, not everything should move everywhere.

Some work items belong to one future organization.
Some belong to another.
Some dependencies must remain connected.
Some overlap is intentional.
Most overlap is dangerous.

This requires highly granular migration logic.

In Vistrue’s case, work items had to be divided based on area paths so each organization inherited only the data relevant to its operational structure. That sounds simple conceptually.

In practice, it becomes extremely difficult once years of revisions, links, parent-child relationships, comments, and attachments are involved.

2. Downtime becomes unacceptable

Most organizations can tolerate inconvenience during a migration.
Restructuring projects usually cannot. Business operations are already under stress during organizational separation:

Teams are shifting,
Ownership models are changing,
Reporting structures evolve,
Delivery expectations remain unchanged.

Freezing engineering systems during this process introduces operational risk at the worst possible time. Vistrue needed the migration completed without disrupting ongoing work. That requirement immediately eliminates many traditional migration approaches.

3. Scale exposes architectural weaknesses

Migration discussions often underestimate what happens at scale.
Moving a few hundred work items is easy. Migrating years of enterprise delivery history while preserving:

Revisions,
Attachments,
Dependencies,
Hierarchy,
Workflow integrity,
and traceability

The architectural shift enterprises are making

One interesting trend becoming increasingly visible in enterprise engineering is this:

Organizations no longer treat ALM migration as a one-time administrative exercise. They now treat it as infrastructure transformation. That changes how migrations are evaluated.

The questions become:

Can teams continue working during migration?
Can data fidelity be preserved at scale?
Can restructuring logic be applied dynamically?
Can migration execution run in parallel?
Can the system recover safely from failures?
Can operational continuity remain intact?

These are architectural questions, not import-export questions.

How Vistrue approached the restructuring

To execute the restructuring, Vistrue used OpsHub Migrator for Microsoft Azure DevOps (OM4ADO), referred through partner collaboration with CDW.

The migration strategy focused on three priorities:

Preserve operational continuity,
Segment data accurately,
Accelerate execution without compromising integrity.

Instead of processing migration serially, Vistrue deployed four service users across source and target Azure DevOps organizations. This enabled parallel migration execution.

Each service user handled a specific batch of work items independently, significantly reducing migration timelines while maintaining segmentation control. This matters because enterprise migration bottlenecks are often not caused by tooling limitations alone. They are caused by sequential processing architectures. Parallelization changes the economics of migration execution.

What actually determines migration success
Many migration projects are evaluated only by whether data appears in the target system. That is an extremely low bar. In reality, enterprise migration success depends on four things:
1. Data fidelity
Did the migration preserve:

Revision history,
Comments,
Attachments,
Relationships,
Dependencies,
and traceability?

Or did the target system merely receive flattened records?

Vistrue preserved complete work item fidelity throughout the restructuring.

2. Operational continuity

Could teams continue delivery during migration?
Or did engineering operations pause while administrators executed backend transfers? The migration occurred without business disruption.

3. Segmentation accuracy
Did the right data land in the right organization? This becomes especially important during divestitures, acquisitions, and organizational splits where accidental data inheritance creates governance and operational risks.

Area path-based filtering helped ensure accurate organizational separation.

4. Execution efficiency

Could the migration complete within realistic restructuring timelines?
Enterprise restructuring initiatives rarely allow unlimited migration windows. Parallel processing significantly accelerated transfer execution for Vistrue.

The bigger lesson for engineering leaders

Enterprise engineering ecosystems were not originally designed for organizational restructuring. But restructuring is becoming increasingly common:

Mergers,
Acquisitions,
Divestitures,
Business unit separations,
Cloud transformations,
Regional operating splits,
Platform consolidations.

As a result, engineering leaders are being forced to rethink migration architecture itself.

The old model:

“Export data. Import data. Hope nothing breaks.” It does not survive enterprise-scale operational change anymore.
Modern restructuring requires migration systems capable of:

Selective segmentation,
High-fidelity transfer,
Parallel execution,
Operational continuity,
and governance preservation. Because the real challenge is not moving data. The real challenge is preserving organizational intelligence while the organization itself changes shape.

Final thoughts

Vistrue’s restructuring highlights something many enterprises eventually discover:

Engineering systems are not passive repositories.
They are living operational environments.
When organizations restructure, these systems must evolve with precision.
Done poorly, migrations create fragmentation, operational drag, and delivery instability.
Done correctly, they become invisible infrastructure transitions that allow the business to evolve without disrupting engineering execution.

And increasingly, that distinction is becoming a competitive advantage.

Restructuring your engineering ecosystem without disrupting delivery requires more than data transfer. It requires architectural precision. Let's discuss how OpsHub Migrator for Azure DevOps (OM4ADO) can help you execute high-fidelity Azure DevOps migrations, consolidations, and organizational splits without downtime.

How a global leasing company migrated from TFS 2018 to TFS 2020 without downtime or data loss (2026)

Dr. Ankita Mehta — Mon, 04 May 2026 04:04:11 +0000

Upgrading DevOps systems sounds simple. Until the system you’re replacing is still in active use.

A global financial leasing company operating across 50+ countries faced this exact problem. Teams were working on TFS 2018, while Azure DevOps Server 2020 was already set up as the destination.

This wasn’t just a migration. It was a transition that couldn’t afford to pause. The constraint most migrations ignore

The trigger for the migration was simple:

TFS 2018 was being retired
Azure DevOps Server 2020 was already in place

But the constraint changed everything:

Teams were still actively working in TFS.

This meant:

No downtime
No disruption
No data gaps. No confusion during transition

Most migrations don’t fail because data can’t be moved.
They fail because work cannot pause while data is being moved.

What was actually at risk

The legacy system wasn’t just a backlog.

It contained:

~5000 work items
~30,000 revisions
~15 GB of TFVC source code
~5000 changesets

That’s not just data.

That’s:

History
Traceability
Data richness

Lose any of it, and the new system becomes harder to trust than the old one.

Why a simple “lift and shift” wouldn’t work

A one-time migration would have created problems immediately:

Teams would lose access during cutover
Updates made during migration would be lost
New item IDs would break continuity
Users wouldn’t know how old work maps to new work

So the goal wasn’t migration. It was operational continuity during migration.

The approach: move everything, pause nothing.

Instead of treating migration as a single event, the team approached it as a controlled transition using OpsHub Migrator for Microsoft Azure DevOps (OM4ADO)

The focus was clear:

Keep systems usable during migration
Preserve every piece of history
Reduce confusion for users

What actually made the difference

1. No downtime during migration

Teams continued working in the existing system while data was being moved.

No freeze. No productivity drop.

2. Full history preservation

Work items were migrated with:

All revisions
Complete history
Linked information

Nothing had to be reconstructed later.

3. Source code moved with continuity

TFVC source code and changesets were migrated along with work items.

This ensured that:

Development history stayed intact
References remained meaningful

4. Original ticket references were retained
A small but critical decision

Original ticket numbers were added to new items

This solved a very real problem:

“Where did my work go?”

Instead of forcing users to relearn IDs, the system preserved familiarity.

5. Continuous support during migration

This wasn’t a “run and forget” migration.

Issues were handled as they appeared
Adjustments were made in real time
Teams were supported throughout
What changed after the migration

The visible change was simple:

Everything moved to Azure DevOps Server 2020.

The real impact was deeper

Teams finally worked in one place
Development, IT, and management teams aligned on a single system.
Data became reliable again
No duplication. No mismatch. No missing history.
Reporting improved

With unified data, reporting reflected reality instead of stitched views.

Decision-making became faster
Stakeholders had access to complete, consistent information.

What this case actually teaches

This wasn’t a complex migration story. It was a disciplined one.

1. Migration is not a data problem

It’s a continuity problem.

2. History is not optional
Without it:

Audits break
Debugging slows
Decisions lose context

3. Small details reduce big confusion

Preserving original ticket references is not a technical feature.
It’s a usability decision.

4. Downtime is not always required

With the right approach, systems can transition without stopping work.

If you’re planning something similar

Ask these questions early:

Can teams continue working during migration?
How will history be preserved?
How will users map old work to new work?
What happens to updates made during migration?

If you don’t answer these, migration becomes a mere cleanup.

Conclusion

Most teams think migration ends when data is moved.
In reality, it ends when:

Teams trust the new system
Work continues without friction
Nothing feels “lost”

That’s a much higher bar.

And that’s what this migration got right.

A practical note

For migrations involving TFS to TFS, TFS to Azure DevOps (ADO), ADO to ADO, merge multiple ADO instances, active source systems, large datasets, and strict continuity requirements, structured migration tools like OpsHub Migrator for Microsoft Azure DevOps (OM4ADO) co-built with Microsoft are often used to manage the transition without disrupting ongoing work.

If you’re exploring similar TFS upgrades, it can be useful to see how other teams have approached it. Here’s a real example of a migration from an older TFS version to a newer setup.

I wrote this piece because most migration stories focus on tools, not what actually breaks during the transition. In reality, the hardest part is keeping work moving while everything underneath is changing.

If you’re dealing with a similar migration, I’d love to hear how you’re approaching it.

How are you handling active work during migration?
What’s been the hardest part for your team?
Are you prioritizing speed, continuity, or data completeness?

Drop your thoughts or questions in the comments. Always interesting to see how different teams solve the same problem.