WebSphere Application Server

Migration Methods
Don’t find yourself out of support

WebSphere Application Server

Mike Hill, Mike Shenhouse, John Juecek and
Tony Burkhalter

1
 Agenda
• Traditional WebSphere Migration, Local vs
Remote
• Inplace migration of Traditional WebSphere
• Clone migration of Traditional WebSphere with
zero downtime
• Migration Assist (MA) Program. What is this, how
can you benefit from this free program, and how
to initiate

2
Traditional WebSphere Migration

Local vs Remote

3
 Introduction to Migration
What is Migration ?

• The definition of Migration is to upgrade a WebSphere

Application Server installation to a newer version.

• Migration is the process of moving the configuration from an

older version to a new version, such that the new configuration
behaves as closely as possible to the old configuration.

• Existing application components and configuration settings are

applied to the new version’s environment during migration
process

4
 Planning Your Migration
• Check OS Pre-reqs for your planned target version
to ensure compatibility
• Determine Your Migration Path
• Your current version (7.0, 8.0 or 8.5)
• Targeted Version (8.5 or 9.0)
Review New Features
Review Planning Guide
• Review Potential Impacts in “What’s Changed”
document
5
 Tools for Migration
• Migration Wizard ( GUI based)
• Command Line
 WASPreUpgrade

 WASPostUpgrade

6
 Migration Scenarios
• Network Deployment cell Migration on same
machine.
• Migration of Network Deployment cell on
remote machine.

7
 Migration Scenarios
• Two step process
 Profile data from old version or source profile is captured into a migration
backup directory.
 Source data is merged into the new target profile.
• Allows users to keep their old system running until new
environment is ready.
• Various options for running a migration, depending on the
topology of the installations.
 Scenarios are outlined in the WebSphere Application Server IBM Knowledge
Center

8
 ND Migration Scenario
on same Machine

V7.0
DMGR

V7.0
NODE

9
 ND Migration Scenario 1. 5.
Start
on same Machine Install 9.0.x with latest
fixpack. Create DMGR Profile 9.0 DMgr
with same CELL and NODE
NAME as in DMGR 7.0

2. DM 4.
3.
V7.0 V9.0/bin WASPREUPGRADE backup v9.0/bin WASPOSTUPGRADE
V9.0
DMGR DMGR
2.
Stop DMGR, Nodeagent(s) and
servers

2.s
V7.0
NODE

10
 ND Migration Scenario 1. 5.
Start
on same Machine Install 9.0.x with latest
fixpack. Create DMGR Profile 9.0 DMgr
with same CELL and NODE
NAME as in DMGR 7.0

2. DM 4.
3.
V7.0 V9.0/bin WASPREUPGRADE backup v9.0/bin WASPOSTUPGRADE
V9.0
DMGR DMGR

6.
Synch Old Node with New DMGR
manually

2.s
V7.0 Node
7. V9.0
NODE V9.0/bin WASPREUPGRADE
Backup NODE

8.
Create Managed or Default
Profile with the same NODE
name but don’t federate it.
Migration process will take
care of it.
11
ND Migration Scenario 1.
Install 9.0.x with latest
5.
Start
on same Machine fixpack. Create DMGR Profile
with same CELL and NODE
9.0 DMgr
NAME as in DMGR 7.0

2. DM 4. V9.0
3.
V7.0 V9.0/bin WASPREUPGRADE backup v9.0/bin WASPOSTUPGRADE DMGR
DMGR

10.
Sync New Node
With the DMGR

2.
V7.0 7.
9.
V9.0/bin WASPOSTUPGRADE
V9.0
NODE
V9.0/bin WASPREUPGRADE
Node NODE
Backup
8.
Create Managed or Default
Profile but don’t federate it.
Migration process will take
care of it.

12
 Summary of Migration
