95
Today's blog post covers tips and tricks to ease Portal/WCM migrations.
1. Migrate once, clone everywhere
Typically the overall setup consists of multiple environments - a development, test, staging and production system. Depending on your requirements you might have less or more environments.
Instead of migrating every one of those environments to their according new target systems our recommendation is to migrate one system and then use staging to production to move the Portal content (and WCM content if WCM is being used) to the other environments. The system that would be migrated is the system that has the current set of data - e.g. the Production system (in case WCM being used the Authoring system would be the source).
For more information see:
http://www-01.ibm.com/support/knowledgecenter/SSHRKX_8.5.0/mp/migrate/mig_multiple_envs.dita
https://www.ibm.com/developerworks/community/blogs/portalops/entry/staging_to_production_portal_8_without_paa?lang=en
2. Missing existing Features after Migration
A set of portlets has been moved from being part of the install onto the Catalog. This does not mean that you have to move away from those features but that you will have to separately download the according feature. The link to the catalog is:
https://greenhouse.lotus.com/catalog/
For more information see:
http://www-01.ibm.com/support/knowledgecenter/SSHRKX_8.5.0/mp/migrate/mig_removed_portlets.dita
http://www-10.lotus.com/ldd/portalwiki.nsf/xpDocViewer.xsp?lookupName=IBM+WebSphere+Portal+8+Product+Documentation#action=openDocument&res_title=Portlets_no_longer_available_wp8&content=pdcontent
3. Missing new Features after Migration
After a migration, to guarantee backwards compatibility, not all of the new features are enabled. We document the steps to install the new features in the InfoCenter.
Instead of choosing this path and to add the new features later on a different path can be chosen to minimize the effort to enable new features:
As discussed in step 1. finish the migration to a single target system. From that target system use staging to production but only move the custom data - content, pages, portlets, ... to a target system that was installed from scratch without migration. After that you will have all the new features installed plus the custom data applied to it. Note that custom WebSphere Application Server settings or similar would need to be moved as well.
For more information see:
http://www-01.ibm.com/support/knowledgecenter/SSHRKX_8.5.0/mp/migrate/mig_plan_exp_v_tol.dita
4. Fast path for Portal only setups
If the system you are migrating from does not have WCM and no page customizations it can be faster to use XMLAccess to move the custom pages / portlets to the new system as well as deploy custom EAR files (theme, ...) than going through a full migration cycle. Note that there is limited support for this path: Support will not assist in determining the tasks that need to performed to manually migrate using xmlaccess. If you are familiar with XMLAccess though and build the deployment in the first place you can compare the scripts between the releases and customize if needed if you feel comfortable with that approach.
5. Fast path for WCM only setups
If the system you are migrating from only has WCM and does not use any Portal pages it can be faster to use the cross version syndication capability to just move the content across. Note that that would only work if you do not have your content as part of the Portal Site library. You would need to move custom WebSphere settings, ear files, ... manually as well.
Note that there is limited support for this path. Also if your JCR database is very large and holds a vast amount of content this approach will not be feasible due to the required time.
For more information see:
http://www-10.lotus.com/ldd/portalwiki.nsf/xpDocViewer.xsp?lookupName=Cumulative+fix+readme+8.0.0.1#action=openDocument&res_title=Using_crossversion_syndication_to_migrate_from_Web_Content_Manager_version_7.0_cf8001&content=pdcontent
6. Enabling WAB after a migration
If you need to enable WAB on a migrated system (Portal 6.1 to Portal 8.0) you can run the following ConfigEngine task. Replace <password> with the according password.
ConfigEngine.bat / ConfigEngine.sh action-create-library-wp.vwat.engine action-create-resource-environment-provider-wp.vwat.engine action-create-resource-environment-provider-custom-property-wp.vwat.engine action-deploy-portlets-admin-wp.vwat.manager action-create-ear-wp.vwat.servlet/ear action-deploy-portlets-wp.vwat.webdock -DPortalAdminPwd=<password> -DWasPassword=<password>
7. JSF Migration
Starting with Portal 8 the underlying WebSphere Application Server has JSF 2.0 as the configured Out of the Box JSF library. If you were using JSF 1.2 in the system you were migrating from there are a few options to go ahead:
- Run JavaServer Faces 1.x portlet project as-is on WebSphere Portal Server v8.0 or later using IBM JavaServer Faces 1.x portlet bridge
- Enable JavaServer Faces 1.x portlet project to run on JavaServer Faces 2.0 implementation in WebSphere Portal Server v8.0 or later
- Upgrade JavaServer Faces 1.x to JavaServer Faces 2.0 portlet applications
For more information see:
http://pic.dhe.ibm.com/infocenter/radhelp/v9/index.jsp?topic=%2Fcom.ibm.portal.doc%2Ftopics%2Ftjsf20_Migration_page.html
Link to the Migration documentation:
8.5: http://www-01.ibm.com/support/knowledgecenter/SSHRKX_8.5.0/mp/migrate/migration.dita
