Upgrade and migration
In this chapter, we discuss the upgrade and migration of FileNet Content Manager environments. You learn about the best practices for planning, performing, and documenting upgrades and migrations.
We discuss the following topics:
11.1 Terminology
Specific terminology is used in the P8 Information Center and by the IBM FileNet Support teams for updating a FileNet Content Manager environment. Understanding the terminology enables you to make informed decisions about your update process choices and the effort involved with each type of change.
11.1.1 Packages
There are several package types that you can apply to your FileNet Content Manager environment:
•New software release
•Modification (mod) release
•Fix pack
•Interim release
•Test fix
Software release
A new software release introduces new features and functionality, adds and removes support for infrastructure elements, resolves client-reported issues, and adds and removes support for components that interact with FileNet Content Manager.
Although new functionality might be added and existing functionality changed or removed, the new software release maintains compatibility with an earlier version for any application programming interfaces (APIs). However, APIs can be marked as “deprecated”. Deprecated APIs eventually are removed.
Mod release
A mod release, or service pack, provides a small set of new features, as well as resolutions to client-reported issues. The mod release provides a roll-up of fixes that are available in previous update packages, as well as fixes that are released for the first time.
Fix pack
A fix pack provides a roll-up of authorized program analysis report (APAR) resolutions that were previously provided as interim fixes, test fixes, or in a previous fix pack, as well as fixes not previously released. Each fix pack contains fixes from previous releases.
Interim fix
An interim fix provides the resolution to a few APARs, usually one, that are likely to be needed by multiple clients.
Test fix
A test fix, or limited availability fix, provides the resolution to a small number of APARs, usually one, that are required by a specific client. Test fixes are also known as limited availability fixes. If you need this type of fix, IBM provides you with specific download information and a password for extracting the fix package.
Interim fix and test fix packages are similar. The primary difference is the size of the target audience for the package.
11.1.2 Package naming conventions
P8 Content Manager software releases use a four-digit identifier:
<major release>.<minor release>.<mod release>.<fix pack>
The major release, minor release, mod release, and fix pack numbers are incremented based on the software package.
Software release
Software releases can be considered major or minor releases. The designation of major or minor is arbitrary, but in general, it tries to convey the quantity of changes introduced by the software release.
Examples:
•5.0.0.0 indicates that the package is major release 5 of the software.
•4.5.0.0 indicates that the package is minor release 4.5 of the software.
Mod release
Mod releases are identified by the third digit in the four-digit identifier.
Examples:
• 5.1.1.0 indicates that this package is the first mod release for the 5.1 software level.
• 4.0.2.0 indicates that this package is the second mod release for the 4.0 software level.
Fix pack
Fix packs are identified by the fourth digit in the release level and the notation FPxyz, where xyz identifies the number of the fix pack.
Examples:
•5.1.0.2-P8CE-FP002 is the first fix pack that is on top of the Content Engine 5.1 release.
•1.1.5.2-WPXT-FP012 is the 12th fix pack on top of the FileNet Workplace XT 1.1.5 release.
Interim fix
Interim fixes are identified by the notation IFxyz at the end of the package name, where xyz identifies the number of the interim fix.
Examples:
•5.1.0.0-P8CE-IF004 is the fourth interim fix on top of the Content Engine 5.1 release.
•5.1.1.2-P8CE-IF001 is the first interim fix on top of Content Engine 5.1.1 fix pack 2.
Test fixes are identified by the notation LAxyz at the end of the package name, where xyz identifies the number of the test fix.
Examples:
• 4.0.2.4-P8eF-LA001 is the first test fix on top of fix pack 4 for the eForms 4.0.2 release.
• 1.1.4.6-WPXT-LA003 is the third test fix on top of fix pack 6 for the FileNet Workplace XT 1.1.4 release.
11.1.3 Installation rules
The P8 Information Center provides details of the supported upgrade paths:
Always refer to the product release notes, the readme file, and the IBM FileNet P8 Hardware and Software Requirements guide to determine whether there are specific prerequisites that must be met before installing the software.
 
