My belief is that the best path would be:
Phase 0: This is how we are now. We have SVN master (trunk), and a read-only git mirror, and a semi-updated github mirror for when a contributor really wants to submit git PRs.
Phase 1: Switch to using Git with PRs for submitting patches (Github's PR system is really really nice these days, but other solutions exist). Setup a SVN mirror "bot" that creates one svn commit for each push/merge detected in the master branch, and allows the buildbots to continue working as they do now.
This would allow the existing svn-patch workflow to continue working, but commits on svn wouldn't be allowed anymore. Developers are expected to at least TRY to learn to use git (it's not that hard! I promise!).
Phase 2: We switch the buildbots and testbots to pull from git, enable testbot access for git PRs (such as with a github bot that responds to "@rosbot runtest" or similar). The SVN mirror remains, for archival purposes, but git commits aren't merged so regularly. Release tags/branches can still be published through SVN, for ease of access.
Phase 3: Everyone ends up agreeing that maintaining the svn mirror is no longer worth the effort.
Of course, anything like this will only happen if the entire team agrees to it.