Hmm, having been a manager I have two immediate "knee-jerk" reactions to this:
- If you don't already have good reasons why are you pitching git other than to be trendy?
- Similarly, how is Subversion failing such that you need a replacement?
I'm not, actually, being negative - I think there probably is a case to be made (dependent on circumstance) but if the case is simply that git is "better" than subversion then you don't really have one.
You also need to be able to enumerate the disadvantages - you've already identified the overhead of migration and re-tooling - what else is a problem? e.g. What happens to your nice, central, backed up repository? How do you integrate with your continuous integration build server (if you don't have one, forget git and go sort that first). Oh security and tracking - SVN runs with proper logins and permissions.
To my mind, the benefits are in flexibility, better merging, the ability to do local commits without breaking the build and so on. The disadvantages are in lack of control and that same flexibility.
It may be that all you want to do is run git locally to your machine as a "better" subversion client (I'm looking at doing this using mercurial).
Hmm, perhaps this whole answer is a comment really? You need to make your case here (in the question) for git over subversion (in your environment) in order to see if we can help you identify the business case.
FWIW, I'm know that one can easily designate a specific instance of the repository to be the trunk/reference source and further that that is how one wires into one's build server - the difference being that with DVCS that's more of an administrative decision than something inherent in the architecture.