Introduction

WebSphere Application Server V5.1, supports the Java™ 2 Enterprise Edition (J2EE™) specification. Microsoft's COM+ (Component Object Model) programming model does not conform to the J2EE (or any open) specification, and so applications written to run in the Microsoft component services-based environment require extensive changes to run on WebSphere Application Server.

It is easy to think of a migration in narrow terms, but it is dangerous to do so; application developers often tend to think of migration in terms of the application code, while administrators think of the production run time. Instead, migration should be thought of in broad terms. Migration must consider (at the very least):

• Development environment
• Developer skills
• Changes to the application code
• Administrator skills
• Run time environments.

Very often, migration is not particularly difficult, but it can be a lengthy process. Therefore, it is critical that you begin a migration as aware as possible, and take adequate stock of what you need to do before you get started.

This article is organized as a high level checklist and meant to serve as a tool to help you adequately cover the areas required to make your migration a success.

Back to top

Overview of the WebSphere platform and J2EE

WebSphere Application Server is a run time platform that provides an extensive variety of services for applications delivered over the Web (including support for browser-based user interfaces and Web services). WebSphere Application Server implements the J2EE specification, which permits organizations to build and deliver applications based on well-defined open standards.

Java is a programming language that comes with a collection of standard libraries. Java 2 Standard Edition (J2SE™) is the base library upon which all Java applications are built. J2SE includes support for building GUI-based applications, network communications, graphics, and much more. J2EE builds upon J2SE by providing a collection of libraries, architectures, and best practices for building "enterprise" scale applications.

J2EE is an umbrella specification that includes many other standards. Chief among them are the servlet, JavaServer Pages™ (JSP), and Enterprise JavaBeans™ (EJB™) specifications:

• The servlet and JSP specifications provide mechanisms for providing control and view logic for Web-based applications (though the specifications are general enough to be used for other purposes).
• The EJB specification is concerned with providing server-side components for use by applications.
• EJB components tend to be used for containing "back end" business logic, while servlets and JSPs generally provide a "front end". When applications are well-architected, EJB back ends can be reused for different front ends. EJB components might be used, for example, to provide business logic for a Web service front end, as well as a servlet and JSP front end.

WebSphere Studio is an integrated development environment (IDE) used to build J2EE applications. The WebSphere Studio family of products includes:

• WebSphere Studio Application Developer
• WebSphere Studio Application Developer Integration Edition
• WebSphere Studio Enterprise Developer.

Each of these products provides J2EE application development support, with increasing levels of extended support. WebSphere Studio Application Developer provides everything you need to build, test and deploy J2EE applications. WebSphere Studio Application Developer Integration Edition extends the J2EE support with support for integrating J2EE applications with legacy applications (such as, CICS®, SAP®, PeopleSoft®, and so on) using JCA connectors, business process choreography, and other features. WebSphere Studio Enterprise Developer adds support for additional legacy enterprise development and includes additional rapid application development tools.

For more information on all WebSphere products, see Resources.

Back to top

Migration roadmap

Migration must consider all aspects of enterprise application ownership. At a high level, your migration plan should cover the following areas:

• Migration assessment
• Development environment
• Skills
• Application code
• Run time environments
• Test.

Each of these areas will be discussed with greater depth in the following sections.

Back to top

Migration assessment

A comprehensive migration assessment is a key element of migration success. Assessment will typically take between five and ten days and should involve somebody familiar with WebSphere Application Server and WebSphere Studio. The main target of assessment is to discover issues that may have an impact on the migration process so that adequate resources can be applied to ensure that the migration is successful. The main activities and objectives of assessment include:

• Bring concerned parties together.
  The migration assessment is a good opportunity to bring concerned parties together. An interesting result of assessment is often a more clear understanding between the different groups about the larger picture, and a greater appreciation for the issues faced by other areas.
  
  
• Educate.
  An unfortunate mistake that many organizations make is to jump headlong into J2EE without really understanding what it is. Before you send your developers and administrators to training, it is helpful to have a high level understanding of what the technology is, what it provides (and does not provide), how the pieces fit together, and the products involved. It is also helpful for the development and administration communities, IT management, and key decision makers to have the same perspective. The assessment provides a unique opportunity to provide this perspective to all concerned parties at once. This education should take the form of a relatively short, high level presentation of the concepts, technology, and products.
  
  
