The first question to ask is "Is the version of Java supported on the machine?" While updating the JRE is one thing, it may be that the underlying OS is not supported running the new version of Java (supported certifications and support contracts and the like that many enterprise environments like to have).
Many java production environments are actually running on top of an application server. This would be the next consideration. Wikipedia comparison of Java EE App Servers shows what version of Java EE is supported. This can be further seen in Oracle's JavaEE compatibility overview. The tested configuration for JBoss Enterprise Application Platform 6 is against Java SE 6.0 update 6u30. Java SE 6.0 update 6u30 is also the tested configuration for JBoss Application Server 7.1.0 Final. These may work in Java 7, but they are not tested configurations.
Expanding on the application server, there are live code analysis tools that are used to do debug after the fact. Omniscient Debugger (see also) and Dynatrace are two examples of this. These applications work by instrumenting (modifying) the live byte code of java running to report back to it. As these applications work by modifying the byte code, if the byte code changes in a way they are not capable of working with (such as in a new JRE), they won't work.
Next down the line is the frameworks. One example of this is JAXB that comes with java and Spring which uses it. Changing to Java 7 updated JAXB which generated code that was incompatible with some frameworks (which requires them to be updated and their dependencies would need to be updated...).
Build tools are next on the list. One would need to make sure that the build environment is using the proper version of Java. Writing code for Java 7 but not updating the version that Maven or Ant uses would then cause problems. There are times when the build tools themselves are strongly tied to one version with particular plugins.
Testing tools. Things such as PMD, findbugs, and checkstyle may not recognize new structures in a new version of Java - these may get very confused with string switch statements or compound catches. Tools that get into instrumentation such as code coverage may not work in the new JVM. In the context of Java 7, Cobertura and Emma have not been updated to the new JRE (again, these applications modify the byte code to see which code is run and which isn't) (see open source code coverage libraries for jdk7). This could require a change to the build scripts to switch from one to another.
Then there is the IDE. One would need to update the IDE to a version that is aware of the new structures in the language. Eclipse's announcement of support for Java 7 shows these issues.
Last and certainly not least is the developer. It is up to the developer to write the new code and be aware of how code can be restructured. Going from Java 1.4 to 1.5, templates and annotations were introduced and it took time for the developers to get into the mindset of the new structures available. Likewise the collections rework back in 1.2 and getting developers away from using HashTable and Vector. Updating the version should be accompanied with some amount of training in the new language structures.