• Before attempting migration, backup all source profiles completely.
• Both WASPreUpgrade and WASPostUpgrade should be executed from
WSAS v9.0 (or new version).
• Cell and Node Name of new Deployment Manager should be same as old
environment.
• During WASPreUpgrade Migration, old Deployment Manager needs to be
stopped.
• Once WASPostUpgrade Migration is complete, old Deployment Manager is
disabled automatically by default.
• Start new Deployment Manager and then manually synch with Old nodes
before starting node migration.
• Create new Application Server profiles - default or managed (managed is
recommended as it will not have sample applications) but don’t federate.
• On each node in the cell, run WASPreUpgrade again, followed by
WASPostUpgrade.
• The Migration backup directories will have logs and traces from Pre and Post
migration.
13
Migration to remote machine (1 of 5)

V7.0 V9.0
DMGR DMGR

Machine A Machine B

V7.0 V9.0
NODE NODE

Deployment Manager migration to remote machine only supported WSAS v7.0 onwards.
In WSAS v6.1 we support only standalone profile migration to Remote machine.

14
 Migration to remote machine (2 of 5)

• Occasionally users want to migrate their WebSphere

profiles and nodes to a new machine that may have a
different operating system installed.
• The WebSphere Application Server V8.0 migration tools
(onward) support these types of migration across all
distributed platforms except iSeries. Cross platform
migrations are not supported on z/OS.
• Use the “WASPreUpgrade –machineChange true”
command for cross platform migrations.

15
Migration to remote machine (3 of 5)

16
 Migration to remote machine (4 of 5)
• The createRemoteMigrJar tool will help with
cross platform migrations.
– You do not have to perform a full WebSphere
Application Server V9.0 installation on the old
machine in order to run the WASPreUpgrade
command.
– The WASPreUpgrade command file can be
obtained from a machine with WebSphere
Application Server V9.0 installed.

17
Migration to remote machine (5 of 5)

18
WebSphere Application Server
In-Place Migration of a Cell

19
 What is In-Place Migration ?
An In-Place Migration is where the newer version of WebSphere
Application Server exists under the same location where the older
(pre-migrated) version existed

• Main Advantage:
The current process and scripts do not need to be updated in
order to achieve an In-Place Migration

• Main Disadvantage:
The old version will be completely removed after the
snapshots are taken

20
20
 TAKE NOTE :
• All WebSphere Application Server installs and uninstalls must be performed using the
documented procedures

• The steps must be followed in order to prevent the deletion of a profile before its
snapshot has been taken

• It is recommended that a complete backup of the WebSphere configuration and IBM

Installation Manager configuration be taken

WebSphere and Installation Manager directories to

 WebSphere_Root
 InstallationManager_Root
 IMShared
 IM_AgentData

21
 In-Place Migration Steps
1. Run backupconfig to backup all existing profiles to be migrated
Examples:
backupconfig.bat C:\temp\v80backupB4mig\dmgrbackup.zip
backupconfig.bat C:\temp\v80backupB4mig\appsrvbackup.zip
2. Install WebSphere Application Server v9.0 into a temporary location and apply
any FixPacks and migration iFixes
3. Run createRemoteMigrJar
Example:
cd <WASv9.0_ROOT>\bin\migration\bin
createRemoteMigrJar.bat -targetDir C:\temp\migjarext
4. Copy the RemoteMigrSupport.jar file to each node to be migrated and unjar it
into a temporary location
Example:
jar xf WAS_V85_windows.amd64_RemoteMigrSupport.jar

22
 In-Place Migration Steps cont.
5. Run WASPreUpgrade with “-machineChange true” option on each node to be
migrated
Examples:
WasPreUpgrade.bat C:\temp\premig\V80toV90Dmgr01 "C:\Program
Files (x86)\IBM\WebSphere\AppServer“ -oldProfile Dmgr01 -
machineChange true
WasPreUpgrade.bat C:\temp\premig\V80toV90AppSrv01 "C:\Program
Files (x86)\IBM\WebSphere\AppServer“ -oldProfile AppSrv01 -
machineChange true
6. Uninstall the previous version of WebSphere from all the nodes
7. Install WebSphere Application Server v9.0 into the original version's installation
location on all nodes.
8. Create a dmgr profile using the original cellName and nodeName

23
 In-Place Migration Steps cont.