• Review high-level architecture.
  With the gathering of concerned parties comes an excellent opportunity to articulate the application at a high level. Reviewing the architecture sets the stage for other parts of the assessment by bringing the "big picture" into clearer view. A high level architecture review should not take more than a couple of hours.
  
  
• Review application code.
  One activity that is obviously part of the assessment process is a review of the application code. Such a review need not be a full-blown code review. Rather, this will probably take the form of a detailed review of the application's requirements and architecture. During this review, opportunities to interoperate between WebSphere Application Server and the Microsoft COM+ run time are explored (either with short term or long term goals in mind). Those areas which are identified as opportunities for interoperability should be reviewed with greater scrutiny to determine if any changes are required to make interoperability easier.
  
  
• Assess application development skills.
  Existing application development skills should be evaluated as part of the assessment. It is likely that your developers will require some education to familiarize themselves with J2EE, WebSphere Application Server, and the new development environment.
  
  
• Review the run time environments.
  Most organizations support a number of run time environments, each with a different purpose. The configuration of these environments (possibly including one or more development test, system test, pre-production, and production environments) should be reviewed as part of the assessment to ensure that the existing requirements, topology, configurations, and hardware is adequate for WebSphere Application Server. A review of security requirements and implementation is an important part of this stage of the assessment. Review of the run time environments typically takes at least a day.
  
  
• Review the build and deployment processes.
  The existing processes should be reviewed to identify changes that are required for WebSphere Application Server. New build scripts and practices will be required as part of the adoption of WebSphere Application Server.
  
  
• Review and understand schedule issues.
  Scheduling is always an issue with migration. Most organizations have applications that are constantly changing in response to external business drivers. Working a migration plan around other deliverables can be a daunting task that requires special attention.
  
  
• Review testing practices.
  Existing testing practices should be reviewed to determine whether or not they provide adequate coverage. If not, then some augmentation of testing practices may be required. If well defined and robust testing practices are not in place at the time of the migration, it is often difficult to know -- when a problem is encountered -- if the migration is a catalyst that has exposed a pre-existing problem, or if the migration is the actual source of the problem. This makes it difficult to gauge the progress and ultimate success of the migration. A comprehensive testing strategy is a very important part of enterprise application ownership. An assessment gives you the opportunity to understand what you have and what you need to do, and to accurately plan your migration so you can put the necessary resources in place. For more information about testing, see Resources.

Back to top

Development environment

Setting up a new development environment is rarely a simple matter of installing a new integrated development environment (IDE). As part of the process of adapting to new tools, you will either have to integrate with your existing source code management software or select a new one. You should also strongly consider establishing a collection of best practices for the new environment (consider leveraging the best practices that already exist; see developerWorks). Rolling out a new environment to multiple developers can be a time-consuming task.

WebSphere Studio is the most appropriate development environment for building applications for WebSphere Application Server. WebSphere Studio is built using open source Eclipse technology (see Resources), widely regarded as one of the best tools available for Java development. WebSphere Studio builds on the tools provided by Eclipse to provide the most complete tool for J2EE development. WebSphere Studio is an open and pluggable environment intended for all kinds of development, including components to build and edit Java, J2EE, and Web site content (HTML, images, and other resources).

WebSphere Studio supports a number of software configuration management (SCM) solutions, including Rational® ClearCase®, Concurrent Versions System (CVS), and others, using vendor-supplied plug-ins. Additional products are supported through third-party plug-ins. If a plug-in is not available for your SCM, WebSphere Studio can still be used in disconnected mode. (See Resources for SCM solutions known to work well with WebSphere Studio.)

It may be possible to reuse some components of your existing application as part of your migration. It may be possible, for example, to reuse HTML and other Web resource elements, property files, and similar components (unfortunately, Visual Basic (VB) code will not run in WebSphere Application Server). As part of the migration to WebSphere Studio, existing source trees may need to be modified (or replaced completely).

