1. WebSphere Portal v6.1 Migration Rob Holt WebSphere Portal Migration Lead

2. Agenda Overview Migration Preparing for migration
Migration Process Overview
Framework
Problem Determination
Common User Errors and Best Practices

3. Agenda Overview Migration Preparing for migration
What is migration
Migration Plan Roadmap
Assessment
Planning
Skills
Runtime Environment Migration
Development Environment
Application Code Migration
Test
Production
Review the results
Supported migration paths
Components to migrate
What is migrated automatically
Migration
Preparing for migration
Migration Process Overview
Framework
Problem Determination
Common User Errors and Best Practices

4. What is Migration
Migration - Moving your existing data and functionality from one WebSphere Portal release to a newer WebSphere Portal release.
Migration does not include the merging of new functionality with the old functionality.
Parallel function and performance
Migration considerations
More than just software development
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
Product architect( Design and features )
Developer( code changes )
Administrator( production runtime )
Technical support( capacity planning )
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.

5. Migration Plan Roadmap
Assessment
Planning
Assessment
Planning
Skills
Runtime Environment Migration
Development Environment
Application Code Migration
Test
Production
Review the results
Skills
Development
Environment
Development
Environment
Runtime
Environment
Runtime
Environment
Code
Migration
Runtime
Migration
Unit Test
Test
Systems
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 tme to feedback these changes into the Plan so the Plan can be re-used when it is needed next.
Test
Production
Review
results

6. Assessment Gather the people Identify education requirements
Consider a core Migration team
Identify education requirements
Developer, Administrator…
Hardware requirements
Possible Upgrades, All levels
Topology assessment
Downtime tolerance, Failover support
Application architecture
Tightened specifications
Dependencies between apps
API removal, JDK changes
Vendor apps and WebSphere products
J2EE/JDK/WebSphere version requirements
Planning
Skills
Development
Environment
Development
Environment
Runtime
Environment
Runtime
Environment
Code
Migration
Runtime
Migration
Unit Test
Test
Systems
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 – What changes can impact the Application Developer? One area that has had a large impact in the past is the education required to learn details of J2EE development. This is a major factor when migrating to WAS 4.0 and later. This is when the true J2EE programming model was supported by WAS. Another major factor for education is when changing IDEs. This happened when moving to WebSphere Application Developer (WSAD) in WAS 4.0 and later as well as the Rational tool suite in WAS 6.0 (primarily Rational Application Developer (RAD)) and later. New WAS function may also be available to be understood in each WAS version.
Administrator – The administrator may also have educational needs. The major point of concern is crossing the boundary from the WAS 3.x and 4.0.x database repository environment to the file/XML based system starting in WAS 5.0 and carrying forward into later versions. New WAS function may also be available to be understood in each WAS version.
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 WAS 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. Various WAS versions have different levels of compatibility support. More is covered on this later in this presentation.
Test
Production
Review
results

7. Planning Build a plan based on assessment Hardware requirements
Educational needs
Identify early adopters
Identify Pilot projects
Consider risk factors
Create an execution timeline
Include a rollback plan
Planning
Skills
Development
Environment
Development
Environment
Runtime
Environment
Runtime
Environment
Code
Migration
Runtime
Migration
Unit Test
Test
Systems
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
Test
Production
Review
results

8. Skills Plan for education New development tooling
Assessment
Plan for education
New development tooling
Changes in WebSphere Portal administration model
Changes in the latest WebSphere version
New standards
New features
Planning
Skills
Development
Environment
Development
Environment
Runtime
Environment
Runtime
Environment
Code
Migration
Runtime
Migration
Unit Test
Test
Systems
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 WebSphere administration model - – This is a significant step when moving from WAS 4.0 or earlier to WAS 5.0 and later. This is due to the change in how the administration model is architected. This also impacts the administration scripting model and education on making that transition should be included.
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.
Test
Production
Review
results

9. Runtime Environment Migrate test systems iteratively
Assessment
Migrate test systems iteratively
Development
Integration
System test
Performance
Pre-Production
Production
Based on your environment
Iterate through servers providing support
DB, HTTP, LDAP, etc…
Planning
Skills
Development
Environment
Development
Environment
Runtime
Environment
Runtime
Environment
Code
Migration
Runtime
Migration
Unit Test
Test
Systems
Test
Production
Review
results

10. Development Environment
Assessment
May require a change in IDE
Progress iteratively, expand outward
Assume application compatibility
Assess apps, based on known issues
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
Planning
Skills
Development
Environment
Development
Environment
Runtime
Environment
Runtime
Environment
Code
Migration
Runtime
Migration
Unit Test
Test
Systems
Test
Production
Review
results

11. Test/Production/Review
Assessment
Run your standard test processes
Progress applications normally through the test environments
Ensure Performance is measured
Gather baseline measurement
Differences exist between WebSphere versions
JDK changes may have occurred
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
Planning
Skills
Development
Environment
Development
Environment
Runtime
Environment
Runtime
Environment
Code
Migration
Runtime
Migration
Unit Test
Test
Systems
Test
Production
Review
Results

12. Supported Migration Paths
Available paths:
WP Express  WP 6.1
WP X (recommended )  WP 6.1
Latest 2 v6.0 Portal Fixpacks
v and v
Migration is not a fixpack but a side by side operation, requiring a new install.
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.
Migration requires a new Portal installation and the tooling to transfer the configuration.

13. Components to Migrate
There are many components that must participate in the migration process
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
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.
v5.x/v6.0
Portal Server
v6.1 Portal Server

14. What is Migrated Automatically
Migration scripts attempt to migrate the following resources
WMM configuration – WMM attributes and associated database tables
Client configuration - Configuration information for all clients that are supported by WebSphere Portal.
Themes and skins configuration - Configuration information for themes and skins for WebSphere Portal.
Portlet Applications and portlets - Migration tasks are provided to facilitate deployment of the custom portlet applications.
Portlet configurations – Customized portlet application configuration is migrated.
Portal pages and places - The corresponding access control is migrated automatically with these artifacts.
User customizations –these are customizable settings that are associated with portlet instances.
Access control- Migration tasks migrate permissions page, porlet application, portlets, and user groups within the portal.
JCR Content – WCM and PZN data
The path you choose for migration will depend on factors such as migration needs, time available, skills available, and existing resources.

15. Agenda Overview Migration Preparing to Run Migration Scripts
Portal 6.1 Install
Prepare Prior Portal
Migration Process Overview
Framework
Problem Determination
Common User Errors and Best Practices

16. Portal 6.1 Install Migration is side-by-side
Prepare WP 6.1 Portal configuration
Enable security to match prior Portal
Users in directory must match
Run database transfer
Reference the Portal InfoCenter for a list of required fixes
PK69311
PK69096
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.
Migration is side-by-side
First, install the 6.1 Portal
Install Content server for migration where WCM is configured in the previous server
Foundation server install where WCM is not required
WP 6.1 can be on same machine or different machine
Operating systems must match
If 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.
With V6.1 it is easy to change the ports temporarily
Prepare WP 6.1 Portal configuration
If WAS security is not set to WMM Custom user registry set it to match prior portal configuration
If a CUR other than WMM is in use the customer will need to implement a CUR based on the VMM interfaces
LDAP or if Non WMM Custom User Registry is configured
Run database transfer

17. Portal 6.1 Install, Continued
Do not cluster 6.1 Portal
Federate after migration
Validate Portal function
Ensure login is possible
Set the WAS and Portal admin ID and passwords to match those from the previous version
Customizations to the v6.1 portal should be avoided, they will be removed or can cause problems during migration
Start with fresh install
Do not deploy portlets
Do not create pages
Do not change access control
Do not delete pages
Set up the new Portal to match the prior Portal configuration.

18. Prepare Prior Portal Backup previous WebSphere Portal
Good idea even though v5.x migration does not make any changes
Required if you want to be guaranteed you can revert back to your v6.0 system
Install required fixes
Currently Available in <PortalServer_v61>/migration/fixes
Forgetting to copy the ‘wps.properties’ file into the migration directory is an easy step to miss.
Known fixes at the time of GA are included in the v6.1 installed image
PK64247 – Augments the customization domain for migrations from v6.0

19. Prepare Prior Portal For v5.x Portals Disable user access
Set the portal to be active for read only access, this prevents the loss of updates while migration is executing.
If clustered, migrate from the primary node and prevent user access to that node during the execution of the portal-pre-upgrade task
Adjust HTTP server time out values to never time out, ideally the connection for the export process should use the internal WAS HTTP server port.
If using delegated user administration, 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, and specify the optional parameter to export groups when running the portal-pre-upgrade command.
Forgetting to copy the ‘wps.properties’ file into the migration directory is an easy step to miss.

20. Agenda Overview Migration Preparing for migration
Migration Process Overview
Migration Scenarios
JCR Data Migration
Validation
Framework
Problem Determination
Common User Errors and Best Practices

21. Migration Scenarios Portal configurations supported
Clustered
Standalone
Portal with process integration
Simplified over previous releases
High level perspective from v5.x
Export all portal artifacts
Import all portal artifacts
High level perspective v6.0
Export required portal artifacts
v6.0 includes direct reuse of database information in some portal domains
Import required portal artifacts
The migrate-all tasks combine the Portal configuration pieces. Other components still require the component migration tasks.

22. Migration Scenarios, Cluster migration
V5.x or v6.0 Deployment
Manager
Step 0
Initial configuration
Step 1
Migrate single node to standalone node
V5.1 or v6.0.1.x
Portal
V5.1 or v6.0.1.x
Portal
V5.1 or v6.0.1.x
Portal
V5.1 or v6.0.1.x
Portal
Step 2
Install Dmgr
Step 3
Federate node and create cluster
Step 4
Create additional cluster members
V6.10 Deployment
Manager
V6.10 Portal
V6.10 Portal
V6.10 Portal
V6.10 Portal

23. JCR Data Migration
Document Manager is no longer available in WebSphere Portal. Before migrating data, Web content previously stored as documents in a document library will need to be replaced with either file resource components or file resource elements stored in authoring templates, content items, sites or site areas
If document manager is in use, a solution to migrate PDM documents will become available in a future release of Quickr.
DB reuse when migrating from v6.0 eliminates the export/import of WCM and PZN data.
We consider these steps ‘optional’, because they are only run in some environments. For example, run ‘migrate-pdm’ only if using PDM.

24. Validation
Before clustering and resuming deployment, validate the migration
Verify the following components migrated correctly:
User attributes
User groups roles access control
Collaboration portlets
Clients
Pages and places
User customizations
Credential vault data
Themes and skins
Portlet applications
Portlet configuration
Virtual resources
Verify performance after clustering
Additional details, see the migration topic in the Portal v6.1 Infocenter.

25. Agenda Overview Manual Migration Preparing for migration
Migration Process Overview
Migration Scripts
Directory and file structure
Commands
Extended Migration Commands
v5.1 Additional Components
Filtering
How migration works
Problem determination
Common User Errors and Best Practices

26. Directory and file structure
The migration directory is located in <wp_root>/migration
Migration plugins live in <wp_root>/migration/components
This presentation is just an overview of Portal migration. Spend some time to understand the details.

27. Commands Automated core migration tasks:
portal-pre-upgrade – Executed against the source server
Run using the supplements CD if in a remote migration scenario
Run from the v6.1 installed image for same server migration
Generates a backup directory which contains the artifacts to move to v6.1
Portal-post-upgrade – Executed against the target server
Imports the old configuration into v6.1
Migration is extendable, currently this extensibility framework is not available for customer usage. The documentation and support is not ready for general use. L2 or L3 may provide patches through the extensibility framework.
Currently used by some components to provide IBM Portlet to JSR 168 conversion and to manage other changes in Portlets from release to release.
Additional custom migration tasks can be plugged into the migration framework.
Additional filtering can be added
Filters are often needed for Portals with a very large number of pages, to keep the exports manageable.

28. Extended Migration Commands
Deployment manager security migration
migrate-wmm-to-vmm – Executed on the primary node immediately after federation to restore security.
Copy backup dir to DMgr host under the same path where it exists on the primary node
update-nodetypes
ConfigEngine task
Use in the case where a “re-migration” of the JCR data is required
Filters are often needed for Portals with a very large number of pages, to keep the exports manageable.

29. V5.1 Additional Components - WCM
Install WCM migration tool
ConfigEngine configure-wcm-migration
Migrate all the WCM data
wcmmigrate all-data
Migrate WCM users
wcmmigrate users
Configure rendering portlets
wcmmigrate configure-local
wcmmigrate configure-remote
Remove the 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.

30. V5.1 Additional Components - PZN
Migrate from 5.1
WPmigrate migrate-pzn-50x
WPmigrate migrate-pzn-51x
Migrate exported 5.1 data
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.

31. How it works Migration from v5.x to v6.1 Migration from v6.0 to v6.1
Requires full export and import of all data
Very similar to v5.x to v6.0 migration
Migration from v6.0 to v6.1
New approach which allows for DB sharing and DB reuse
Significantly reduces down time some scenarios can be migrated with zero downtime
Filters are often needed for Portals with a very large number of pages, to keep the exports manageable.

32. How it works – DB Reuse approach
v6.0 portal
Connect to existing
user repository
LDAP
Install v6.1
portal
DB transfer release and
Community domains
Release
Execute Portal migration tasks
Move required v6.0 resources into the v6.1 portal
Shutdown previous Portal Server
Community
Community ..
Release
Action Set 2
MyPortal
Action Set 1
Content Node
Portal
Portlets
Content Nodes
Templates
Wps.content.root
My Portal
Applications …
Resource
prod.
Resource 2
prod
Resource 3
Resource y
Resource x
Resource1
value
Referential
Integrity DB
Schema
Resource 1
abc
Weak References
JCR
Connect to previous
customization,
LM,FB,Sync,
and copied JCR
domains
LM,FB,Sync
Copy JCR domain
Customization
JCR

33. Agenda Overview Manual Migration Preparing for migration
Migration Process Overview
Migration Scripts
Problem determination
Log files
Information to be Collected
Common User Errors and Best Practices

34. Log files Log files are created using the command line scripts
The logs created by the command line script help you debug migration process failures. The following log files are useful for debugging issues
<wp_profile_root>/PortalServer/log/MigrationTrace.log
<wp_profile_root>/ConfigEngine/log/ConfigTrace.log
Log files may refer to other files created in the migration backup directory.
XmlAccess import result files
This presentation is just an overview of Portal migration. Spend some time to understand the details.

35. Information to be CollectedOS
OS level
Fix packs
Portal levels – Including fix pack and iFix levels for previous and v6 Portal
Log files:
<wp_root>/log/MigrationMessages.log
<wp_root>/log/MigrationTrace.log
<wp_root>/migrationwizard.log
<wp_root>/migrationwizardlog.txt
All temporary work files and previous portal information used in the migration process. This includes the allout.xml, importAll.xml, template files, previous wpconfig.properties, etc…
Instruct the user to zip the Portal backup directory or a subset of the backup directory
This presentation is just an overview of Portal migration. Spend some time to understand the details.

36. Agenda Overview Manual Migration Preparing for migration
Migration Process Overview
Migration Scripts
Problem determination
Common User Errors and Best Practices
Limitations
Common Errors
Custom XmlAccess Migration
Portal Resources

37. Migration limitations
Manual recreation of all process tasks required if the customer is using WBI. WBI -> WPS conversion is not automatic. Limitation in the WPS product.
V5.1 Requires a re-write
V6.0 If using a local process container the migration complexity is high
XmlAccess can not migrate large numbers of users
Export requires a significant amount of resources.
Admin Portal access control is not migrated.
Permissions on default admin portlets must be manually recreated
Permissions on clones on non OOB admin pages do get migrated
Some cloned admin portlets may require the manual setting of configuration parameters
Changes to admin pages must be manually recreated.
Includes additional portlets added to pages, themes, skins, etc…
Admin page access needs to be recreated as well.
v5.10 transformations have been modified, there are manual steps required to fix the transformation.
There is no undo, the changes made during the migration process can not be automatically undone,
Imperative that the user backs up their initial portal configuration if it is faster than a reinstall.

38. Migration limitations
Migration of portlets within EAR files requires the user to manually deploy the portlets but not register them prior to executing the portal-post-upgrade migration command
Update the ear mapping file for custom deployment paths
Services and services settings are not migrated automatically.
Service jar files need to be manually redeployed
service-settings must be manually re-created
Some wires may not be migrated
Private wires for instance
Search indexes must be recreated
Taglib for people awareness has been changed in v6.1, requires updating in older themes
Not compatible with v5.1
V6.0 taglib slower performance
MS SQL Server 2000 is not supported
v6.0 must be upgraded to use MS SQL Server 2005 prior to migrating
Customized migration, by default is not part of the migration framework.
The migration framework allows customization code to be plugged in.

39. Common Errors and Best Practices
Information in the infocenter is not read and understood before migration is attempted.
All required pre-migration steps are not performed
Corrective service not applied to the previous Portal.
Attempting to connect through the HTTP server which times out and drops the connection.
This problem may occur during the export and may manifest itself on the during import, the symptom is an allout.xml that is not a properly formatted xml file.
Improper WAS admin uid/pwd specified
Improper Portal admin uid/pwd specified
Database URL not in the proper format for portal-pre-upgrade
release.DbUrl=jdbc:db2://<your db server>:50000/wps60db:returnAlias=0;
Should be:
release.DbUrl=jdbc:db2://superman2.raleigh.ibm.com:50000/wps60db

40. Common Errors and Best Practices (cont)
Current portal installation has not been verified.
User never attempted to log in
User is attempting to migrate into a clustered node, this is not supported
After federation of migrated node the security settings have disappeared
migrate-wmm-to-vmm task needs to be executed against deployment manager
Not enough memory is allocated to the process that is performing migration.
User resources not removed from portal when they have been removed from LDAP.
Execute the clean users task to re-assign ownership
Users do not restart the v6.1 Portal after migration, migrated themes and skins or pages may not show up properly
Attempting to migrate Portal on a machine with limited resources or other servers running on them. Severe resource contention will cause failures, timeouts on DB or LDAP connections

41. Common Errors and Best Practices (cont)
Rational Application Developer
Portal Toolkit v5/v6.0 projects must be migrated to a RAD which supports Portal v6.1 (TBD)
RAD can help with some manual portlet upgrade
Transfer LDAP users if needed
This is not recommended to be done before migration. The customer should migrate using the same user repository. The user should verify the migrated portal, then change the LDAP repositories.
For migration from v6.0, special care must be taken to propagate the extID if users must be moved into a new repository
Validate WMM configuration is valid before attempting migration
Ensure cross registry groups are not configured in WMM unless the backing registry supports this configuration
Ensure base entries exist
Ensure LDAP server information is valid
Deploy required SSL certificates in the default trust store for v6.1
Values in the WmmVmmDBMigration.properties not configured correctly
Need to specify the full DN for the previous portal admin user and group
DB driver needs to be same as what is used by WAS
DB driver must be copied to AppServer/lib directory
Old and new Portal and WebSphere user ID must be the same
Short login name and password must be valid in both the old and new portal
Custom versions of OOB portlets fail
Different war file names can cause a conflict when doing an update
WPCP does not exist in v5.1, so there is no migration path.
Add link to infocenter here

42. Common Errors and Best Practices (cont)
Custom content may require manual updates to get new function.
Custom themes and skins
Custom themes from v5.0 Express will require modifications
Changes in Search will require manual modifications to themes
Change to people component components will require manual updates to themes
Manual modification is required to take advantage of the v6.1 features such as drag and drop, fly out, context menus, etc…
Custom portlets
C2A Portlets and Struts portlets may require updating
Most other portlets should run as is
If the customer wants to upgrade their portlets, it is recommended they migrate their previous portal first then upgrade their portlets.
Custom xmlaccess scripts – XmlAccess is forward compatible.
If the customer has existing XmlAccess scripts they used to create their previous portal and they do not wish to perform a full migration, they can use the XmlAccess script used to set up their previous portal.
Other manual steps
Rational Application Developer – Refer to the Portal and RAD infocenter for migrating the development environment.
Redeployment of custom services
Custom content is the Portal resources that you develop – mostly custom portlets, themes, and skins.

43. Common Errors and Best Practices (cont)
Most custom portlets run unchanged on WP v6, portlets built that take advantage of WMM API’s will need modification
Migrating Struts and C2A portlets require repackaging with updated jars
Details on this conversion is covered in the infocenter.
If using CredentialVaultService.getDefaultUserVaultSegmentId() API
Migrating the credential vault is covered in the infocenter.
Change com.ibm.wps.util.ObjectId  com.ibm.portal.ObjectId
Portlets deployed using the portal interfaces are automatically migrated
Pre-deployed portlets now only need to be installed on v6.1
The details on this slide are mostly examples. Refer to the appropriate documentation when actually making updates.
Migration scripts will install custom portlets

44. Common Errors and Best Practices (cont)
Modified admin portlets cause failures
If a modified admin portlet has been deployed in a previous version, manual steps may be required.
Ensure DbSafe mode is not enabled when applying iFix PK64247
Ensure a backup is made for the <AppServer>/lib directory
Will be required to be restored if changes to the VMM DB repository configuration are needed and SqlServer and DB2 z/OS are used
WPCP does not exist in v5.1, so there is no migration path.
Add link to infocenter here

45. Custom XmlAccess Script Migration
Use of the WebSphere Portal migration scripts is not required, existing XmlAccess scripts may be sufficient, provided certain conditions are met
WMM UR is not in use
No customizations are enabled
No admin portlets are included in the deployment scripts
No dependencies on OOB content,
etc…
WebSphere Portal v5.x/v6.0 XML access scripts are fully compatible with WP 6.1
These scripts are compatible however the expected results after import may be unexpected. A full export of a previous server and import of the export into a v6.1 portal may not work.
Your v5.x/v6.0 XmlAccess scripts used to prime your previous portal will work on v6.1.
LPID -> GUPID my be an issue. The use of the identification mapping service may be required to create unique object ID’s in the new Portal.
How migration handles domains for v5.x migrations:
The content is automatically stored in the default domain, core migration does not explicitly set domain attributes
If you have v5.0 xmlaccess scripts, they only need updating if you want to take advantage of new features in v5.1.

46. Portal Resources
Best resource for migration commands

47. Portal Resources White papers for migration from v5.1 and v6.0
WebSphere Portal Documentation
6.1 Information Center:
(Preview)
Developerworks: WebSphere Portal Zone
Questions or concerns regarding the migration content in the WebSphere Portal 6.1 Information Center?
Please contact Mary Carbonara ) for further assistance
Migration Central - Support Web Site

48. Thank You
Questions & Answers