Java EE 7 migration: Risk mitigation strategies

With Java EE 7 scheduled for rollout in the 3rd quarter of 2012, enterprise developers are already considering if and when they should migrate to the newer version. The Java EE platform is known for its incremental development and improvement. New releases aren’t necessarily groundbreaking or flashy. Instead, they often represent maturation of the existing technology. This means users of older versions may consider their version perfectly adequate even if there’s a newer release available.

For example, respondents to TheServerside.com Readership Survey 2011 consider both EE 5 and EE 6 to be “current” versions of the EE platform since both offer basically equivalent capabilities for application development. Many organizations aren’t having significant issues with older versions. Others have already spent the time and energy to find workarounds for known problems. So, it’s not surprising that they don’t feel a pressing need to upgrade every time Oracle makes a big announcement about a new product.

Will Java EE 7 be different?

There will be changes in EE 7 that could catch the interest of some enterprise users. A standardized caching API and a modularization API are being added. But the most talked about upgrade is improvement in cloud support and integration. Java EE 7 assumes that enterprises are poised to make a move en masse to embrace the PaaS model. The cloud is certainly becoming a more popular tool for large businesses.

However, some detractors point out that a focus on certain issues like multi-tenancy are misguided since it’s the private cloud and not the public cloud that is getting the most love from enterprise level businesses these days. That being said, some in the Java community already view EE as woefully behind in the development race. An upgrade that ignored the requirements of the cloud environment would certainly be seen as yet another version that presents new features that are “too little, too late”.

Organizations may trickle rather than rush to adopt Java EE 7

Enterprises that are currently using PaaS or planning to migrate are most likely to be attracted to this newest version. Other firms may continue to hold back. It’s not actually because they lack faith in the latest release. Java EE is a respected technology – perhaps partly because Oracle does show caution in rolling out significant changes. Let’s take a look at some of the most commonly cited reasons why enterprise users say they may delay adoption.

1. Time required to perform backwards compatibility testing
   30% of respondents expressed concern over the resources that would have to be committed to this aspect of an upgrade. When you adopt a new version, there are several potential outcomes. Best case scenario, you can still use all the assets created previously. Usually, there will be some tweaking necessary to migrate successfully. Worst case, you miss something and software that used to function just fine breaks down catastrophically.
   
2. Time required to investigate the latest release
   This reason ties in to #1 because actually taking the time to fully explore a new release is absolutely necessary for determining what types of compatibility testing are needed. Otherwise, it’s impossible to assess the risks involved. A busy CIO or IT manager who is juggling multiple projects isn’t likely to feel a compelling need to investigate an upgrade if everything is already working fine. That leads us to reason #3
   
3. No need to switch
   As mentioned at the start of this article, the older versions of Java EE are working fine for plenty of companies. The risk of not upgrading seems low compared to the risk of upgrading and having something go wrong. After all, no one outside of IT is even likely to notice when applications are running smoothly. In that situation, moving forward with the latest version violates the prime directive of IT management “If it ain’t broke, don’t fix it.”

Other issues that are likely to slow the acceptance of Java EE 7 include lack of buy-in from management and heel-dragging from vendors in releasing products that implement the latest release.

Risk mitigation strategies

What can businesses do to make the migration to Java EE 7 less risky? Actually, waiting to jump on the latest EE version bandwagon until it has some time to prove itself is not a bad idea. The wait and see approach provides an opportunity for others to discover any bugs with the new version. There will always be more intrepid users who take the plunge and blog about it for the rest of the enterprise population.

Staying in the discussion during the pre-rollout phase is another good risk mitigation strategy. It’s a lot easier to make a decision about if/when to upgrade when you know what’s going on leading up to the release. Potential conflicts and poor decisions on the part of the designers are often easy to spot long before the version is released. The role of monitoring industry publications and relevant forums can actually be delegated to an IT team member so the IT executive just gets the “executive summary” about what’s going on when it’s relevant to the decision making process.

What if the upgrade process has the potential to be beneficial but inertia is still holding your company back? One way to overcome this obstacle is by bundling the Java EE 7 migration with another project. For example, if there’s a cloud development or migration project in the works, that’s a valid reason to dedicate some resources to a Java upgrade as well. This can add to the overall complexity of due diligence and testing. But once it’s done, there’s more to show for it.