Tip: The readme file might also direct you to the appropriate installation and upgrade sections in the P8 Information Center for some of the procedural information.
Major, minor, and mod releases contain full installers. Therefore, they can be installed on a system that has no previous version of the software installed, as well as on top of an earlier version of the software.
In some cases, such as FileNet Workplace XT, fix packs are also full installations. In other cases, such as with IBM Content Navigator, the fix packs must be installed on top of the product release that is indicated in the fix pack name. All fix packs are cumulative, which means that you can skip fix pack levels.
Interim fixes and test fixes are not usually cumulative; instead, they contain files that must be applied, often manually, to a specific level of software. To verify the content of the package and to determine any prerequisites, see the readme file that is supplied with the interim fix or test fix.
 
Caution: Before upgrading an environment that is updated with a test fix, check the readme file of the newer software update package to ensure that the package contains the fix that was originally provided by the test fix. If the test fix is not explicitly listed, check with your IBM representative for information about when the test fix will be made generally available. If necessary, request that a new version of the test fix is generated that is compatible with the newer software update package.
Software updates cannot be uninstalled independently or separately from uninstalling the associated product component. The exception to this rule is the packages that are installed by manually copying files. These updates can be “uninstalled” by copying the older versions of the files over the newer versions of the files, and by reversing any other steps described in the readme file that is associated with the update package.
11.1.4 Update types
Three terms are used to describe updating a FileNet Content Manager environment:
•Update
Refers to applying a small change, such as a fix pack, interim fix, or test fix to the environment. And, update is also used as a general term to cover any changes made to the environment, including upgrade and migration.
•Upgrade
Refers to applying a new release to the environment, such as moving from Content Engine 5.1 to Content Platform Engine 5.2. In an upgrade, there is no change in the hardware that is used by the components.
•Migration
Refers to applying a new release to the environment and redeploying the software on new hardware or in a new software configuration. Software configuration changes can include changing application server, moving components to new operating systems, and moving to a new database management system.
Updating, upgrading, and migrating FileNet Content Manager are standard maintenance tasks and need to be scheduled on an on-going basis. These changes need to be coordinated with other system maintenance tasks, such as updating application server levels and applying operating system fixes.
Another term that is frequently used when discussing upgrade and migration is staging. Staging can be used in two ways:
•Breaking the upgrade or migration into multiple steps that will be performed at different times so that, for example, the upgrade is completed over multiple maintenance windows.
•Using an interim set of servers on which to perform some of the upgrade and migration steps. The staging servers are frequently used to test portions of an upgrade or migration by using production data.
Figure 11-1 illustrates the process flow for a migration upgrade.
Figure 11-1 FileNet Content Manager upgrade migration flow
11.2 Planning for updates
The goal for any update is to make the change as transparent as possible to your users.
Updates usually must occur in a predefined maintenance window. The length of the maintenance window might vary between corporations, by type of change, and by the environment in which the update is being made. But in all cases, you want the update to complete in the prescribed maintenance window and with minimal impact to your customers. Planning and practice are the keys to every successful update project.
The planning effort includes these steps:
•Know your starting point.
•Know your desired endpoint.
•Understand what might be affected because of the desired endpoint.
•Detail the steps in the update, including the answers to these questions:
 – Who will perform each step?
 – How long will each step take?
 – What kinds of issues might occur?
 – What are the remedial steps for any potential issues?
 – What tests must be performed to validate that the update was successful?
