I can't answer this question without asking another question: why do you want to refactor your code base? You say you want to take advantage of the Java 8 runtime, but what does this mean?
If you have a code base using many anonymous classes that could be replaced with lambdas or method references, there could be a small benefit, in some cases. But I don't think you would ever notice the difference. Being functional is a great advantage in terms of safety, testability, and reusability, at the development stage. It often also leads to a much better architecture. But this does not mean that you can't write safe an easy to maintain programs, with a good architecture, in imperative programming. Writing good programs is difficult in imperative programing, but it is also difficult in functional programming. The main difference is that writing BAD programs is much easier in imperative programing, which leads many programmers into thinking that FP is more difficult. So you will gain the most by applying FP to average programmers, because very good programmers will most often write good programs, even imperative ones. (This is why I like functional programming so much!)
In any case, I would suggest not refactoring your code base if you don't need to. Just start applying functional principles to your new developments. When interfacing to legacy code, you will encounter some problems that you will be able to solve either by refactoring only as much as needed, or by implementing minimal functional wrappers around imperative libraries.
Another use case, regarding legacy code, is if you have to make it evolve. In such case, it might be better to rewrite some parts, and
you should take advantage of functional programming as much as possible. Otherwise, the only reason to rewrite imperative programs that works well into functional ones is fun. This might be a very good reason for programmers. Not sure you boss will appreciate it though!
And remember you don't have to change everything at first. Start by clearly separating functions (meaning functional methods) from effects. Insure referential transparency. Use final members as much as possible. Avoid closures by using additional parameters. This is a good start to write safer programs.