Other tools may be used by the development team as well. These tools will have to be evaluated to determine their appropriateness for WebSphere Application Server development. If necessary, appropriate replacements may be required; for example, WebSphere Studio provides tools for XML authoring which may be appropriate replacements for third-party XML tools.

Back to top

Skills

Application developers will need to be familiar with Java and J2EE to be effective when migrating your application to WebSphere Application Server. Classroom training provides a great start in developing these skills. Mentoring, immediately following the classroom training, is your best bet at effectively transferring required skills to your developers.

WebSphere Studio is different from other development environments and you should expect that it will require some time for developers to fully develop the skills required to work effectively with the product. Even really bright people should receive training for WebSphere Studio to fully leverage the power the product can provide. Typically, ten to fifteen days of classroom training followed by a period of comprehensive mentoring by experienced J2EE developers is sufficient for application developers who are already familiar with enterprise application development. Every migration plan should include mentoring for the development team to guide them through their first few months with J2EE and WebSphere Studio.

Classroom training for developers should include (at a minimum) the following topics:

• Object-oriented analysis and design
• Java language
• J2EE (with particular focus on servlets, JSPs, and EJB components)
• WebSphere Studio.

Managing a collection of WebSphere Application Server nodes is a task that requires dedicated administrators with specialized skills. Management of WebSphere Application Server is very different from management of Microsoft Internet Information Service (IIS) and Transaction Server (MTS). While many of the concepts are similar, the details are very different. It may take some time for your operations staff to learn about WebSphere Application Server and understand how to configure and manage it. Existing scripts that you may use to manage your existing server will need to be rebuilt to work with WebSphere Application Server.

Formal training will benefit even skilled administrators. Typically five days of classroom training is enough to arm seasoned application server administrators with the information they need to install, configure, and maintain WebSphere Application Server. Classroom training for administrators should include (at a minimum):

• Installation and configuration of WebSphere Application Server
• Maintaining WebSphere Application Server (applying patches, and so on)
• Clustering and scaling
• Installing and configuring J2EE applications.

Back to top

Application code

Application code could well be the single largest aspect of your migration to WebSphere Application Server. Just how big a task this is depends on your needs in the short and long terms. It is possible, for example, for WebSphere Application Server to interoperate with Microsoft COM+ applications. You could consider this as part of a short term strategy: as you adopt WebSphere Application Server, you still need to provide business functionality. Migrating all of your code to J2EE can be time consuming and possibly expensive, so as part of this process, it may be wise to keep some of your existing code running.

In evaluating how your application code will be migrated, you need to consider:

• Architecture
• Code organization
• Third party libraries
• Migration tools.

These points are discussed below.

Architecture

Application architectures exist to bring together the various aspects of an application into a cohesive form. Applications contain view, control and business logic:

• View logic is concerned with presenting information to the user and collecting information from the user.
• Control logic is concerned with moving information between the view and business layers. The control logic is also concerned with determining the next course of action.
• Business logic is where the interesting behavior is supposed to exist; this layer contains the algorithms and processes that are specific to your business.

Classic application architecture best practices recommend that each of these logic types be contained in a separate layer, as shown in Figure 1. According to best practices, the view layer communicates with the control layer, which in turn communicates with the business layer. This separation provides a number of benefits; to start, keeping your business logic completely separate from your control and view logic makes it very easy to add new views to your application. For example, if your business logic is well defined and separated from the rest of the application, adding a Web service front end should be relatively easy.

In Web-based Microsoft COM+ applications, Active Server Pages (ASP) files are typically used to provide both view and control logic. In many cases, a single ASP file contains both view and control logic (though it is possible to have a control-only ASP). Listing 1 shows an example ASP file that provides both view and control logic.

This ASP presents a simple HTML form prompting the user for a user name and password. The test at the top of the file (1) determines what "mode" we are in. If we're in "view" mode, then some HTML text is displayed (2). If we are in "control" mode, then control code is executed (3).

Listing 1. Sample ASP file

(1)	<%if Request("txtUserName") = "" then %>

(2)	<html>
	<head>
	<title>Login</title>
	</head>
	<body>
	<form name="login" method="post" action="login.asp">
	User Name: <input type="text" name="txtUserName"><br>
	Password: <input type="password" name="txtPassword"><br>
	<input type="hidden" name="action" value="<%=Request("action")%>">
	<input type="submit" name="cmdLogon" value="Logon">
	</form>
	</body>
	</html>
	<%else

