I do not see why you were downvoted. I earn my living writing C++ for a living for mission critical CAD applications and I cannot imagine me or any one of my colleagues use an automatic converter.
C++11 is nice. For new code. I see no reason to use this for old, working code.
This whole "automatic converter" thing is a bit of a straw man. The libraries used by clang-modernize and clang-format are the same clang uses to "work" with your code. If you don't trust them then you've pretty much lost anyway.
What you get out of it is extra performance — that's it, really.
I was actually (I think) the first reference customer of the tooling libraries underneath clang-modernize and clang-format inside Google, and worked with Chandler and Manuel to get a proof of concept out in December 2010. My code was long gone long before it was upstreamed to the open-source Clang project, and was really just a barely-working prototype. It was promising enough (and encouraging enough that an outside engineer from Search had personally invested time in writing it) to get the project staffed up as an actual Google project, though.
The real reason we wanted it was because we had just redesigned the search page entirely [1] and launched Google Instant [2], and the former was launched to "Everything except for IE6 and RTL languages", the latter was launched to "Modern browsers that can handle the performance requirements, if the user has turned it on", and the resulting combination of conditional branches in the code made it virtually impossible to launch anything else. I was leading a short mini-project to get the new interface launched everywhere and clean up all of the dead code paths that had only serviced the old Google interface.
Simultaneously, Chandler and Manuel had come up with this library to do pattern-matching on top of the Clang AST, and they were looking for a reference customer or at least some reason to exist as a project. So they were like "Let us help you with that - we can let you write tools that will fix your 1000+ conditional branches automatically."
Ironically, my project actually failed. (At least the part where we used automated tools to remove dead code - we did succeed in launching the new interface everywhere, so it was considered a success by management). The old code was removed manually by engineers over the next 2 years. But what it did show was that a.) there was demand for these automated refactoring tools inside the company and b.) the primary blocker to effectively writing these tools was the need to reformat source code as you add or remove expressions, which is why clang-format was developed.
clang-format is actually my favourite out of the two. I never had a real use case for clang-modernize (I did try it once though; just to see the magic happen). clang-format however impresses me pretty much every day. It doesn't really do anything Go's "fmt" command can't do, but it just looks so much more impressive given C++'s complex syntax.
C++11 is nice. For new code. I see no reason to use this for old, working code.