Practicing the steps of the update provides the data for building the detailed plan and expanding the expertise of the team that is responsible for the update tasks. When rolling out an update, the learning and the practice happen on non-production systems. If the update includes moving to new hardware, that is, performing a migration, the practice can also occur on the new hardware with copies of production data.
11.2.1 Getting started
Before you perform any type of update in a FileNet Content Manager environment, ensure that you are prepared:
•Know the current levels of all the software in the environment, including the operating system, database, application server, and directory server so that you can validate that these software components are at a level that is compatible with the FileNet Content Manager software that you are planning to install. Your review needs to also include all third-party applications and other IBM components, such as IBM Content Collector, that interact with the P8 Content Manager environment.
•Obtain the latest fix pack readme file and release notes for the FileNet Content Manager components that are being updated.
Readme files can be downloaded from IBM Fix Central. The release notes are published in the P8 Information Center under Troubleshooting and support → Release notes and what’s new.
•Review the FileNet P8 Fix Pack Compatibility Matrices to determine whether the package that you want to install is compatible with the other FileNet P8 components in the environment. Download the matrices from this website:
•Review the IBM FileNet P8 Hardware and Software Requirements guide to determine whether the package you want to install is compatible with the underlying technologies in use in your environment. The guide can be downloaded from this website:
If you are planning an upgrade or migration, also review the “Planning and Preparing” section of the P8 Information Center and take the time to complete the installation worksheet and to build a customized version of the upgrade instructions. The worksheet and instructions for building a customized upgrade guide can be accessed from the following page:
11.2.2 Practicing the update
Most clients have several FileNet Content Manager installations so that development and testing can occur in non-production environments. Updating these environments serially reduces the risk of introducing a change that has a negative impact on your production environment, and it also allows you to practice the update process.
The order in which you update the environments can be different depending on the update being installed. Table 11-1 illustrates the order in which you might perform an update, assuming you have the following five environments:
•Development
•User acceptance test
•Performance test
•Preproduction
•Production
Table 11-1 Update order
Type of update
Software release
Mod release
Fix pack
Interim fix
Test fix
Development
1
1
1
3
3
User Acceptance
2
2
2
4
4
Performance
3
3
3
5
5
Preproduction
4
4
4
1
1
Production
5
5
5
2
2
Because interim fixes and test fixes are often installed to address an issue encountered in the production environment, it is important to get the change installed into the production environment as quickly as possible, but also as safely as possible. We advise that you install the change initially into an environment running the exact same software as the production environment, and then promote the change to production.
Practicing the update in this fashion has the following advantages:
•Refines the installation process that is needed at your site.
•Trains the resource staff who will ultimately perform the update in the production environment.
•Allows the project manager to develop a realistic schedule for the update.
•Identifies issues that might occur during the installation and any associated workarounds.
•Provides an opportunity to build an appropriate test suite to ensure that your applications work correctly after the update.
 
Recommendations: Test suites need to cover functional, stress, and performance testing.
11.2.3 Documenting the process
Using the customized upgrade documents generated from the P8 Information Center or the readme files provided with the software update packages, build an update document for your site that captures the following information:
•The process used
•Issues encountered and their workarounds
•Timelines
•Resources used; that is, the people involved in the update, their roles, and the time required
 
Recommendations: Ensure that at least two people know how to perform each task.
•Test process followed
The document will form the basis for future update projects.
11.3 Upgrading to a new software release
Upgrading to a new software release is a major project that usually takes several months because in addition to installing the new software, you must validate the following information:
•Existing applications work as expected; this task includes checking for deprecated APIs and reworking the code as needed.
•Performance and throughput are not adversely affected by the upgrade.
An upgrade is often the time to introduce new functionalities in the FileNet Content Manager components and custom applications, new hardware, and new underlying technologies.
Depending on the starting point and endpoint of the upgrade, you can choose how to install it:
•Stage the upgrade; that is, complete the upgrade over more than one maintenance window.
•Perform a “big-bang” upgrade; that is, complete the upgrade in a single maintenance window.
Whatever plan you choose to adopt, leave enough time in the plan for these activities:
•Backup and restore activities
At a minimum, take backups before you start the upgrade activity and after the upgrade completes.
•Testing
The test activities include functional, performance, and stress testing.
 
Tip: If you have a disaster recovery site, ensure that your plan includes breaking any synchronization links at appropriate points in the upgrade process, upgrading the software on the disaster recovery hardware, and re-establishing the synchronization links.
11.3.1 Staging the upgrade
To determine whether staging an upgrade will work for your environment, evaluate the following areas:
•What is the different mix and match of software components that are supported?
For example, if you move to the FileNet Content Manager 5.2 release, are the versions of FileNet Workplace XT, IBM Content Navigator, or IBM Enterprise Records currently in use in your environment compatible with the FileNet Content Manager 5.2 release? If they are, you can choose to upgrade to the new Content Platform Engine, but leave the other applications at their current levels.
•Are you moving to new hardware as part of the upgrade?
If so, you can install the new P8 Content Manager software on the new hardware and after the installation is validated, initially test the upgrade process by using copies of the production object stores, workflow systems, and file storage areas.
After the initial validation is complete, point the environment to the actual production databases and file storage areas and allow the update to complete.
•Are there clear delineations in the resources that are used by your applications?
If you are replacing all the hardware in your current production environment and there is a clear delineation in the resources used by your applications, you can choose to run with two production environments in parallel but on different release levels. In this model, you copy over the object stores, workflow systems, and file storage areas that are used by each application in stages.
For more information about taking this type of approach, see the following technote:
 
