Migration Notes

The migration tools are used as part of a four-step migration process:
1. Run WASPreUpgrade on the existing WebSphere Application Server configuration.
2. Uninstall the existing version of WebSphere Application Server.
3. Install the new version of WebSphere Application Server.
4. Run WASPostUpgrade on the new version.
In the second step, it is recommended that rather than uninstalling the existing version, it be made dormant. By keeping the existing software installed on the machine, it will be much easier to back out of the migration should unexpected problems arise.

The fully automated migration includes the following steps:
1. Migrate the existing Version 5.x deployment manager to Version 6.0 using the migration
tools.
2. Migrate the HTTP servers and HTTP server plug-ins on all Web tier nodes.
3. Individually migrate the application server nodes using the migration tools.

The WASPreUpgrade and WASPostUpgrade tools effectively move the existing configuration into WebSphere Application Server Version 6.0.

Why to migrate?
Two important things to my understanding.
For new features.
For maintenance support.
-> New Features
Again two views. Developer view and support view.
ex., My developer called me one day, said, struts framework x.xx version is throwing error on the development. I paid a look into the log and search for the errors in the IBM. Found that, that version of JVM donot support this version of struts. So, what to do? Its the developers call to have the latest copy the JVM which can support this version of struts and apps.
This is what is developer initiated migration.
Admin initiated migration -
Admin may initiate the migration too. Some of the app server errors must have been addressed in the new version of the application server and so the need for migration.
-> Support
If the product is end of the support, there is a need to migrate to supported version.

While migrating, one should need to understand inconsistencies and deprecations between the target and source environments.
In considering the incompatibilities and deprecations, we look at these major areas:
* J2EE differences
* J2SE/JDK differences
* Application Server runtime differences
* Programming Model Extension differences
* Third Party Library differences

-> J2EE Differences
Java Code, as we all know, is forward compatible. Meaning that, code compiled in JDK 1.3.0 runs on 1.4.0, but, may throw some deprecation warnings.
Its a good practice for the developers to address those deprecations in the code. So, when one plans to migrate from x version to y version, the development team should plan to revisit their code.