Convincing customers to upgrade to Java 5

We sell packaged Java web applications to some of our customers. It's basically a collection of servlets, some SOAP web service and some static resources. We don't do EJB nor any other Java Enterprise fancy stuff.

Some of our clients are running IBM WebSphere Application Server v5.1, hence we are limited to Java 1.4 for the run-time and the development. Of course, we would like to do our development using Java 5 (or even better Java 6). Doing SOAP in 1.4 requires an external lib (we use AXIS, but it's aging). We can't use enum, boxing, generics... It's becoming harder to find 1.4 compliant third-party libraries.

The customers are currently satisfied with this old-but-working-well setup. We would like them to upgrade their Java run-time. In开发者_StackOverflow this case, it means upgrading to IBM WAS 6.1 or 7.0?

What can we tell them? What's in it for them?

So far I've got:

1. Better performance as JVM is much more efficient in Java 5 (even better with Java 6). I can't put figures on it, though. Not sure if IBM VM has improved a lot (one of our client is running on AIX).
2. Support. IBM WAS 5.1 can only be supported through special extended support programs.

They are big corporations, so they plan their solutions more than a year in advance. They select a mature product today and they deploy it years later. The product then has a few months before being end-of-life.

See IBM WebSphere Application Server comparison

Java 1.5 has reached end of life November 3, 2009.

So neither 1.4 nor 1.5 are supported any longer which means no security fixes.

So basically the only supported Java platform currently is Java6 (aka Java 1.6)

You could tell them the costs of their decision.

If they continue to choose Java 1.4 then adding a new feature will cost $yyy. If they upgrade then adding the same feature would cost $xxx. Presumably they also have a cost of upgrading their systems. If you can show them that the savings on the newer version of Java exceed the cost for them of upgrading their system then they can see that they will save money if they upgrade.

Obviously it is difficult to give exact values for the development costs, but if you can estimate that development would go for example roughly 30% faster (and therefore be 30% cheaper) on a newer version of Java then you can get a rough figure at least.

First of all, the only SDK that is supported with a given version of WAS is the SDK that actually ships with the product (in other words, IBM won't support running WAS on another JDK, if this matters).

Secondly, WAS might actually not even start with a more recent version of the SDK (WAS 6.1 won't start with IBM JDK 1.6 for example).

• WAS 5.1: J2EE 1.3, JDK 1.4.2
• WAS 6.0: J2EE 1.4, JDK 1.4.2
• WAS 6.1: J2EE 1.4, JDK 1.5
• WAS 7.0: J2EE 1.5, JDK 1.6

So requiring a more recent runtime will probably be synonym of big migration: qualification of the JDK and application server, training of admins, migration of platforms, migration of applications, update of monitoring, deployment tools, regression testing, etc. This is generally a complex and extremely slow process with big conservative companies.

In your case, you could maybe consider branching your software and offer different versions and:

• only do maintenance on the old version
  • and define an EOL date for the old versions (you can't maintain it Ad Vitam Aeternam)
• offer new features on the new version only
• offer more aggressive pricing on the new version

There must be a good reason for your customers to adopt a newer version and it must out-weight the cost of a migration.

You're in business to satisfy your customers. They have a need (be it real or perceived) to stick with an obsolete platform.

So, say "yes," but let them know you plan to increase your maintenance and upgrade prices for the old platform on a date certain. This is a perfectly justified price increase; you need to maintain expertise and equipment to make sure your code works on an old, unsupported, and conceivably insecure platform. You're delivering real value to them by supporting their current infrastructure.

And be happy you're not in the diesel engine business. If you were, you'd have plenty of customers with world-war-ii era technology.

Been there... Clients can be stubborn. I have used RetroTranslator(http://retrotranslator.sourceforge.net/) and Retroweaver(http://retroweaver.sourceforge.net/) to have Java 5 features. Nothing can be done on the performance side though.

As for Java 1.5/1.4 EOL there is Java for Business program for Java customers - they are not EOL if you pay for them...

Tell them about security. I'm not sure if sun still deliver patches for older versions (pavanlimo answer).

While I agree with the other answers given, another consideration is have you considered there situation? Have you written the application in such a way that it plays well with others? I've been a system admin for a while now and one of my biggest gripes is the number of development houses that think that we should change our IT environment when they are ready. And of course if there are 2 or more such development houses supplying products to my site then there is conflict.

Have you written your app in such a manner that I could run your choice of Java version and the (pick your number but its likely to be greater than 2) other versions of Java that I require, usually on the same server, to support the other equally important applications? And suggesting backward compatibility is irrelevant - the other vendor will not support me unless I'm on their chosen version.

Perhaps because Java 1.4 has reached EOL on 30th Oct 2008. And so, their security can be compromised!.

Show a couple of examples, where, security has actually been compromised due to Java 1.4.

They will be sufficiently scared IMO.

Why not go to java 6? Both java 1.4 and java 5 have reached their end of life.