(3)	dim userID, password
	set userID = Request("txtUserName")
	set password = Request("txtPassword")
	if userID <> "" then
		dim loginAccount, loginId
		set loginAccount = Server.CreateObject("Login.Account")
		loginId = loginAccount.LoginUser(userID, password)
		if (loginId = nothing)
			Response.Redirect("login.asp")
		else
			Response.Redirect("main.asp?Id=" & loginId)
		end if
	else
		Response.Redirect("login.asp")
	end if
	%>
	<%end if%>

The flow of control through this ASP is shown in Figure 2. This ASP loops back to itself. It starts in view mode (1) in which it presents the form to the user and gathers data. When the user submits the form (2), information from the form is packaged up and sent back to the same ASP. The control logic makes use of COM objects (3) to access the database. The mode of the ASP is determined purely by the presence or absence of values from the form (the request attribute will contain form values if the form has been submitted).

A similar architecture is possible with J2EE but is discouraged. J2EE provides constructs that allow view and control logic to be easily separated. Listing 2 shows a Java ServerPages (JSP) file. Note that the JSP file is primarily concerned with providing view information.

Listing 2. Sample JSP file

<html>
<head>
<title>Login</title>
</head>
<body>
<form name="login" method="post" action="LoginServlet">
User Name: <input type="text" name="txtUserName"><br>
Password: <input type="password" name="txtPassword"><br>
<input type="hidden" name="action"
value="<%=request.getAttribute("action")%>">
<input type="submit" name="cmdLogon" value="Logon">
</form>
</body>
</html>

JSPs are very similar in concept and in implementation to ASPs. The names are similar, as are some of the tags (<%...%> and <%=...> in particular). In our example, the JSP content is very similar to the ASP content, introducing only relatively minor syntax changes. Do not be distracted by these similarities: while it is certainly true in this example and in many real world cases, it is not necessarily the case that JSP code will mirror ASP view code so closely. There is a lot of functionality that is provided in very different ways in ASPs and JSPs.

One of the changes in the JSP code is the action for the form. In the JSP, the form is submitted to the servlet, named LoginServlet, shown in Listing 3.

Listing 3. Sample servlet file

package com.wtb.sample.servlet.layout;

import java.io.IOException;
import javax.servlet.*;
import javax.servlet.http.*;

public class LoginServlet extends HttpServlet implements Servlet {
	public void doGet(HttpServletRequest req, HttpServletResponse resp)
	throws ServletException, IOException {
		String userID = req.getParameter("txtUserName");
		String password = req.getParameter("txtPassword");
		if (userID != null) {
			LoginAccount loginAccount = getLoginAccountBean();
			String loginId = loginAccount.loginUser(userID, password);
			if (loginId == null) {
				getServletContext().getRequestDispatcher("login.jsp")
					.forward(req,resp);
			} else {
				getServletContext().getRequestDispatcher("main.jsp?Id="+loginId)
					.forward(req,resp);
			}
		} else {
			getServletContext().getRequestDispatcher("login.jsp")
				.forward(req,resp);
		}
	}
}

This servlet performs the same set of steps performed by the control code in the ASP, but uses Java syntax and J2EE constructs. The big difference is that the view and control logic is separated into completely distinct layers. This is shown in Figure 3.

The user first connects to the JSP (1) which provides a form for the user to complete. When the user submits the form, control is passed to the servlet (2), which enlists the help of an Enterprise JavaBeans (EJB) stateless session enterprise bean to perform the business logic. Conceptually, the layers are the same, with COM objects replaced by EJB components.

Of course, ASPs and JSPs provide far richer constructs for building applications. A single scenario is presented here to show where similarities can lie and to demonstrate that migration is possible. This example also shows a reasonably well-architected ASP-based application being migrated into a reasonable well-architected J2EE application. In reality, not all applications are well-architected; lack of reasonable architecture makes migration more challenging. (A thorough study of the specifics of migrating every possible aspect of ASP is beyond the scope of this article.)

