"Migration," in terms of J2EE, generally means good things for a project or application. It means bug fixes from a previous version, new features to make your life easier (whether you are a developer or a system administrator), and often it means performance, fault-tolerance, and scalability enhancements.

So, if migration means good things, why does the term "migration" usually send chills down the spines of all of us Ð CIOs, project managers, and developers alike? In our minds, migration equates to missed project deadlines, and product features and application functionality that may have to be put on hold as highly valuable resources such as senior developers, system administrators, and QAs are busy ensuring the migration goes smoothly.

There are two types of users in this world performing "migrations" with J2EE products. First, there are those that built their application on WebLogic Server and WebLogic Portal/Commerce Server and are currently migrating toward the new BEA WebLogic Platform 7.0. These users are moving to the new version to take advantage of a new feature that will lower development time dramatically (enough to make the time spent on migration worthwhile). I recall migrating to WebLogic 6.1 to get Message-Driven Bean (MDBs) support. Our team was sick of writing JMS (Java Messaging Service) code in startup classes and writing this "plumbing" was time-consuming. For our application, MDBs were a huge time-saver and well worth the upgrade.

Second, there are the poor souls who mistakenly built their application on another J2EE server and are migrating from it to WebLogic for its superior scalability, performance, and ease of use. These users have applications that most likely took advantage of proprietary extensions that need to be torn out and replaced with a WebLogic-specific, or standard J2EE equivalent. As you'll see in this issue, even an application that contains no proprietary extension code can be a bear to migrate to another J2EE-compliant server. Studying migration strategies can not only help you plan for your next migration, it can help you be a better architect and developer because you learn the touch points that J2EE applications have between different servers. You learn how sound design and coding practices can make upgrades and migration between servers faster and painless.

This month in WLDJ we focus on migration strategies for WebLogic Server that covers both types of J2EE migrations. This issue contains articles to help you think through your migration plan when moving your application to the latest version of WebLogic, as well as how to move from another application server to WebLogic Server. Viresh Garg from BEA contributes to this month's theme by guiding us through the process of moving from WLS 6.x to WLS 7.0. Along with full J2EE 1.3 support, the new version of our favorite server offers tight integration of the portal and commerce products under a complete e-business platform and security enhancements touted as 1.5 years ahead of the competition. Cool stuff!

Also, this month we have Nick Tran's article on migrating Sun's J2EE Blueprints to WLS. Sun's J2EE Blueprints are generally deployed on the Sun J2EE RI (reference implementation), but we'd never want to deploy a production application on anything but WebLogic, right? So, let's get that application originally built on another server migrated over to WebLogic and deployed on a production-ready server.

I encourage those of you currently planning to migrate to the new BEA WebLogic Platform or just beginning new development on the latest version of WebLogic, to take a look inside. This month is full of helpful advice and sound practices for everyone developing on WebLogic.