I have no idea where the industry is headed, but I feel rather confident that there will always be some group of people that will find some reason to look down on your codebase. If you rewrote the whole thing in state-of-the-art FP tonight, then by morning there will be some contingent of zealous logic programmers with their noses turnt up.
Don't worry about being looked down on. Worry about improving yourself as our field figures out how we can improve our craft. There's a lot of noise, which makes it hard to tell which things offer the most improvement, but knowledge is never a setback. You will never learn something new and be worse off than you were before. And learning something new doesn't require you to rewrite your codebase to use it, either—of course, you can if you so chose, but that's not a decision you can make until you've grokked the newness ;)
As for the difficulty of the transition: I didn't find it difficult, but I also had the luxury of time. I think it could potentially be difficult for someone thrown into the deep end (e.g., "go into the `hdom-canvas-draw` example and implement new features X, Y, and Z by Thursday!"). People often talk about FP being a different way of thinking about programming. That's true to some extent, but it's not entirely different from what you're used to. I think the thing that seems strangest for newcomers to FP isn't the way of thinking, it's the terminology. Names like `filter`, `map`, `mapcat`, `partition`, &c. seem odd and incomprehensible at first. But they're just operators, like `add`, `multiply`, `insert`, `append`. They're the kind of operator that make functional programming functional: they operate (at least in part) on functions.
If FP is something you want to learn, my advice is to start slow and simple. Some people can probably dive into that example code, tear it apart, figure out how it works, and learn that way. Perhaps I could if I were motivated enough, I don't know. What I do know is that I can't be arsed to do something like that. It's frustrating. Annoying. I have better things to do with my time.
The common advice is Abelson & Sussman's «Structure and Interpretation of Computer Programs», which is pretty good, though it has some problems. Felleisen & al. wrote «How to Design Programs» to address some problems with SICP, and wound up introducing even more problems. The choice between those two boils down to whether you want a book that addresses you like a 13-year-old with a good grasp of the infinitesimal calculus (SICP) or one that addresses you like an 11-year-old that barely understands elementary algebra (HtDP). Personally, I rather like Paulson's «ML for the Working Programmer», which assumes you're an adult who probably doesn't hold a degree in mathematics. Unfortunately, it's not freely available like the other two.
If you decide to go with SICP, I recommend using either MIT Scheme or Racket with sicp mode (you can install the mode through the menus in the DrRacket IDE). For MLftWP, I'd recommend using PolyML (any Standard ML implementation compatible with the revised definition will work fine, but PolyML is actively maintained and easy to set up).
From there, you should be pretty versed in the foundations of FP, and it's just a matter of practice to get comfortable. Of course, there will always be more to learn—the student may never rest :)
ETA - My best advice would be this: if you have the money and the time, read both the Paulson book and SICP; if you have the money but not the time, read the Paulson book; if you don't have the money, read SICP, which you can find in many formats on the Web (it's CC BY-SA licensed). I would not recommend HtDP to a professional programmer, and only maybe to a neophyte.