In many cases, ASPs provide all application logic, including view, control and business logic. In these cases, identifying and separating the various logic types can be very time consuming. A short term migration strategy might be to migrate the combined logic from Microsoft VB scripting into combined logic in J2EE as part of a first stage of migration. In a later stage, layers can be introduced into the J2EE application.

Code organization

J2EE defines a very specific packaging structure that separates the various artifacts into different archives. Web artifacts, including servlets, JSPs, and Web content (like HTML, PNG and JPEG files), are packaged in a Web Archive (WAR) file. EJB artifacts, typically consisting of the EJB types, are packaged in an EJB-JAR (JAR) file. An Enterprise Archive (EAR) file is used to collect all the application components (WAR and EJB-JAR) files into a single file. Other libraries (JAR files) used by the application can be located in the EAR file as well. The archive can also contain application client archives (JAR), which is another J2EE module type.

Figure 4 shows how the various archives (also referred to as modules in the J2EE documentation) are organized.

Packaged with each module is an XML deployment descriptor that describes the organization of the components in the module and how they are configured at run time.

WebSphere Studio requires that application code be structured along J2EE lines. Web artifacts must be placed in a Web project and EJB artifacts must be placed in an EJB project. Within these project types, a particular directory structure is also required. A Web project must, for example, contain a Web content directory that contains all the content for the project (everything except for source code).

Third party libraries

If your Microsoft COM+ application makes use of third party libraries, you will have to spend some time researching equivalent functionality in J2EE. In many cases, J2EE will already contain the functionality you require. In other cases, you will have to seek out alternatives. Business Objects' Crystal Reports is a good example of a library commonly used by Microsoft COM+ applications; an equivalent library is provided for Java that uses a report file format.

As part of the migration effort, third party vendors should be contacted and asked to provide compatibility statements for WebSphere Application Server. This should be done relatively early in the migration cycle so that, if necessary, alternatives can be researched.

Migration tools

Migration to WebSphere Application Server is generally a manual one composed of processes rather than specific tools. This is the nature of middleware: middleware provides the power and flexibility to solve arbitrary problems; however that flexibility makes building good general-purpose tools to migrate between middleware platforms based on different standards very difficult.

Still, there are many different types of tools that (ideally) you could leverage as part of a migration:

• Assessment tools
  Assessment tools are useful for determining the effort required to complete the migration. As part of a migration assessment, it is important to take stock of the various types of components in your application. If, for example, you know how many forms are defined in a Visual Basic application, and you know (or can make an educated guess) how long it will take to rebuild a single form, you can extrapolate how long it will take to migrate all forms.
  
  Assessment tools can also help by determining code complexity. Complex code may be more difficult to migrate, as it is generally more difficult to understand. Knowing the complexity can help you to make better estimates of the work required.
  
  
• Code migration tools
  Really comprehensive tools that migrate application code from Microsoft technologies to native Java and J2EE do not exist. An extremely vast amount of intelligence is required for a tool to understand the semantics of your application and use that knowledge to build a semantically equivalent J2EE implementation. However, tools can still be useful. Tools may be able to automate the conversion of some part of your application code, which could translate into significant time savings.
  
  One big problem with many code migration tools is that they translate code line-by-line; they do not attempt to understand the semantics and just literally translate each statement. Since the languages are quite different between technologies, efficient native translation is difficult or impossible. Many tools depend on libraries that provide APIs that deliver equivalent functionality to the statements being translated.
  
  Also, the translated code's dependence on a library is also a potential issue. Long term dependence on the library may incur extended licensing costs and dependence on the vendor for regular updates and support. However, dependence need not be long term. One of the key benefits to using such tools is the ability to very quickly move significant portions of your application to J2EE immediately. Once the code works in J2EE, it is much easier to then use one set of tools (such as WebSphere Studio) to modify, test and debug it.
  
  You might consider short term dependence on a library as part of a first stage of migration. In a second (or later) stage, code that depends on the libraries can be removed so that the dependency can also be removed. In the long term, the dependency goes away; in the short term, the code migration occurs more quickly.
  
  
