5
votes

We are planning migrating a big team project from TFS to Azure DevOps. TFS repository is classical TFVC and work item templates are customized CMMI templates. The requirement is to convert source code repository to git with history and to convert customized CMMI templates to Scrum work items when migrating. Also we are asked about possibility to keep relation between source code and work items. I have read lots of article and blogs. There are few tools and options like tfsmigrator, git-tfs, vsts-wi-migrator. But I couldn't understand that this requirement is feasible. Microsoft has even made a clean start and offers it as the first choice. I need comments/case stories of azure devops community .

2

2 Answers

5
votes

In theory, a lot is possible, but in practice, only a few people in the world I know of can perform the migration you're proposing. Martin Hinshelwood and David Corbin seem to specialize in these types of problems. I have quite a bit of experience, but I always seem to be able to weasel me out of a few of your key requirements as they're a lot of work, potentially expensive and almost never 100% possible.

If I'd have to do this I'd try to talk you out of a few of your requirements. I'd try to convince you to take the following path:

  • setup a clone of your TFS server to test this process on a couple of times.
  • On your current TFS use tools like witmorph to transform your CMMI template to scrum in-place. This is already quite a bit of work as there is no clear one-to-one path to take. And now that TFS allows in-place work item type changes, you may need to update witmorph to take advantage of these features.
  • Then migrate directly to Azure DevOps before even touching the sources.
  • Update your TFVC check-in comments to include the associated work item ids. You can use a similar script to this to iterate through all of the comments and update them with the #1234 work item ids.
  • Then use "Import from TFVC" to import the last 6 months from TFVC into Git.
  • keep the old TFVC repository around and make it read-only.

This way you get to keep your history. Full fidelity migration is not completely possible (TFVC just isn't Git and some things won't translate over). You get a reasonable amount of history in Git as well if you feel this is important. Your work items will remain linked to TFVC, since you've morphed them in-place their IDs won't change and re-linking isn't required. Given that you've updated the check-in description, the commits should also auto-associate to your existing work items.

Other things like builds, test results, releases will migrate over cleanly this way as well and you end up pretty close to what your target solution should look like.

3
votes

[Jesse - Thanks for the Kind words]

Yes, I do a lot of upgrades related to TFS with many of them being high-fidelity migrations to Azure DevOps.

As Jesse pointed out, TFVC is not Git - and there are fundamental conceptual differences. I firmly believe that both have their advantages (and limitations) rather than thinking of one as universally better than the other.

When it comes to history, accurately representing what was captured in one into the other is not practical. It is quite often better to keep the history in the original VCS and setup a clean environment for moving forward in the New.

Feel free to reach out to me directly: [email protected]