Firstly, Linux as the new platform is not that big of a problem. Java is based on the JVM which does a pretty good job on hiding the system and the hardware. If you need to dig into the OS, than neither Java nor C# are the language of choice in my opinion. It's much like developing PHP. You can do it with a webserver on both Linux and Windows, and in almost all cases there aren't any differences during runtime due to the system it's deployed on.
When you are developing web applications with Java, especially enterprise web applications, you'll probably use Java EE, so you'll have to use a container for it (JBoss, WebSphere, GlassFish, etc.). These can be run on Windows or Linux, it doesn't matter. Our production systems here use Red Hat Enterprise Linux with JBoss, while most developers have Windows 7 systems and this inhomogeneity never caused any trouble.
Switching to Java from C# isn't really complicated, too. The languages are quite similar in most aspects. You'll really miss some features like Properties and LINQ, but this is really a minor concern.
A much bigger concern are the APIs. Java and J2EE done right differs quite a lot from the .NET (web-)technologies. You should put serious effort into learning JPA and EJB best practices (if you are using Java EE, that is, JPA can also run standalone). I also advice to use EJB 3.0 as the pervious versions are totally overengineered and now have been simplified. Sadly, most Java development these days is still a venture through the XML-Hell. Although convention over configuration has been put into place in the newest releases of most APIs, there's still a lot of XML to write. This is especially true to web-development (JSF for example). Please note that in this context I am talking about configuration issues and not about declarative UI development.
As far as web-technologies are concerned, I'd advice you not to use JSF (which is propagated as a standard), as it is complicated and overengineered. It might get better with the next releases. I'd rather use Apache Wicket or Tapestry, which will save you a lot of headaches, especially if you'll have the need for custom user controls or rich clientside scripts.
As for the interoperability: If the existing services are coded against industry standards (REST/SOAP) then you probably have no problem consuming them with .NET. However, if you'll have to use existing libraries and modules, then it's probably better to use Java, in order to keep reuseability high (DRY) and for the sake of homogeneity.
My advice is to keep the environment of the customer clean. Use Java, the language switch isn't that complicated. Train on the APIs you want to use extensively. I know developers are going to swear, because they'll be missing LINQ, and because they'll be writing a little more boilerplate code, but you can definitely transfer lots of experience (especially on the modelling part) to the new environment.
Regarding the APIs of choice, some people (@TMN for example, thanks for pointing it out) suggest to skip EJB altogether and to adopt Spring Framework and Hibernate. Hibernate can also be used as a JPA provider. This is certainly not bad advice.