9. Run WASPostUpgrade on the dmgr node with the following options:
-keepDmgrEnabled true
-includeApps script
-setPorts useOld
Example:
WASPostUpgrade.bat C:\temp\premig\V80toV90Dmgr01 -oldProfile
Dmgr01 -profileName Dmgr01 -keepDmgrEnabled true -includeApps script -
setPorts useOld
10. Start the dmgr and validate the dmgr's SOAP port has not changed
11. Optional: Install applications or BLAs using the install_all_apps.jy script
12. Create an application server profile “custom profile” with a temporary
cellName and original nodeName but DO NOT FEDERATE

24
 In-Place Migration Steps cont.
13. Copy the following files from the new dmgr's conifg directory to the
corresponding location of each nodes migration backup directory
(WASPreUpgrade directory)
a. All serverindex.xml files
b. The security.xml file
14. Run WASPostUpgrade on the application server nodes with the following
options:
-setPorts useOld
Example:
WASPostUpgrade.bat C:\temp\premig\V80toV90AppSrv01 –oldProfile
AppSrv01 -profileName AppSrv01 -setPorts useOld
15. Run syncNode to synchronize the nodes with the dmgr

25
 In-Place Migration Steps cont.
16. Start the nodeagents and servers and ensure the configuration has been
migrated
17. Uninstall the temporary instance of WebSphere v9.0 that was installed in step
2

26
Clone Migration Demo

27
 Clone Migration Demo
• Clone Migration eliminates down time
• Source system can run while the migration is being
done
• Migrating from V7 to V9 using the Migration Wizard
• Clone option is added to the Wizard in fixpack 9.0.0.1
• If you specify a clone migration for a Deployment
Manager, you must also clone all of its federated
nodes.
• Migrating a DMGR and 1 node
28
 Create new Profiles for V9
• Create DMGR profile.
• Needs to use same cellname and nodename as
V7
• Different ports used from v7 to prevent port
conflict
• manageprofiles.bat -create -profileName DemoV9Dmgr01 -profilePath
C:\WASV9ND64\WebSphere\AppServer\profiles\DemoV9Dmgr01 -templatePath
C:\WASV9ND64\WebSphere\AppServer\profileTemplates\management -serverType
DEPLOYMENT_MANAGER -cellName DemoCell -nodeName DemoDMGR01Node -
hostName shenw520 -isDefault -startingPort 20000

29
 Create new Profiles for V9
• Create Node profile
• Needs to use same nodename as V7
• Needs to have a different cellname
• Different ports used from v7 to prevent port conflict
• Do not federate, this will be done by the migration
process
• manageprofiles.bat -create -profileName DemoV9Node1 -profilePath
C:\WASV9ND64\WebSphere\AppServer\profiles\DemoV9Node1 -templatePath
C:\WASV9ND64\WebSphere\AppServer\profileTemplates\managed -nodeName
DemoNode -hostName shenw520 -startingPort 3000

30
 Leave V7 running
• Console URL:
http://localhost:4100/ibm/console/login.do
• There are 2 applications installed
• Snoop URL: http://localhost:10231/snoop/
• Server port: 10231
• Lets look at a demo (The following 8 slides are
for your reference and will be shown in the
demo)
31
 Migrate DMGR
• C:\WASV9ND64\WebSphere\AppServer\bin\migration
• Values on the panel:
New
detected version of WAS: WAS 7.0.0.41
source profile: demoV7Dmgr
Check box for Clone the Source Profile , Next
DMGR disablement : uncheck box for Disable the source deployment manger after migration
Profile Migration Output (use defaults):
output directory: C:\WASV9ND64\WebSphere\WSMigration\DemoV7Dmgr01
trace directory: C:\WASV9ND64\WebSphere\WSMigration\DemoV7Dmgr01\logs
Target Profile: Migrate to existing: DemoV9Dmgr01
Application Migration(use defaults): Migrate and install; install in default dir
Port Value: generate new ports, starting value 6000
Additional Migration Options (use defaults): embedded databases: stop migration Admin console: do
not migrate My Tasks
32
Migrate Summary

33
Migrate Results

34
 Migrate Node
• Start the V9 DMGR
• Values on the panel
New
detected version of WAS: WAS 7.0.0.41
source profile: demoV7Node1
check box for Clone the source profile
Deployment Manger Verification
node name:DemoDMGR01Node
cell name: DemoCell
hostname: shenw520
SOAP port 6007
RMI port 6000
Test Connection to Deployment Manager
Connection success, next

