Step 2: Identify Unused Code and Code To Be Re-Factored
We will minimize the amount of code to be migrated, and we will identify and remove any
code that is not currently being used. We also want to identify code that needs to be re-factored
(e.g. code that includes both business logic and display logic will be re-factored based
on the Struts framework).

Step 3: Identify Required API Changes
The bulk of the work in migrating to WebSphere is due to differences in Java features and
APIs that the application servers support. As part of the assessment, the project delivery team
will review the source code to be migrated and identify what code modifications need to be
made related to the differences in feature support. Below is a summary of the areas we will
investigate to identify required changes:

Assessment Step 4: Resolve Architecture and Standards Issues
The next step in the assessment is to resolve any architecture differences/issues that must be
agreed on prior to beginning the actual migration.

Assessment Step 5: Identify Configuration Changes Required
The next step in the assessment process is to perform a detailed examination of what work
must be performed to configure the target application(s) in a WebSphere environment. We will
identify what prerequisite software (e.g. HTTP Server or database) must be installed prior to
installing WebSphere and configuring it for the target application(s).

We document what must be done in the WebSphere administrative database to configure the
target application(s). We identify what security configuration must be done to equate to the
security settings. We also identify any required configuration changes to the JDBC Providers
and Datasource names.

We then assess the cluster configuration environment and determine what model/clone configuration
must be done to provide an equivalent clustered WebSphere environment. We also
check the web server plug-in configuration to determine what changes are required.

Step 6: Identify Administrative Script Changes
There may be existing command scripts which were used to perform recurring tasks.
WebSphere Administrators use two utilities to help automate and simplify the administration
of complex WebSphere environments – XMLConfig and WSCP. Both utilities provide a scripting
language for configuring and administering the WebSphere domain. In a typical corporate
environment, scripts have been developed for these tools to automate some of the routine
tasks required to administer the environment. During the assessment, we will identify what
scripts exist and what work is necessary to migrate them to the WebSphere environment.

Step 7: High-Level Sketch of Upgrade Solution
The Assessment Report will provide a high-level sketch of the recommended Solution
Architecture for converting the target applications to WebSphere. The solution sketch will
show the hardware and software platforms, the upgraded application, and any external interfaces
which must be maintained. We will also document any major risks involved in the conversion to
WebSphere and provide a plan for mitigating the risks as early as possible during the conversion
process.

Step 8: Develop Version Upgrade Project Plan
The final section of the Assessment Report will contain a detailed project plan for executing
the WebSphere conversion for all required applications. This will identify all tasks required to
convert the target application(s) and deliver them to a production-level WebSphere environment.
It will include tasks for tackling the risk factors identified during the assessment.

The project plan will adhere to a modified version of the Rational Unified Process for executing
the project. It will identify a short Inception phase where the requirements to make the
WebSphere conversion successful will be clearly identified and a detailed Test Plan will be
developed. It will contain a short Elaboration Phase where any design work required to convert
the application(s) to WebSphere will be performed.

The bulk of the work will be performed in the Construction Phase – making required configuration
and coding changes to get the application(s) working in a WebSphere environment.
There will also be a Transition Phase where QA testing is performed and the application(s) are
prepared for production deployment.

Elaboration Phase – Resolving Design Issues
Since this is a conversion of existing code, there will be little new design work performed.
Any unresolved design issues will be addressed in the Elaboration Phase and we will proceed
immediately to the Construction Phase for all applications and vertical slices of applications
as soon as possible.

Construction Phase – Code Conversion
During the Construction Phase, we will perform the code conversion for each application
based on vertical slices of the application. Each vertical slide roughly corresponds to a use
case. We will identify the full set of vertical slices which together comprise the complete
application. We will begin the migration focused on the vertical slice which is most difficult
or contains the most risk factors. When that vertical slice is completely migrated and working properly
on WebSphere, we will move to the next most difficult vertical slice and will continue
until the entire application is converted.

During the Construction Phase, the project delivery team will develop Ant build scripts to automatically
build and package the full applications to be converted to the WebSphere platform.
Application Server Upgrade and Configuration.

During the Construction Phase, we will set up three WebSphere environments – System
Integration Testing, QA Testing, and Staging environments. The first two environments will
be set up where the code migration work is performed. The staging system will be on existing
hardware at the client site.

The System Integration Testing environment will be used to perform integration testing during
the migration. We will be migrating code in piecemeal to this environment to ensure that it
works as part of the integrated application.
The QA Testing environment will be a clean environment where we run applications that have
been completely migrated and built from scratch via Ant build script.
The Staging environment will be considered the “Production” environment for this migration
effort. We will deploy the QA tested code to it and will perform factory acceptance tests on
applications as they are delivered to this environment.

For all three environments, we will install the WebSphere Application Server, after first
installing prerequisite software packages (e.g. http server, dbms for admin database, etc). We
will convert the configuration file to the equivalent entries in the WebSphere administrative
database. We will also implement any required web server plug-in changes.

We will make any required changes to the WebSphere Application Server’s security configuration.
Then we modify all JDBC Provider and DataSource names as necessary.

Next, we clone the initial configuration of the WebSphere Application Server in order to configure
a cluster of Application Servers to support the target applications. We also convert any
scripts that were created to automate admin tasks in the applications environment to the
equivalent scripts in the WebSphere environment (this may mean creating new XMLConfig or
WSCP scripts).

Application Code Changes
At this point, the configuration of the WebSphere Application Server and associated prerequisite
software is complete and we then focus our attention on coding changes to the target
application(s). We search for JNDI look-ups and change the target names as required. We then
examine the views of the applications and determine what equivalent Struts JSPs should be
developed to produce equivalent views. We then create deployment descriptors for deploying
all JSPs to WebSphere.

Next we focus on Servlets and make any required API coding changes and then modify the
Servlet deployment descriptors as required. We then make any required changes to
UserProfile API calls and then make changes required by Session Management API changes.
Then we move on to Business Objects used in the applications and convert them. Then we
work on EJBs, first making any necessary changes to EJB lifecycle API calls and then adjusting
the EJB deployment descriptors as required.

The next step is to review all code repairing as required due to changes in the corresponding
J2EE APIs:
• JDBC – changes to WebSphere equivalent.
• Security APIs
• Transaction Management – migrate use of transaction management extensions
to WebSphere equivalent.
• XML APIs

When all coding changes are completed, we perform rigorous integration testing to ensure that
the application works as it did prior to the upgrade.

Unit, System Integration, and QA Testing
We will perform continual and extensive testing throughout the migration process. During the
Construction Phase, code will be continually unit-tested as code is migrated. For model,
domain object, and EJB code, we will use unit test harnesses – JUnit and Cactus. As each vertical
slice of each application is migrated, we will perform system integration testing to verify
that the application functions as required.

When integration testing is complete, we move to the Transition Phase of the project, where
we perform extensive QA testing and performance testing. Performance testing will include
simulating 5 concurrent users for 30 minutes.

Transition Phase – Deployment To Production
As we finish System Integration Testing on each application to be migrated, we will turn it
over to QA testing in the client staging environment. We then define production deployment
procedures and deliver the application(s) to the production environment. We also develop a
maintenance document to aid customer personnel in making maintenance changes in the
future.