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.
Top comments (0)