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

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.

DEV Community: Dr. Ankita Mehta

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

What was actually at risk

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

The focus was clear:

What actually made the difference