Functionality

Just like there is no fighting city hall, there is no use discussing whether deprecating a feature is a good idea. While I may personally become annoyed by a feature missing that I used all the time, there is almost always a better way that will be just as useful once I read up on it. And it is much more likely that I never even knew the feature was there in the first place and won't even know that it changed. I have web applications that I wrote in 2000 that deploy seamlessly to the last servlet containers. I have also consulted on projects where everything came to a screeching halt in a dot release upgrade, which is why it is a good idea to have your development team review the deprecated list if you are not strongly compelled to upgrade. While every WebLogic Server administrators I have met has been both brilliant and charming, they generally have no need to know what low-level APIs the application development team relied on to get into production on a tight schedule.

This does not necessitate upgrading to 10.3. You have the option to not upgrade at all if your current version serves all of your needs. Or you could upgrade to a version lower than 10.3. If your current version is at EOL and none of the first eight items have you the least big excited, staying where you are would make the most sense. Sure, there is 99% chance that you will eventually have to upgrade, but at this point in your application's you may end up upgrading twice if you do not have any great incentive to do so now.

If you are considering upgrading just to continue receiving support, I would highly recommend reviewing your application roadmap to determine if it makes more sense to go for the latest version or just far enough up the version tree so that support and application retirement coincide. While support retirement, once published, rarely gets postponed, the planned decommissioning or upgrading of a custom application deployed to a J2EE application server frequently does get put off. Be careful that a stop-gap upgrade does not cause you to do more of the same each time a version comes to EOL or you will feel like you are bailing out a boat with a Hula Hoop.

I am not a proponent of upgrading for the sake of upgrading, though I do believe that we are still in a period of Information Technology history where the need to upgrade is a fact of life. The important thing is choosing when to upgrade, because the bottom line is ROI, especially in the current economic climate. Most of the ten points discussed in this article could be the deciding factor to upgrade singly for some applications. For other applications, even a 9 out of 10 may not be enough reason to upgrade yet.