Migrate Off Java CAPS With Less Risk And Cost

I’ve spoken to many companies about moving from Java CAPS (or the predecessor SeeBeyond platform) to WebSphere. I thought I would share with you a little insight into how we approach these migrations in order to help organizations reduce the costs and risks associated with the replacement.

Why choose IBM connectivity solutions over Oracle?  Go here to learn why WebSphere is the smarter choice.

I won’t spend time discussing why there is a need to replace Java CAPS infrastructure (you can find a quick summary here).  Safe to say that anyone running this platform is likely to understand that it is imperative they develop and execute a roadmap to a new integration platform.  The problem most organizations face is that they have a significant investment in the existing platform in the form of code artifacts, the details of which are not necessarily well documented, that they are reluctant to lose.  Additionally, there is a concern with both costs and risks in order to replace the “plumbing” between  applications, a project that might at first glance be perceived as not delivering an immediate business benefit.  Our focus is primarily placed on helping customers make the move to WebSphere Message Broker, though there have been some cases where other WebSphere target platforms may make more sense depending on what version and parts of the Java CAPS software stack were in use (e.g., BPEL processes).  Here’s a video that outlines some of the key capabilities of WebSphere Message Broker:

We’ve understood these concerns and have developed both an approach to the migration as well as a set of tools that helps to preserve current investments.  The approach we take to migrating off Java CAPS (a no charge service offering – based on the WebLogic to WebSphere migration discussed here) consists of three basic steps – a Discovery, followed by a Migration Assessment, and then finally providing guidance, best practices, and support around the Full Migration.


Our team has developed a migration questionnaire we send to our client in advance of a scheduled Discovery call.  The questionnaire helps us gain a basic understanding of the existing environment, the scope of the integration applications that need to be migrated, a review of testing practices, as well as giving us a chance to review any documentation that exists for the implementation.  Next we meet with the client, typically via conference call, to review the responses and dig deeper into any areas where we need more information.  Use of the questionnaire helps make the Discovery call an efficient use of everyone’s time, and allows us to be very focused when the team arrives for the onsite Migration Assessment.  The output of this step is a basic understanding of the current infrastructure, an understanding of what a future state infrastructure needs to deliver, as well as identifying candidate areas for detailed investigation.

Migration Assessment

This step is where we dig into the details of the Java CAPS implementation.  Through the Discovery step we’ve typically identified some example code artifacts, such as OTD’s / ETD’s and Java Collaborations, that we can examine in detail. This step allows us to assess the applicability of our migration tools as well as identify any areas where manual effort needs to augment or replace what we can deliver through automated conversion.  The team will also conduct architectural and functional reviews of the system.  The output for this step is a full migration plan that includes a timeline with migration steps, level of effort, and a risk mitigation plan.  The team follows up the onsite portion of this work with a presentation of the findings and recommendations that include the migration plan deliverables outlined.

This step may be augmented with a proof of concept to migrate an example integration program to the target WebSphere environment.  This work helps to build confidence in your team around how the migration can take place, serving as an example for which to build your “migration factory”.  It also helps us to identify any specific issues with your artifacts, allowing us to further refine your migration plan.

Full Migration

Once the migration plan has been delivered, you are free to engage whatever resources you would like to use to conduct the full migration.  Some of our clients have chosen to use their own IT staff for the migration, others have engaged service delivery partners, and IBM has consulting services (IBM GBS or IBM Software Services for WebSphere) that can be used as needed.  In many cases our clients choose to use a blended approach in order to ensure they have the most efficient use of resources while also having the right expertise at the right time.

In any case, our Migration Team will stay engaged to relay their experience and answer questions as they arise.

In a future post I’ll provide some more information on the investment IBM has made developing tools to help automate the conversion of Java CAPS / SeeBeyond environments to WebSphere.  One of the recent developments we’ve had in this area is to add support for the conversion of Monk code, so anyone with an older e*Gate implementation can benefit from our tools investment as well.

Interested in learning more about how to migrate your Java CAPS environment to WebSphere?  Contact us at whywebsphere@gmail.com.

Categories: Migration

Tags: ,

3 replies


  1. Migrate Off Java CAPS With Less Risk And Cost | Smarter Questions for a Smarter Planet
  2. Software Migrations Made Easy | Why WebSphere? Blog
  3. Updated JCAPS Migration Tool Increases Asset Reuse | WhyWebSphere Blog

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: