A large retailer using WebSphere Commerce 6 had failed in a previous migration to WebSphere Commerce 6.1. The retailer now needed new features found in WebSphere Commerce 7. TxMQ, an IBM Premier Business Partner, added two brand-new clustered WebSphere 7 environments. The result: TxMQ implemented WebSphere 7 and delivered twice the processing capacity using half the number of clustered servers with no downtime to operations.

A large retailer (the “client”) was using WebSphere Commerce 6 running clustered WebSphere Application Server (WAS) 6.0 and backend clustered services running WAS 6.0. Both WebSphere environments were on AIX 6. The frontend Commerce servers maintained the website, while the backend services performed shipping, email notifications, billing and inventory. The backend services also hosted a homegrown call-center application. The development environment staged 16 separate JVMs to manage disparate projects. The QA environment housed four clustered application servers in a three-tiered architecture that exactly mirrored production.

A previous migration to WebSphere 6.1 had failed and was subsequently abandoned. With the release of WebSphere Commerce 7, the client’s development team needed to utilize new features found in WebSphere Commerce 7. There was also no tolerance for downtime, whether it be in development or production. Automated deployment scripts were requested for each environment.

The key to project success was to analyze what had been unsuccessful in the past. From that initial conversation, TxMQ split the project by environment. The first environment was the client’s frontend WebSphere Commerce 6 environment. The second was the backend WAS services.
TxMQ attempted two separate approaches to tackle the frontend environment. The first approach was to migrate the Commerce 6.0 application into version 7 using the supplied IBM tools. When that failed, TxMQ went to the backup approach and installed WebSphere 7 on new, recently purchased hardware. The existing installation of WebSphere 6 was on old, about-to-be-retired hardware. While the original approach was to eventually migrate to the new hardware once WebSphere 7 was installed, TxMQ improvised and installed 7 only on the new hardware. This made it simple to maintain the requirement for downtime, because the team could build alongside the existing architecture. There was little to no downtime and testing proceeded smoothly without interruption to the legacy environment. Cutover was as simple as shutting off the legacy lpars.
Within the second environment, the application was a bit simpler than the Commerce. The IBM-supplied tools migrated that application successfully and TxMQ was able to successfully complete all tasks using the first approach of an in-place migration.
In hindsight, TxMQ would recommend the client perform a full reinstall of WebSphere 7 because of the significant changes to the SSL certificates between WebSphere 6 and 7. In order to re-enable security, TxMQ had to completely rebuild the client’s legacy certificates (that were transferred over by IBM tools). In a PMR to IBM, it was acknowledged that this was a flaw in the migration which resulted in corrupted security keys.

In summary, TxMQ added two brand-new clustered WebSphere 7 environments with little to no downtime to the client’s project schedule. The client’s development environment was perfectly mirrored from legacy and was switched with little to no impact to the existing schedule. Performance testing indicated that the client could run nearly twice the seasonal load on half of the usual hardware. Whereas the client could process 4,000 orders/hour with 8 clustered servers, the client could now process nearly 8,000 orders/hour with just 4 clustered servers.
TxMQ was able to provide extensive documentation on the installation process for both the backend and frontend environments. Additionally, TxMQ provided documentation for the deployment scripts, as well as updated architecture diagrams for both the deployment script and the new WebSphere 7.

Initially, TxMQ experienced problems with the 32-bit application – it would run out of memory due to excessive class loaders. The solution lay within a parameter buried deep in the infocenter that accepted a code to limit the number of classloaders.
WebSphere Commerce is caching-intensive. TxMQ executed a highly significant amount of performance-tuning around the dynacache settings. Some new distributed-object caching methods introduced in WebSphere 7 helped achieve greater order throughput. However, there was a need to rewrite the cachespec.xml to utilize these features.
While migrations were usually successful, in the end everybody agreed that a clean install was faster.
Photo courtesy of Flickr contributor David Precious