• Emulation tools
  Some tools provide functionality that extend beyond code conversion. With an emulator, you can -- in theory -- take your existing application and drop it onto WebSphere Application Server and it will just work. Emulation sounds like a great blessing and in some cases it is. However, considering the following:
  • The "migrated" application will not leverage J2EE best practices, which means that qualities of service provided by J2EE application servers may not be obtained.
  • The run time environment is more complex: you must maintain both the new WebSphere Application Server environment and the emulation environment on top of it.
  • Development teams will need to continue developing using the existing toolset.
  • You are at the mercy of a third party vendor to provide support for your application up to the point where you migrate the code into native Java and J2EE.
  Finding the right emulation tools may be difficult. A product that emulates .NET would require that existing applications that use older Microsoft technologies (like Visual Basic) be upgraded to take advantage of its services. Upgrading from older technologies to .NET can, in some cases, be as complex and time consuming as rebuilding the application in J2EE.
  
  One of the key benefits of emulation is that it can potentially allow you to get your applications running on WebSphere Application Server quickly. Once they are running, you can start to migrate them into native J2EE applications. This is especially valuable for organizations with a large number of applications that cannot be all migrated at once. In a first stage of migration, the existing applications can be quickly moved to an emulated environment on WebSphere Application Server; in future stages, individual development teams can complete the code migration.

Back to top

Run time environments

Most organizations have more than one run time environment, including development test, system test, performance, and pre-production. Other environments with other purposes may also exist.

Rarely is the migration of a run time environment a simple matter of shutting everything down, installing new hardware and starting everything back up. This may be possible for development test and system test environments, but other run time environments have restrictions that make such practices impossible. In almost every case, the production run time environment must stay in service while it is migrated. Often, very limited downtime is acceptable for even the pre-production environment. Migration of a production run time is made more complex if there are multiple applications with different development teams and different delivery schedules. In this sort of environment, it may be necessary to run both application server products concurrently for a period of time. There are, however, some interoperability options.

Horizontal interoperability

The simplest form of interoperability is to run your existing Microsoft COM+ applications beside new J2EE ones. That is, run some applications completely on the Microsoft COM+ runtime and some applications completely on the WebSphere platform. As applications are migrated from ASP/COM+ to J2EE, they can be deployed on WebSphere Application Server. Throughout this process, server resources can also be moved around as necessary.

This type of interoperability assumes that the application can be partitioned into independent pieces and that any communication between the pieces can be affected by using backend systems (like a database, for example). Figure 5 shows an example of this interoperability scenario.

In this example, IIS is configured with WebSphere Application Server's plug-in. The plug-in is configured to direct all requests for "Application 1" to WebSphere Application Server. All other requests are handled by IIS. This example also shows an application database that is shared by all applications. Care needs to be taken in this sort of configuration to ensure that that all interaction with the database is consistent across all applications.

The key benefits of this sort of interoperability are relative simplicity, and the fact that the migration can be executed in steps: one application can be migrated, tested and rolled into production while the other applications continue to work unchanged.

Vertical interoperability

It may also be possible to interoperate between parts of the application. That is, some parts of the application can stay in the Microsoft COM+ run time while other parts are migrated to J2EE. This is true particularly if your Microsoft COM+ applications make use of a layered architecture. If you have your application's business logic layer neatly packaged in a Web service or COM object, then you may be able to build view and control logic in J2EE that makes use of that COM object. Figure 6 shows vertical interoperability between WebSphere Application Server and the Microsoft COM + run time.

Interoperability can be achieved in many ways. It is possible to access COM objects from WebSphere Application Server. It may also be possible to communicate using HTTP or Web services (to make use of Web services, Visual Basic applications need to be upgraded to .NET). For more information on interoperability options, see Resources.

Rolling migration

Depending on your run time configuration, it may be possible to do a "rolling migration". A sample run time topology is shown in Figure 7.

In a rolling migration scenario, application servers are upgraded individually or in small groups using the following steps:

• One or more application server nodes is selected.
• The selected nodes are removed from the load balancer's routing tables (see Figure 8).
• The nodes are removed from service (shut down).
• Microsoft server technologies are either removed or made dormant.
• WebSphere Application Server is installed, configured and tested.
• The J2EE application code is installed, configured and tested.
• The upgraded node is activated and configured to accept incoming requests (for example, it is added back to the load balancer's routing table).

The process is repeated for the remaining nodes.

This is a very simple overview of the activities and may not necessarily be appropriate for your configuration. This scenario assumes that you have at least three servers providing more capacity than you require (so that enough capacity is available to handle traffic during the migration) and that you are reusing existing hardware as part of the migration. If your run time environment is running close to capacity, you might consider temporarily adding additional hardware to your configuration during the rolling migration. If you are acquiring new hardware as part of the migration, the process may be even easier.

The first node to be migrated would become the first server in a new WebSphere Application Server V5 cell (a collection of application server nodes that are managed through a single interface). As additional nodes are migrated, they are added to the cell, as shown in Figure 9.

Every migration plan should include a back out strategy. In the above steps, it is suggested that the existing server software be "made dormant". Rather than completely removing the old software, you can instead just shut it down (and configure your system not to start it). If later testing reveals that the migration did not work, it is then a relatively easy matter to reinstate the old version of the application.

If you have multiple applications, the rolling migration may take weeks or even months. If you have a single application, or if all your applications are migrated prior to the run time migration, the rolling migration may be accomplished in a matter of hours or days. In either case, it is important to consider that, at least for some period of time, you will have to support a run time environment that contains a mix of software (like that shown in Figure 9).

The mix of versions has some interesting implications. To start, if two different versions of a single application are running on different server products, effort must be made to ensure that the application appears consistent to the user. That is, the application should look and act the same way on both application server versions. If your applications make use of server-side state (HttpSession in J2EE), you may consider introducing (if you have not already done so) server stickiness to ensure that all requests from a particular user are directed to the same server instance. Unfortunately, HttpSession state cannot be shared between WebSphere Application Server and IIS. This has a potential impact on failover.

Figure 9 shows an Application Data database shared by WebSphere Application Server and the COM+ servers. This may be possible, but will likely require that very specific database versions with very specific fix packs be applied. As part of the migration, you may need to update your hardware, operating systems, and other components (such as the HTTP Server and database). Product requirements are well-documented in the prerequisites (see Resources).

Back to top

Test

Test your run time migration plans in a test environment before starting the migration of your production run time. Migration is more than just installing new products. Some of your existing practices and process may need to be considered as well. Any scripts you currently use to administer your servers will need to be revisited and rebuilt.

Back to top

Conclusion

It is difficult to cover all aspects of migration in a single document. Without exception, every organization and application is different, so it follows that every migration experience will be different as well. In this paper, we have outlined many of the issues you must consider as part of your migration effort. More specific information about migration is detailed in An End-to-End Migration Guide in Resources.

Migration is always a significant undertaking. Even if no change is required to your application code, migration will still take some level of time and effort when all factors are considered. Migration involves more than just code or any single environment. Your migration plan should account for everything from the development environment and skills, right through to administration skills and run time environments.

Migrations that begin with careful planning are the ones most likely to be successful.

Resources

• IBM WebSphere products
  
  
• IBM developerWorks Migration station: Migration overview
  
  
• IBM developerWorks Migration station: Application server track
  
  
• Getting on the open road: Migrate to the Java platform
  
  
• Java Web-enabled fundamentals for Windows developers
  
  
• Best Practice Guide for WebSphere Application Testing, Jeff Garratt
  
  
• Eclipse, Web site of the Eclipse Foundation
  
  
• Plug-in Central includes business partner plug-ins for Ready for IBM WebSphere Studio and Ready for IBM Rational products
  
  
• WebSphere Application Server system prerequisites
  
  
• Migrating to WebSphere V5.0: An End-to-End Migration Guide, IBM Redbook SG24-6910-01, Seong Yu et al.
  
  
• WebSphere and .NET Coexistence, IBM Redbook SG247027, Peter Kovari et al.
  
  
• developerWorks WebSphere Application Server zone
  
  
• developerWorks WebSphere Studio zone
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Overview of the WebSphere platform and J2EE
• Migration roadmap
• Migration assessment
• Development environment
• Skills
• Application code
• Run time environments
• Test
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

Dig deeper into WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers