WebSphere Portal Technical Conference U.S. 2007 WebSphere Portal v6 Migration Rob Holt, WP...

of 40 /40
WebSphere Portal Technical Conference U.S. 2007 WebSphere Portal Technical Conference U.S. 2007 WebSphere Portal v6 Migration Rob Holt, WP Migration

Embed Size (px)

Transcript of WebSphere Portal Technical Conference U.S. 2007 WebSphere Portal v6 Migration Rob Holt, WP...

Lotus Software Presentation TemplateWebSphere Portal v6 Migration
Rob Holt, WP Migration
*
Q & A
*
Disclaimer
THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY. WHILE EFFORTS WERE MADE TO VERIFY THE COMPLETENESS AND ACCURACY OF THE INFORMATION CONTAINED IN THIS DOCUMENTATION, IT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. IN ADDITION, THIS INFORMATION IS BASED ON IBM’S CURRENT PRODUCT PLANS AND STRATEGY, WHICH ARE SUBJECT TO CHANGE BY IBM WITHOUT NOTICE. IBM SHALL NOT BE RESPONSIBLE FOR ANY DAMAGES ARISING OUT OF THE USE OF, OR OTHERWISE RELATED TO, THIS DOCUMENTATION OR ANY OTHER DOCUMENTATION. NOTHING CONTAINED IN THIS DOCUMENTATION IS INTENDED TO, NOR SHALL HAVE THE EFFECT OF, CREATING ANY WARRANTIES OR REPRESENTATIONS FROM IBM (OR ITS SUPPLIERS OR LICENSORS), OR ALTERING THE TERMS AND CONDITIONS OF THE APPLICABLE LICENSE AGREEMENT GOVERNING THE USE OF IBM SOFTWARE
WebSphere Portal Technical Conference U.S. 2007
*
Q & A
*
Must consider the applications, infrastructure, education and culture
Migration process should not compromise day-to-day business
Manage complexity, expectations, expense and risk
Careful planning is required
Each situation is unique
There is no one standard plan
The point here is that there are many factors to consider when planning for a WebSphere Portal Server Migration. Different factors and participants will be involved in the Migration process and plan. You should account for all of these.
Different perspectives
Developer( code changes )
Administrator( production runtime )
Development managers( resources and deadlines )
Executive management( cost, risk, impact )
Careful planning is required. Many of the customer successes or failures can be directly related to the strength (or even existence) of a comprehensive plan. Many times Project Management becomes as important as the technical aspects when Migrating.
Each customer situation is unique based on the WebSphere Application Server version involved, use of 3rd party applications, previous Migration experiences: just to name a few.
WebSphere Portal Technical Conference U.S. 2007
*
Runtime
Environment
Runtime
Migration
Test
Systems
Development
Environment
Runtime
Environment
This shows the overall process of building a Migration Plan. Each of the items will be covered in more detail coming up.
The first step is Assessment. This step is very important as it identifies each of the factors that will have an impact on the Migration plan. It is effectively Requirements gathering based on each individual company’s situation
Planning: takes the factors identified in the Assessment step and builds a specific set of actions and a proposed timeline for those actions. The plan may have to be readdressed as more factors are understood or one or more changes in timeline are required.
Skills: This step addresses upgrading any skill gaps that have been identified. Many alternatives for this education exist including formal classes, online courses, IBM Education Assistant, etc.
At this point there are two paths that can be worked in parallel. I typically talk about the “Runtime Environment” first because that is how it flows later in the materials. This path describes an iterative scenario to apply the runtime part of the Migration Plan to the various test environments that may exist in each company’s environment. It provides a mechanism to test the runtime migration portion through the various test systems before performing the task on the Production system
Development Environment: Takes the standard iterative cycle of development to one more suggested degree when doing a WebSphere Portal Server Migration
Test: Roll the applications or set of applications through the certification test cycle that is in place for the company.
Production: Roll the migration into the Production environment with hopefully no surprises
Review the results: Now is a good time to do a self-assessment of the success or failures of the different steps of the Migration. Now is an excellent time to feed back these changes into the Plan so the Plan can be re-used when it is needed next.
WebSphere Portal Technical Conference U.S. 2007
*
v5.0.2.x Portal Server
v5.1.0.x Portal Server
We continue the n-2 support statement. We support migration from any version 5 Portal product. However the minimum version 5.0 supported is v5.0.2.2. Migration supports migrating from the following family of products Express, Enable, and Extend.
Migration, due to the nature of its underlying infrastructure (WAS) requires a side by side migration. The side by side requirement is the same as it has been in previous releases.
Side by side migration means:
Migration requires a new Portal installation and the use of tooling to transfer the configuration – This does not restrict the migration such that the version 6 Portal is required to be installed on the same physical box as the previous version. It simply means the version 6 Portal must be installed in a new directory on either the same machine or on a separate box that has network connectivity to the Portal running the previous version.
It is not fix pack, the current definition of a fix packs means that it is installed over an existing Portal and is used for minor updates not for major releases.
Fixpacks use the Portal Update Installer to install fixpacks or individual fixes.
Fixpacks apply file updates to an existing installation.
The migration implementation is separate from fixpacks.
WebSphere Portal Technical Conference U.S. 2007
*
Components to Migrate
There are many components that must participate in the migration process
v5.x Portal Server
WMM Custom portlets Process tasks Portlets configuration Page configuration Access control WSRP resources Clients configuration
Virtual resources Themes, skins, screens Portal Document Manager Personalization WCM Transcoding Etc…
There are many components to consider when migrating. It is recommended that you inventory your system to understand which components you have to fully understand what your migration process will entail. The core Portal components are automatically migrated by the automated migration tools and use the typical path for migration. This migration path is simplified by the new migration wizard.
If you have a highly customized portal containing additional components you may find that you have an advanced migration path. This path is similar to the typical path but allows more power and flexibility through the use of command line tasks.
A an example where manual intervention is required, would be migration of the services and services settings, these settings are now stored in a WAS registry, but due to a limitation in the WAS registry certain special characters are not allowed, if you have an application that requires a services-setting with a special character, the setting itself may need to be modified to accommodate the character restrictions.
WebSphere Portal Technical Conference U.S. 2007
*
Themes Skins Screens Portlet Applications Access Control User Customizations Virtual Portal
Markups Global settings Portal Resources JCR Content Credential Vault Slots
Themes, Skins and Screens Will require manual updates to get new functionality. v5 Themes will not work on v6 admin pages
Portlet Applications – Requires a manual copy of the Portlet war files to the new Portal’s installable apps directory. This must be done so the Portlet war files can be found during the migration process. Struts portlets may require a minor manual step if you are using a Struts portlet framework (SPF) prior to v5.1. To obtain cross page wiring for C2A cooperative portlets the pbportlet,jar file must be updated to a version greater or equal to v5.1.0.1. If there portlets are not upgraded before the migration process it is ok, as the migration process itself should not fail, however the portlets may not behave correctly when used until they are updated. It is recommended that you migrate first then upgraded the portlets using the portlet update feature.
Access Control All access control is automatically migrated except for any Access control customizations on any default admin pages or admin portlets.
User Customizations – All user customizations including, portlet setting and portlet config are migrated.
Virtual Portal Data - The virtual portal itself must be manually created. All configuration for the Managed VP portlet is not migrated so it needs to be re-created manually.
Markups – The supported mark ups are migrated
Global Settings - If migrating in a clustered environment there may be an issue with migrating the Global settings
Wires – If a set a cooperative portlets are wire together the wires themselves will be migrated as well.
Favorites- The favorites are migrated as well
Portal Resources – WSRP, Web Clippings, Credential Vault slots, Custom Unique Names are also migrated.
JCR content – Although this is not migrated as part of the core portal migration, the data in the JCR is migrated when the automated tools are used to migrate additional components such as PDM, PZN, and WCM
WebSphere Portal Technical Conference U.S. 2007
*
Q & A
*
Install the 6.0 Portal
WP v6 can be on the same machine or a different machine
Operating system family must match
Cell
Standalone
Portal v6
Portal v6
DM Node
Side-by-side means that the new Portal version is installed without affecting the existing Portal therefore, migration is a non-destructive process. Even though it is non-destructive we do recommend that you take an opportunity before starting the migration to back up your existing system.
Install Portal v6 – This can be on the same machine, be sure that your hardware requirements meet the minimum level for potentially running 2 Portal’s. Generally during the migration process you should not be processing Portal requests, and both portal should be dedicated to the migration process. If you don’t want to install on the same system, you can install the v6 Portal on a separate box as long as you are using the an OS in the same family you should be OK. For instance if you are using Windows 2000 it would be fine if your new OS is Windows 2003. It is not a supported scenario for instance to attempt to migrate from Window to Linux.
Same machine migration poses other resources issues as well. Note: A same system migration demands more disk drive, memory, and CPU resources, there may be port conflicts as well. These resource issues can usually be remedied by only having one Portal active at a time or you can temporarily change the ports for the v6 server. For instance during the export phase it is only required to have the previous portal started and during the import phase it is only required that the current portal be started.
WebSphere Portal Technical Conference U.S. 2007
*
V5.x Deployment
Step 2
Install Dmgr
Step 3
Step 4
*
Enable security to match prior Portal
Users in directory must match
Run database transfer
Reference the Portal InfoCenter for a list of required fixes
Validate Portal function
Verify admin login
Important: What you want to remember is to set up the new Portal to match the prior Portal configuration. You want use the same security model, with the same users, the same DB connection type.
You also don’t want to make use of the new Portal. You do want to log in and make sure the Portal is accessible with the admin ID. Don’t create pages, don’t create groups, don’t generally modify the portal beyond its “fresh” state.
If you plan on migrating a virtual portal you will need to create the VP’s in your new Portal to match that of your previous Portal. What this means is that you want to create the Virutal portal with the same name and context root of the virtual portal that you will be migrating from.
Very Important. This is not in the IC yet: If you expect to use Process Server based clusters you must install to a managed node. If you are not going to be using a WPS cluster, install to a stand alone node, then federate and clone after the migration is complete. When using Process server there is a restriction on adding a Portal node to a cluster, this hopefully will be addressed in a future release of Portal. The migration itself is very similar in process, when migrating be sure to turn the node agent off until the migration itself is complete. Also after the migration is complete and you have turned the node agent on to synchronize any nodes be sure to give the node agent enough time to fully synchronize all the nodes.
WebSphere Portal Technical Conference U.S. 2007
*
Reference the Portal InfoCenter for a list of required fixes
Refer to maintenance procedures for v5.0 and v5.1 when applying required fixes.
Backup previous Portal (Recommended)
Good idea even though migration does not make any changes
Disable user access (Recommended)
Set the portal to be active for read only access, this prevents the loss of updates while migration is executing.
Preparation of the previous portal is crucial. Most of these fixes address issues with XmlAccess some are specific to certain functionality, there is actually some validation that is performed during the migration process to verify the fixes have been applied. Check the infocenter for the most current list of iFixes required.
The fixes that were known at the time of GA that are required are shipped in the v6 Portal image. These fixes can be found under <wp_root>/migration/fixes. You will need to download the latest version of the v5 PUI to install the fixes.
The fixes can be applied at any time before the migration is attempted. If your portal is in a cluster you should refer to the maintenance procedure for 24x7 maintenance for Portal. When you are ready to migrate you should remove the node from the cluster.
Again, a reminder to verify the number of groups in the LDAP server visible to portal is less than the configured number of maximum groups in the wmm.xml file.
WebSphere Portal Technical Conference U.S. 2007
*
Q & A
*
Easy to use GUI
WebSphere Portal Technical Conference U.S. 2007
*
*
Provides direct access to the migration commands
Used for migration of additional components
Automated core migration tasks
Task definitions:
prop-collector – Collects information on the previous Portal. It gathers the configuration information required to contact the previous Portal server. This collection process will collect items such as property files, including wpconfig.properties, service property files, it will collect the themes, skins, and screens. The output of this task is a zip file that will need to be copied to the migration root directory on the current Portal.
collector-extract – This is a simple task that will extract the output from the prop-collector task.
export-portal-content – This task creates the temporary work directory then exports the contents of the previous portal server.
import-portal-content – This is the task that transforms the exported portal content into a format compatible with version 6. It will fix up the XmlAccess deployment script for the upgrade OOB portlets, it deploys the themes, skins, and screens.
These 4 tasks define the interface into the Portal migration framework. The underlying framework is expandable but we have not defined public interfaces but that is under investigation.
WebSphere Portal Technical Conference U.S. 2007
*
Q & A
*
WPMigrate migrate-pdm-convert-50x
WPMigrate migrate-pdm-transform-50x
WPMigrate migrate-pdm-import-50x
These are the tasks required to migrate PDM. As you can see the tasks names end in 50x if you are migrating from v5.1 a set of very similar but differently named set of tasks will be used. The tasks essentially export the PDM data and convert it into the format required for import into Portal v6.
WebSphere Portal Technical Conference U.S. 2007
*
Install WCM migration tool
WPSconfig.bat remove-wcm-migration
These are the tasks required to migrate WCM. The tasks require the setup of properties in a properties file as well as the specification of some command line parameters. Those details are beyond the scope of this presentation.
WCM requires a tool be installed into the Portal. After migration this tool should be uninstalled. WCM requires the JCR data is migrated first, then the WCM users. After the JCR data and the user have been migrated the portlets must be configured to render content for the newly migrated data in the JCR.
WebSphere Portal Technical Conference U.S. 2007
*
WPmigrate migrate-pzn-50x
WPmigrate migrate-pzn-51x
WPmigrate migrate-pzn-svData-transform-51x
These are the tasks required to migrate PDM. As you can see the tasks names end in 50x if you are migrating from v5.1 a set of very similar but differently named set of tasks will be used. The tasks essentially export the PDM data and convert it into the format required for import into Portal v6.
WebSphere Portal Technical Conference U.S. 2007
*
Log files
Q & A
*
Log files
Log files are created using the command line scripts and the migration wizard.
The following log files are always created during the migration process:
<wp_root>/log/MigrationMessages.log
<wp_root>/log/MigrationTrace.log
The following log files are created only when using the migration wizard:
<wp_root>/log/migrationwizard.log
<wp_root>/log/migrationwizardlog.txt
This presentation is just an overview of Portal migration. Spend some time to understand the details.
WebSphere Portal Technical Conference U.S. 2007
*
LDAP host
Current health of the previous and current portal
Previous portal configuration
Remote migration/Single server
Network adapter/hostname configuration
When reporting issues to IBM customer support provide the following information:
Current and Previous Portal configuration information - OS installed on, Version, additional components installed, same server install, remote migration, etc…
Current health - Can you log in? Is there abnormally slow response? Portlets display correctly?
WebSphere Portal Technical Conference U.S. 2007
*
OS
OS level
Fix packs
Portal maintenance level – Including applied fix packs and individual fixes for previous and v6 Portal
Log files
All temporary work files
Zip the directory <wp_root>/migration/work - be sure to compress this information as some of the files can be several 100 MB’s in size. Text compress works well, 200 MB XmlAccess files can be zipped into files < 7MB.
This presentation is just an overview of Portal migration. Spend some time to understand the details.
WebSphere Portal Technical Conference U.S. 2007
*
Review the directions in the Infocenter
Follow the pre-migration steps very carefully
Verify the HTTP server connection will not time out. It is preferable that the internal WAS HTTP port is used for migration.
When attempting to migrate Portal on a machine with limited resources or other servers running on them. Only start one server at a time.
Severe resource contention will cause failures, timeouts on DB or LDAP connections.
WebSphere Portal Technical Conference U.S. 2007
*
Best Practices (cont)
If both Portals are on the same machine, the Portal can use new or conflicting ports
If conflicting ports, run one Portal at a time or change the Ports for the new portal temporarily.
Start the previous server during export
Verify the previous server is reachable (i.e. check HTTP server, or firewall) when attempting to export from remote server
Start the current server during import
WebSphere Portal Technical Conference U.S. 2007
*
Start with fresh install
Do not deploy portlets
Do not create pages
Do not delete pages
If additional administration is needed, run after migrating
Be sure to specify the real host name in the v5 wpconfig.properties file, “localhost” will not work when doing a remote migration.
Be sure to copy ONLY the non out of the box portlets to the <wp_root>/installableApps directory.
WebSphere Portal Technical Conference U.S. 2007
*
Best Practices (cont)
If clustered, prevent access to the node from which the migration will be done. Stop the node agent and prevent end user access to the node.
If using LDAP, verify the number of groups in the wmm.xml file is equal to or larger than the number of groups visible to Portal in the LDAP server.
Verify the WAS and Portal admin user ID’s and passwords are specified correctly for each migration task
WebSphere Portal Technical Conference U.S. 2007
*
Best Practices – Portlets
Login to the current portal installation, to verify installation has completed successfully.
Shut down the node agent during a cluster migration
Allocate enough memory to the OS process or partition that is performing migration.
Be sure any users from LDAP that have been deleted are also deleted from the Portal server.
WebSphere Portal Technical Conference U.S. 2007
*
Best Practices – Portlets
Restart the v6 Portal after migration if the migrated themes and skins or pages don’t show up properly.
Don’t rewrite portlets when migrating. Portlet changes that cause migration difficulty:
Unique ID (uid)
WAR file name
WebSphere Portal Technical Conference U.S. 2007
*
WebSphere Portal Technical Conference U.S. 2007
*
http://www.redbooks.ibm.com/redpieces/abstracts/sg246391.html?Open
http://w3.itso.ibm.com/redpieces/abstracts/redp4227.html
*
External Components
Advanced Customizations
Q & A
*
RAD can help with some manual portlet migration
Transfer LDAP users if needed
This is not recommended to be done before migration.
Upgrade HTTP server
Upgrade DB Server application
Manual migration is reserved for the components that require customization or are not part of the Portal server itself. This include upgrading portlets to use newer API’s, of frameworks as in the case of Stuts and some C2A portlets. This also include updating the development environment, or the upgrade of any supporting applications such as LDAP or a database. Generally items that are not configured or exportable through XmlAccess will require a manual migration.
Custom themes and skins - If you wish to use the new v6 functionality such as drag and drop, context menus, fly out, etc… they must manually modify their themes and skins after migration is complete.
Custom Portlets - If the customer wants to upgrade their portlet, it is recommended they migrate their previous portal first then upgrade their portlets. It is likely the portlet may not work properly if changes are required, but performing the migration first before updating the portlet is less risky and reduces the opportunity for the migration to fail.
Custom XmlAccess Scripts -If you have existing XmlAccess scripts used to create the previous portal and do not wish to perform a full migration, the XmlAccess script used to set up the previous portal can be used on the v6 Portal as well. There are some exceptions to this rule in situations where some access control behavior in v6 was modified and additional validation has added to prevent the import or invalid access control scenarios. If you experience this problem, you will need to update your script to conform to the new access control restrictions.
WMM – Required to be manually migrated using your DB tools. You will simply need to copy the tables from your previous Portal’s WMM DB into the current Portal’s WMM DB. If you are using cloudscape you may experience some difficulty, since the tools are not as robust as those provide by the other DBMS portal supports. If you are using CS you can actually use the Portal v6 enhanced DB transfer to perform this transfer.
Rational Application Developer, LDAP, WAS Custom Services, - These are all items that are configured or maintained outside the scope to the Portal admin. These will need to be manually migrated as well, using tools that are distributed with the applications.
Important to mention:
Do not switch LDAP’s during the migration process. To reduce the complexity and risk use the same LDAP repository that you were using in the previous Portal for you current Portal.
Technical gotcha’s for LDAP:
WMM is configured to only retrieve a certain number of LDAP groups. By default this number is 200 if your LDAP server has more groups than that then you must increase the LDAP configured WMM number of groups. This requires an update the wmm.xml file on the previous server.
The export has a step that is fairly LDAP intensive. You will want to minimize access to the LDAP server so that you will not experience connection time out issues, which may cause the migration process to fail.
Hopefully your user administrative protocol is comprehensive. One common problem that we see is users are removed from LDAP but are not deleted from the Portal access control repository. This will cause a problem with the migration, and will not be noticed until the import process. We recommend that you verify that any users removed from LDAP have also been deleted from the Portal repository.
WebSphere Portal Technical Conference U.S. 2007
*
Custom themes and skins
Manual modification is required to take advantage of the v6 features such as drag and drop, fly out, context menus, etc….
See the info center on how to upgrade prior themes to add new functionality.
Custom portlets
Most other portlets should run as is
Custom XmlAccess scripts –
XmlAccess is forward compatible.
You can use the XmlAccess script used to set up your previous portal.
Transfer WebSphere Member Manager (WMM) database tables
If you are using a WMM Custom User Registry
Required for WebSphere Content Manager (WCM)
Manual migration is reserved for the components that require customization or are not part of the Portal server itself. This include upgrading portlets to use newer API’s, of frameworks as in the case of Stuts and some C2A portlets. This also include updating the development environment, or the upgrade of any supporting applications such as LDAP or a database. Generally items that are not configured or exportable through XmlAccess will require a manual migration.
Custom themes and skins - If you wish to use the new v6 functionality such as drag and drop, context menus, fly out, etc… they must manually modify their themes and skins after migration is complete.
Custom Portlets - If the customer wants to upgrade their portlet, it is recommended they migrate their previous portal first then upgrade their portlets. It is likely the portlet may not work properly if changes are required, but performing the migration first before updating the portlet is less risky and reduces the opportunity for the migration to fail.
Custom XmlAccess Scripts -If you have existing XmlAccess scripts used to create the previous portal and do not wish to perform a full migration, the XmlAccess script used to set up the previous portal can be used on the v6 Portal as well. There are some exceptions to this rule in situations where some access control behavior in v6 was modified and additional validation has added to prevent the import or invalid access control scenarios. If you experience this problem, you will need to update your script to conform to the new access control restrictions.
WMM – Required to be manually migrated using your DB tools. You will simply need to copy the tables from your previous Portal’s WMM DB into the current Portal’s WMM DB. If you are using cloudscape you may experience some difficulty, since the tools are not as robust as those provide by the other DBMS portal supports. If you are using CS you can actually use the Portal v6 enhanced DB transfer to perform this transfer.
Rational Application Developer, LDAP, WAS Custom Services, - These are all items that are configured or maintained outside the scope to the Portal admin. These will need to be manually migrated as well, using tools that are distributed with the applications.
WebSphere Portal Technical Conference U.S. 2007
*
If using CredentialVaultService.getDefaultUserVaultSegmentId() API
Change com.ibm.wps.util.ObjectId com.ibm.portal.ObjectId
In the rare case where customizations are on admin pages they need to be recreated. None of the admin pages are migrated.
Any modifications to ADMIN pages or portlets will need to be manually re-created.
The wp.migration.admin component compensates for default theme selection by explicitly assigning the IBM theme to the default Admin pages.
Themes and Skins – V5.x themes and skins should run unmodified on Portal v6. They will not however automatically have any of the new features, such as drag and drop, fly out, context menus, etc…. The IC documents how to update your themes and skins to add these features.
One special note about the admin pages and their themes and skins. DO NOT apply a v5 theme and skin to the default admin page in v6. The migration process with explicitly assign the IBM theme to the default admin pages. If your previous portal has admin portlets on pages other than the default admin pages, those portlets may not work until the theme and skin associated with those pages is updated. You can enable functionality by assigning the IBM theme post migration to those pages.
WebSphere Portal Technical Conference U.S. 2007
*
XmlAccess can not migrate large numbers of users
There is no undo
Services are not migrated automatically
WPS Tasks are not migrated - Manual recreation of all process tasks required if the customer is using WBI. WBI -> WPS conversion is not automatic. Limitation in the WPS product.
XmlAccess can not migrate large numbers of users – Use the WMM migration steps to migrate users or LDAP tools.
Admin Portal access control is not migrated.
Permissions on default admin portlets must be manually recreated
Permissions on clones do get migrated
Some cloned admin portlets may require the manual setting of configuration parameters (TBD)
Changes to admin pages must be manually recreated.
v5.10 transformations have been modified there are manual steps required to fix the transformation, these steps are documented in the Info center
There is no undo - the changes made during the migration process can not be automatically undone. It is imperative that the user backs up their initial portal configuration if it is faster than a reinstall.
Migration of portlets within EAR files requires special handling – These portlets must be manually redeployed and the XmlAccess file needs to indicate the action to take for these portlets needs to be locate instead of update.
Services are not migrated automatically. - Service jar files need to be manually redeployed, service-settings must be manually re-created
The migration wizard does not migrate additional components – This is currently a restriction, but is being looked at for future versions of Portal Server.
WebSphere Portal Technical Conference U.S. 2007
*
Q & A
Thank You
*
Migration Roadmap
Back up
The “Migration roadmap” describes details of what to consider before undertaking WebSphere Application Server Migration and provides how to build and execute a Migration plan
WebSphere Portal Technical Conference U.S. 2007
*
Migration Roadmap
The “Migration roadmap” describes details of what to consider before undertaking WebSphere Application Server Migration and provides how to build and execute a Migration plan
WebSphere Portal Technical Conference U.S. 2007
*
Runtime
Environment
Runtime
Migration
Test
Systems
Development
Environment
Runtime
Environment
This shows the overall process of building a Migration Plan. Each of the items will be covered in more detail coming up.
The first step is Assessment. This step is very important as it identifies each of the factors that will have an impact on the Migration plan. It is effectively Requirements gathering based on each individual company’s situation
Planning: takes the factors identified in the Assessment step and builds a specific set of actions and a proposed timeline for those actions. The plan may have to be readdressed as more factors are understood or one or more changes in timeline are required.
Skills: This step addresses upgrading any skill gaps that have been identified. Many alternatives for this education exist including formal classes, online courses, IBM Education Assistant, etc.
At this point there are two paths that can be worked in parallel. I typically talk about the “Runtime Environment” first because that is how it flows later in the materials. This path describes an iterative scenario to apply the runtime part of the Migration Plan to the various test environments that may exist in each company’s environment. It provides a mechanism to test the runtime migration portion through the various test systems before performing the task on the Production system
Development Environment: Takes the standard iterative cycle of development to one more suggested degree when doing a WebSphere Application Server Migration
Test: Roll the applications or set of applications through the certification test cycle that is in place for the company.
Production: Roll the migration into the Production environment with hopefully no surprises
Review the results: Now is a good time to do a self-assessment of the success or failures of the different steps of the Migration. Now is an excellent time to feedback these changes into the Plan so the Plan can be re-used when it is needed next.
WebSphere Portal Technical Conference U.S. 2007
*
Identify education requirements
J2EE/JDK/WebSphere version requirements
Runtime
Environment
Runtime
Migration
Test
Systems
Development
Environment
Runtime
Environment
This step identifies each of the factors that will have an impact on the Migration plan and the actions that will be required. It is effectively Requirements gathering based on each individual company’s situation.
Identify education requirements – typically the education requirements revolve around two primary roles (Developer and Administrator). Although other roles or related roles can also be impacted.
Developer New Portal/WAS function may also be available to be understood in each WAS version.
Administrator – The administrator may also have educational needs.
Hardware requirements Version upgrade is a good time to understand if it is a reasonable time to upgrade hardware. It may coincide with planned sun setting of hardware and should be factored into the planning. A choice of hardware upgrade during WAS version migration may impact the Migration Strategy that can be selected.
Capacity planning – Upgrades to CPUs, disk capacity or memory may have to be factored into the plan. The latest Portal versions typically does not force a hardware upgrade but in many cases an increases memory consumption may be assumed.
One hardware assessment that can be forgotten is the hardware beyond the Production environment. The other Test systems in the development cycle, including Developer hardware should be considered.
Topology assessment – The topology can factor into the plan for how to Migrate the production systems.
Downtime tolerance – Different Qualities Of Service (QOS) requirements for different applications and systems have to be understood. This may impact the ability to upgrade during a specified maintenance window and will have to be factored into the plan. This could drive an additional step of prototyping a Migration production to determine if the maintenance window can be satisfied. Additional capabilities are being provided as part of the WAS Migration package (Mixed Node support) that can be used for minimizing this risk.
Failover support – Failover support requirements during a Migration are important to understand. This will determine another QOS aspect if there is not a failover topology already in place to address the availability needs of applications.
Application architecture – Various aspects of Application architectures also need to be understood. This is much more variant based on the WAS release and associated J2EE level than some of the other Assessment factors already described.
Tightened specifications – When migrating to later WAS versions there may be cases where some applications that used to load and run on previous WAS versions will have some issue. One such area is tightening of J2EE specifications to clarify some areas that were not totally closed in prior specifications. An example is in the area of deployment descriptors. In both WAS v5.1 and v6.0 there are cases where applications will no longer be installable in those new versions that could be installed in earlier versions. This is due to tightened checking of the deployment descriptors during application installation.
Dependencies between apps – If there are dependencies between applications or on shared libraries these have to be understood. These factors can determine the order of migration of these applications.
API removal – If APIs have been removed that are in use by existing applications then these have to be modified before migration to the new WAS version. These API removals are tightly controlled and documented in the WAS InfoCenter. This documentation also includes deprecation information.
JDK changes – It is important to know when JDK boundaries are crossed when planning to Migration. In most cases the JDK compatibility is very strong. In some cases there are documented breakages that need to be understood. More information on this is provided on the JDK compatibility site as noted in the References section.
Vendor apps and WebSphere products – Supported specification levels can be a factor when determining which WAS version to migrate toward.
J2EE – Sometimes specific J2EE levels are required by companies/customers. Knowing which J2EE level is supported helps determine which WAS version to target.
JDK – Same for JDK level. One of the primary motivators for v5.1 was JDK 1.4. Knowing what JDK level that is supported is more required information. It is also useful to know when a JDK boundary is crossed to help evaluate the Migration impact. More on both of these topics is provided later in this deck.
WebSphere level requirements - Third party and other WebSphere products (e.g. WCS, WPS, …) can have specific requirements for WAS versions that they support. This can cause complications on which WAS version to migrate to when and whether work is required to potentially line up support from vendors for the WAS version that is actually desired by the customer.
WebSphere version changes
Architecture – Certain WAS versions had changes in architecture that impacted Developers and/or Administrators. Understanding these impacts is key to building the plan. More is covered on this later in this presentation.
Compatibility – Compatability of applications and administration scripts is another factor to consider when building the plan.
WebSphere Portal Technical Conference U.S. 2007
*
Hardware requirements
Educational needs
Runtime
Environment
Runtime
Migration
Test
Systems
Development
Environment
Runtime
Environment
Given the Assessment and basic requirements, the next step is to build a plan taking each of the assessment results into account
Hardware requirements – One of the first actions is to acquire and plan for upgrading hardware requirements. This can include Development machines (which should be considered an early upgrade) all the way through the Test environments (which would typically require a plan to upgrade in parallel.
Educational needs – Education needs should also be addressed fairly early in the cycle.
Identify early adopters – If possible it is best to use iteration in working with staging the Migration with Development teams. Sometimes groups emerge that either want or need to be on the latest technologies. It is ideal to work with these teams as a first pass through Migrating applications and then apply lessons learned to further iterations with other teams.
Identify Pilot projects – Work with the earliest adopters to identify Pilot projects that can be used to drive the Migration process. There are different benefits of selecting mission-critical versus “typical’ applications in building confidence in either the simplicity or the common changes that may be required for a successful Migration
Consider risk factors – There can be a large variety of risk factors. The idea is to identify and minimize them. Several examples include impeding application updates too long while Migration is occurring and exceeding a window where it is critical to have stable and available Production environment.
Create an execution timeline – From the previous information take a first pass at building an execution timeline. Include all the factors above and upgrade plan for each of the Test systems in the Test environment. This should be viewed as an iterative plan. Once some of the earlier steps are completed the timetable should be readdressed and refined.
Include a rollback plan – Always include a rollback plan. This is critical to the business. It is also important to practice the rollback plan before attempting Migration of the Production system, otherwise you could be flirting with disaster. Note that the WAS runtime tools and techniques allow a good rollback plan by not destroying the old WAS environment before installing the new WAS environment. This enhances the ease of supporting a rollback plan.
May require more memory for RAD, see reference in the back titled “Rational Application Developer Performance Tips” for some relief
WebSphere Portal Technical Conference U.S. 2007
*
Changes in the latest WebSphere version
New standards
Runtime
Environment
Runtime
Migration
Test
Systems
Development
Environment
Runtime
Environment
Skills building can take different forms and should be adjusted based on how people learn best.
A variety of techniques can be used. Standard approaches include formal classes on many different levels. Other alternatives, such as online education can also be used to address this need. One online source worth considering is the IBM Education Assistant. See References for more information.
New development tooling – Some of the WAS version boundaries include changes in IDE as well. The movement from VAJ to WSAD was a fairly significant change. The movement from WSAD to RAD has proven to be much less drastic. Both are based on Eclipse 3.0 and appear to be an evolution.
Changes in the latest WebSphere version – new features in the latest WAS versions provide an opportunity to take advantage of new capability. This can be an opportunity to Developers as well as Administrators
New standards – New standards, such as J2EE, may be available in the latest WAS version. This provides additional features and support that needs to be understood.
WebSphere Portal Technical Conference U.S. 2007
*
*
Progress iteratively, expand outward
If no changes required, perform standard regression
If development is required do it iteratively
Initially make changes that are required to support version migration
Reduces complexity of planning, diagnosis and debug - “Keep it Simple”
Test to the depth of test environment that fits your comfort level
Then do any necessary new code development and iterate following your standard practices
Address Deprecations at some point
Ideally as part of application maintenance
Assessment
Planning
Skills
Production
Review
results
Test
Development
Environment
Code
Migration
*
Progress applications normally through the test environments
Ensure Performance is measured
Have a rollback plan for production
Practice on another system earlier in the cycle
Review the results of the Migration
Update the plan for next time
Assessment
Planning
Skills
Production
Review
results
Test
Development
Environment
Code
Migration