As it has been widely blogged, TFS Migration Toolkit pre-release version become available on 20th of April.
I have promptly downloaded it to have a quick look - after all, migration scenarios is fairly common occurence with TFS implementations, and so far there was not much one could do. But I'd say that the toolkit fell somewhat short of my expectations and here is why:
- It appears to be geared almost entorely to third party developers; if I am going to write commercial solution for Quality Center/TFS sync it certainly makes sense to try and use it. But I fail to see how average customer can benefit from that, or myself as the person implementing TFS - the complexity of writing migration utility appears to be significant
- The example of WSS converter is not something really helpful - of course that's my opinion only. I'd say most people are looking for migration of other version control/bug tracking systems to TFS or synching several TFS boxes rather than WSS solutions. So from my perspective, building an example for WSS that includes all quirks of WSS is not the best candidate for the task. One wants example to be relatively simple, and including WSS does not promote that cause. What about demonstrating power of toolkit on VSS, or ClearCase or BugZilla or Quality Center?
- I am a little unsure of DB usage in the toolkit. So I have to use MS SQL Server 2005; but I remember that license of MS SQL Server 2005 installed for TFS prohibits usage of it for other appplications. Would the toolkit be an exception? Or the license should be acquired? Express edition could be an answer, but certainly not for everyone.
But overall, I am pretty happy about that toolkit being released. At least now there is an alternative to writing things from scratch, and availability of source code will make things easier to understand (ever tried to tweak VSSConverter?).
1 comment:
No, the migration toolkit does not count as part of TFS, so you cannot use it on the specially-licensed SQL 2005.
We recommend using SQL Express. The metadata should not come anywhere near the 4GB limit even on a large migration. If you do several enterprise-sized migrations, you should probably create separate Express databases for them so they have room to grow during 2-way sync. (In that case you probably can afford a full version of SQL anyway).
Post a Comment