11.3.2 Big-bang upgrade
With a big-bang upgrade, the goal is to update the existing environment to the latest release levels all in a single maintenance window. Often, this upgrade process is followed because the upgrade is taking place on the existing hardware.
To be successful with this type of upgrade in addition to practicing the upgrade to ensure that it can be completed in the required window, you must also have a roll-back plan. If the upgrade runs into an issue that cannot be resolved in the maintenance window, you can bring the old environment back online and limit the impact to your clients.
11.4 Migration best practices
If the upgrade involves moving to new hardware or changing the type of application server, database server, or LDAP server, the upgrade is called a migration. If you are moving to new hardware, the new hardware can be running the same or a different operating system as the existing hardware.
When you perform a migration, use the following best practices:
•Ensure that all servers are referenced by a domain name server (DNS) alias rather than an IP address.
This enables the change in server to be invisible to the clients. However, ensure that you consider the amount of time that is required for the change to replicate across the network.
•If moving databases from Oracle or SQL Server to DB2, work with IBM Lab Services on the data migration.
•If moving to a new LDAP server, ensure that all user and group references are updated correctly.
Consider testing the change by setting up a new P8 domain (at the same software level as the existing P8 domain) with the LDAP server and using the FileNet Deployment Manager to map users and groups. FileNet Deployment Manager will attempt to map the users and groups automatically, and flags any users or groups that do not appear to have a match in the destination environment.
 
Tips:
•If moving to a new type of LDAP server, consider engaging IBM Lab Services to help with the migration because they have expertise and special tools to help with this type of migration.
•If you perform the upgrade on new hardware, copy the Content Manager configuration file from the existing production system to the new hardware, and use it when running the upgrade of the Content Engine or Content Platform Engine.
11.5 Special considerations for upgrade
Two specific changes are introduced in the FileNet Content Manager 5.2 release that require special consideration.
Support for Legacy Content Search Engine is dropped
Content Search Services (CSS) was first introduced in the FileNet Content Manager 5.0 release as a replacement for the Legacy Content Search Engine. CSS provides similar functionality to Legacy Content Search Engine but is based on Lucene technology and uses a different query language.
Content indexes created by using Legacy Content Search Engine cannot be migrated to CSS indexes, instead the content must be reindexed.
Content Engine 5.1 supports running both Legacy Content Search Engine and CSS. Therefore, the indexes that are required by CSS can be generated as a background task. When the reindexing is complete, applications can start using the new indexes without affecting clients who are performing content-based retrievals.
 
Note: Applications that use content-based retrieval (CBR) must be updated to use the query language syntax that is compatible with CSS.
Content Platform Engine 5.2 supports CSS only. If content has not already been reindexed by using Content Platform Engine 5.2, clients will be unable to perform content-based retrievals until the reindexing is complete.
If there is a period of time where it is acceptable that content is not indexed, upgrade directly to Content Platform Engine 5.2. Otherwise, upgrade to Content Engine 5.1 before you upgrade to Content Platform Engine 5.2.
Content Engine and Process Engine servers are combined into a single engine called Content Platform Engine
In the FileNet Content Manager 5.2 release, the Content Engine and Process Engine capabilities are merged into a single engine called Content Platform Engine.
If you are performing an in-place upgrade, Content Engine and Process Engine must be upgraded together.
One side benefit of merging the two engines is that the two client installers (one for Content Engine and one for Process Engine) also are merged. Therefore, the number of installation programs that need to be run is further reduced.
11.5.1 Reference information
The following documents provide useful information about upgrades and migrations. Some of the documents reference specific release levels of the P8 Content Manager software, but they can often be generalized to work with all levels:
•White paper: IBM FileNet P8 Platform Installation and Upgrade Best Practices
•Simultaneously Upgrading and Migrating Content Engine
•Best Practices for FileNet P8 3.5.2 to P8 4.5.1.2 Upgrade with Replatforming (Windows to UNIX)
•What adjustments can I make to FileNet Content Engine (CE) Automatic Upgrade?
11.6 Conclusion
In this chapter, we discussed the update types and the best practices to follow to ensure a timely and successful update.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset