Archive for the ‘Quickr’ Category
Quickr 8.1.x to 8.5 Migration Issue
In order to migrate a source, or 8.1.1.1 Quickr server, it must be modified by the deployment of several recommended and required fixes. In the documentation at the IBM product documentation Wiki (available here) are instructions. At the time of this blog entry there is a line #5 stating that “the following Portal fix PM51981” should be applied.
This is not correct and the doc should be revised. Here are the details.
- The fix is for WebSphere Application Server and not for Portal.
- The fix is for WAS 6.1 and not 6.0. (Quickr 8.1.1.1 is deployed to 6.0)
- The fix SHOULD be applied to the target 8.5 server.
I suspect that in moving the documentation from the InfoCenter to the Wiki included a few unfortunate copy/paste errors of which this is but one.
Tip: IBM Quickr for WebSphere Portal 8.5 – Migration Strategies
Fundamentally there are two advertised approaches for migrating from Quickr for WebSphere Portal 8.1.1.1 to 8.5. One approach is to leverage the Backup & Restore functionality of IBM Quickr and another is to embrace a complete migration following a detailed procedure that migrates all places on a server. There is a potential issue with the former scenario that should not be overlooked. That is this: Be sure that all places to be restored have been backed up AFTER upgrading the “source” server to 8.1.1.1 and that each backup references the current page and portlet deployment of the system. Customers who rely on backups that are months or more old may be gravely disappointed when attempting to restore such places on their new 8.5 platform.
IBM Lotus Quickr for WebSphere Portal 8.5
A project underway this week involves an install of the Quickr product for WebSphere Portal. I did one of the earliest deployments of 8.5 a while back for a customer in Canada. The install process is highly scripted and this can be a blessing and a curse. What I like about the script is the reduced effort required to complete the install. What I do not like is that there are no stopping points where a snapshot might be taken to preserve the state of the install. Some of the tasks are very long running and when the process is highly scripted several hours may transpire before a failure occurs due to an error in the underlying environment. Because the install is scripted, the entire process must be repeated once the underlying issue is resolved.
Taking Notez - Island Pond Consulting 