35
 Migrate Node
• Values on the panel…
ProfileMigration output: (keep defaults)
output directory: C:\WASV9ND64\WebSphere\WSMigration\DemoV7Node01
trace directory: C:\WASV9ND64\WebSphere\WSMigration\DemoV7Node01\logs
Next
Target Profile: Migrate to existing: DemoV9Node1, Next
Port Value: generate new ports, starting value 7000, Next
Additional Migration Options (keep default): embedded databases: stop migration
Migration Summary, Migrate

36
Migrate Node Results

37
 Access Application on V9
• Start the nodeagent
• Access V9 console:
http://localhost:6002/ibm/console/login.do
• The 2 applications are shown
• Snoop URL: http://localhost:7012/snoop/
• Server port 7012

38
Migration Assist Program

39
 What is the Migration Assist Program
• It is an extension of the clients current Support and Subscription
(S&S)/Passport Advantage (PPA) at no additional cost
• Provides proactive assistance to help IBM clients achieve business objectives,
minimize risks and maximize return on investment
• Level 2 can draw on their experience, provide recommendations, identify risks,
provide advice on best practices, point to technical documentation, field client
questions and alert the support teams of critical periods when the client will
perform their cut over
• Focus is on a single client environment
• It does not
• cover where WebSphere is embedded in a stacked product
• replace programs such as Services or Accelerated Value Program
• assist with application design, business logic, client data, environment
setup, performance tuning or system health check to complete the
migration
40
 How do clients initiate the program?
Currently for WebSphere there are a few ways to engage

1. Primarily our use the Knowledge Collection which has instructions to email
ma@us.ibm.com to request participation in the MA program.
Knowledge Collection - Migration Offers and Support

Level 2 support contacts the client to confirm that the MA program is a fit. If so, we
open a PMR for the Migration Assist program
2. Our Accelerated Value Program reps inform our clients of this program
3. If a PMR being worked, the client is asking a lot basic questions with respect to
migration. Tech support would recommend the program to the client.
4. Twitter, We use Twitter to advertize our Migration Assist program

41
 Questionnaire Example
1. Is the WebSphere Application Server bundled? (i.e. Is your WAS environment installed with a stack product such as WebSphere Commerce,
WebSphere Portal , WebSphere Process Server, etc.; versus running just WebSphere Application Server?)
2. Source WebSphere Application Server version (ex: 6.1.0.43 or 7.0.0.33)
3. Target WebSphere Application Server version (ex: 7.0.0.23 or 8.0.0.3 or 8.5 or 9.0)
4. Source operating system and bit level (ex: AIX 6.1 , 32 bit or 64 bit)
5. Target operating system and bit level (ex: AIX 6.1 , 32 bit or 64 bit)
6. What is your migration schedule? (ex: testing June-July; production July-August)
7. How do you plan to test your migration? (ex: test, development, staging, production environments)
8. How do you plan to backup your environment? (ex: tape backup or backupConfig cmd)
9. Are you planning to use the IBM WebSphere Application Server Migrating toolkit, regular configuration migration(waspre/postupgrade), or
combination
10. If you use IBM HTTP Server (IHS), are you planning to migrate?
11. Are you migrating the Deployment Manager cell or Standalone cell?
12. How many cells do you plan to migrate?
13. How many nodes are there on each cell?
14. Also are your nodes local or remote?
15. Approximate number of application servers (JVMs) in the cell?
16. Approximate number of applications in the cell?
17. How large are the applications? (example average are small, medium, large)

42
 Presentation
 Using the returned questionnaire a presentation is created
specifically for the client’s environment and target product
 A meeting is scheduled with the client and their coworkers to
present
 We field questions during presentation
 Provide time for the client to review data provided for any
questions post presentation
 Then we can focus on a target system and test a migration with a
new PMR.

43
 Migration Information
• Migration Assist Program – How to participate Blog
• Knowledge Collection, Migration Offers and Support.
• WebSphere Migration Guide
• Migrating cells using the command-line tools
• Migrating cells to new host machines using the command-line tool
• WebSphere V9 Migration Assessment service to the rescue for V7 and V8.0 users

44