I moved quite a few tests recently. It depends on how many and what type of tests you re converting, and you didnt kill yourself giving us details. In general, I think its safe to assume that your average MSTest minded shop wont be massively Test Infected and thus wont have delved into each dark corner of MSTest.
All the Assert.* methods and the basic Test Attributes are simple find and replaces. The more rare ones, I d generally steer towards assessing each case individually. Unless you re already a xUnit.net expert, you ve got lots to learn and this will help you.
Also, usage of Assert.Fail isnt a simple transformation. The other thing is the transformation of TestClassInitialize to IUseFixture - simple to do, but hard to automate.
If people are using Test References, you won t be able to remove the reference to the MSTest assembly (and you ll still need to have VS on your build server - and it will continue to randomly fail on the Shadow taks, see my questions).
The biggest manual work for me was going through the 20 lines of boilerplate in a region at the top to see whether anyone actually used any of the custom attributes before deleting them.
The main thing that would have been a lot of work had it not been for a CodeRush template was converting ExpectedException to Assert.Throws. If you havent got CodeRush or ReSharper on this job, you d be stealing money from your employer.
