Having multiple JREs on a system isn't in and of itself a risk, but the risk that they might be invoked by untrusted code is present.
So the key to this setup is likely to be ensuring that the outdated JREs can only be invoked by the application that you need it to and not by any untrusted code.
Exactly how you achieve this depends on the application that you need to allow the use of. If it's a thick client app then installing the outdated JRE in the applications home directory and ensuring that any environment variables (like JAVA_HOME) that direct programs to specific JREs are not pointing at it would help.
The most critical element in terms of likely risk is ensuring that the Java browser plugin for the vulnerable version is not exposed to the Internet. There are a large number of malicious sites/exploits which can attack that weakness, so it's one to avoid.
If your business app. needs the Java browser plugin then things get harder to do with less risk. Here I'd say your choices are either to ensure that the browser with the outdated Java plugin is only usable for access to the legacy application (e.g. force a proxy and set it to one that can't get to Internet based sites), or to provide a Virtual environment with the browser/Java plugin made available and again make sure that environment can't access the Internet.
With any of these solutions there is still a risk that an attacker will find a way to invoke the vulnerable JRE but by restricting the use of it, you can reduce the level of risk.