Note that FxCop is very customisable with regards to the rules you wish to apply. You may find it works best by incrementally introducing it; only for a certain set of rules for a certain set of files, or even excluding all legacy files initially.
There are bound to be rules that you may never activate because they just do not suit your problem domain. And remember that if a piece of code 'breaks a rule' for a specific purpose, there is an attribute to mark such code as acceptable, although I would instate a rule that all such overrides must use the Justification
property on the attribute to indicate why.
Finally, as much as the built-in rules will help a lot with improving code quality, the really big wins are to be had in custom rules that will allow you to check for company conventions. If you do not automate your 'peer review' in this fashion, then you cannot really guarantee compliance.
I use FxCop as an integrated part of the build system at work, and our common libraries currently get released with all rules enabled with minimal attribute overrides, and it has been worthwhile in more than a few places.