You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking for guidance: TFS/ADO Server → Azure DevOps Services
Hi all,
We’re currently migrating two TFS collections and one ADO Server collection. We’ve had good success consolidating into ADO Server using nkdAgility tools.
Now we’ve been asked to move everything to Azure DevOps Services, ideally using the inherited process model.
We’ve tried some manual recreation and partial migrations, but we’re running into challenges:
Global lists vs picklists (especially shared across projects)
Project-specific lists tied to common fields
Test case migration (no ReflectedWorkItemID)
Fields that rely on calculations
From what I’ve read, it sounds like collection import might be the only way to preserve fidelity—but that would leave us with multiple orgs, which we’re trying to avoid.
Project-based migrations feel pretty lossy, even with good tooling.
Am I missing an approach here, or is this a trade-off between fidelity vs modernization?
Any guidance or lessons learned would be appreciated.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Looking for guidance: TFS/ADO Server → Azure DevOps Services
Hi all,
We’re currently migrating two TFS collections and one ADO Server collection. We’ve had good success consolidating into ADO Server using nkdAgility tools.
Now we’ve been asked to move everything to Azure DevOps Services, ideally using the inherited process model.
We’ve tried some manual recreation and partial migrations, but we’re running into challenges:
ReflectedWorkItemID)From what I’ve read, it sounds like collection import might be the only way to preserve fidelity—but that would leave us with multiple orgs, which we’re trying to avoid.
Project-based migrations feel pretty lossy, even with good tooling.
Am I missing an approach here, or is this a trade-off between fidelity vs modernization?
Any guidance or lessons learned would be appreciated.
Post/References reviewed so far:
References
Thanks,
Troy
Beta Was this translation helpful? Give feedback.
All reactions