The issue holding most serious projects back is MSVC's historic lack of support for C++11 (and now 14/17) features. Thankfully, it looks like this is starting to change with MSVC 15 [0].
As an anecdote, the (very large) project I work on at $DAYJOB is finally moving from C++03 to C++11 in the next few weeks.
If your employer won't use provably stable and almost entirely backwards compatible language improvements, you might want to just find another job. C++ is a hard enough language that someone out there will be willing to be sane about the language version they use.
I know I'd only touch 20 year old C++ code with the go-ahead to refactor it into C++14. I'd argue that not adopting smart pointers, standard threads and mutexes, and auto type deduction make projects effectively unmaintainable at sufficient scale.
Back in 2005 my employer decided it was about time to move away from C++ in enterprise projects.
Actually in most of the enterprise projects I have been involved, C++ tends to be restrained to bindings to some feature not exposed in the chosen languages.
Changing employer doesn't matter, as most of these decisions come from the customers themselves.
It might work for in-house products, not so well when doing consulting.
As an anecdote, the (very large) project I work on at $DAYJOB is finally moving from C++03 to C++11 in the next few weeks.
[0] - http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17...