CLM 2011 Upgrade Frequently Asked Questions
Rosa Naranjo, Jazz Jumpstart Team
Last updated: April 26, 2012
Build basis: CLM 2011, Rational Team Concert 22.214.171.124, Rational Quality Manager 126.96.36.199, Rational Requirements Composer 188.8.131.52
This article will present some frequently asked questions (FAQs) regarding the CLM 2011 Upgrade process as well as some known issues and workarounds, if applicable. Some of the questions or issues will be related to the overall upgrade process and some will be related to a particular application upgrade.
Here is some guidance on when to upgrade directly to 184.108.40.206 or upgrade from 3.0.1 to 220.127.116.11:
- Read the release notes associated with each product for information on fixes: RTC 18.104.22.168, RQM 22.214.171.124, and RRC 126.96.36.199.
- Requisite Pro migration with RRC is only available with RRC 188.8.131.52. See RRC 184.108.40.206 New & Noteworthy for details.
- Many data warehouse issues where Oracle is the DB vendor are fixed with RTC 220.127.116.11 and RQM 18.104.22.168, thus we strongly recommend that you upgrade directly to 22.214.171.124 if you are still using RTC or RQM 2.x or 3.0.1. The issues found range from errors in BIRT reports to missing tables in the DW schema for RQM 3.0.1.
- If using SQL Server 2005 as the DB vendor for the data warehouse, there was an issue in 3.0.1 that caused the STAR ETL job to fail. This results in a loss of trend data for trend based reports. This is now fixed with 126.96.36.199.
- RRC 188.8.131.52 fixes issues during upgrade related to Saved Filters, attribute groups with same identifier, external resources and issues with certain markup constructs.
- RTCz improvements related to promotion capability (other than component promotion for ALL components). See 169140 and 177648 for more details.
- What are the supported upgrade paths for CLM 2011?
- How many new databases will I need?
- Is there a specific order I need to upgrade in?
- Do I need to upgrade all my applications at once?
- Can I use Lifecycle Project Administration (LPA) with my 2.x applications?
- Do I need to update my current 2.x Eclipse/Visual Studio clients to the latest?
- Can I change server locations as part of the upgrade to CLM 2011?
- How can I change the public URI of my RTC/RQM/RRC or JTS server?
- I saw the article on jazz.net about link migration. Will that not fix everything?
- Is a public URI required in 3.x?
- I have changed the public URI and it seemed to work. What’s broken?
- Is there some set of SQL commands I can run in the database to fix everything?
- Can I use repotools export and import commands to do a server move?
- Can I move my database from one db server to another?
- I need to replicate a repository to a testing and staging environment. How can I do that if I cannot change the public URL?
- I have a test DB that I use to give demos. I thought I could use export and import to put this on different machines or share it with others. What can I do?
- Can I upgrade the applications to all use a shared JTS?
- Are there differences between a new CLM 2011 installation and an upgrade?
- Can I use the upgrade wizard of Installation Manager to upgrade to CLM 2011?
- Why does my server.xml have different EOL characters than the original one?
- Is it possible to complete an upgrade if I cannot mount drives in my existing 2.x environment?
- Do I need new licenses for CLM 2011?
- Can I upgrade to CLM 2011 from a previous v3.0.1 beta or milestone driver?
- Can my applications share a JTS if they use different authentication realms?
- Why is this upgrade so difficult? Will it always be like this?
- Do I need to update my RTC 3.0 clients?
- I have multiple RTC servers upgrading from 3.0 to 3.0.1. When do I instruct users to upgrade their RTC clients to 3.0.1?
- What Eclipse level is required for RTC 3.0.1 clients?
- Was the public URI required in RTC 2.x?
- Can I upgrade to RTC v3.0.1 and leave the JTS at v3.0?
- What will happen to my local work-item based requirements in RQM 2.x after I upgrade to RQM 3.0.1?
- What if some of these local RQM 2.x requirements came from RequisitePro?
- I upgraded to RRC 3.0.1 and notice that some data has not been migrated. What happened?
- I upgraded to RRC 3.0.1 and I notice that my browsing experience with IE8 is sluggish, what can I do?
- Is there any troubleshooting information available for a RRC 3.0.1.x upgrade?
- What changes, if any, are required if I have custom report templates for RPE in use wiht RRC v2?
- I have errors that mention ‘Invalid consumer key’ either in the RRC Web UI or the server logs or I noticed that the User interface controls are disabled in for the setup wizard. Is there any assistance for this?
- My online migration failed. What are my recovery options? Do I need to re-run the entire upgrade?
- Can I reuse an existing Rational Insight database as the common data warehouse?
- How is the reporting data handled when upgrading? (New)
- What is the meaning of ‘Data Mart’ mode vs ‘Data Warehouse’ mode on the Reports tab of the JTS Admin UI? (New)
- When a customer migrates, do they have to configure the data warehouse in the setup wizard? (New)
- Can the data warehouse be moved? (New)
Supported upgrade paths
- RTC 2.x -> RTC 3.0.1 which is equal to CCM 3.0.1 JTS 3.0.1 (new or shared among CLM 2011 applications)
- RTC 3.0 -> RTC 3.0.1 which is equal to CCM+JTS 3.0 to CCM+JTS 3.0.1
- RQM 2.x -> RQM 3.0.1 which is equal to QM 3.0.1 + JTS 3.0.1 (new or shared among CLM 2011 applications)
- RRC 2.x -> RRC 3.0.1 which is equal to RM 3.0.1 + JTS 3.0.1 (new or shared among CLM 2011 applications)
- JTS 3.0 -> JTS 3.0.1 (to allow installation of new apps independent of RTC 3.0 upgrade)
RQM 3.0.1 consideration
You can find the necessary requirements in the RQM upgrade documentation.
If you are upgrading from RQM version 2.0.1 iFix02 or higher, upgrade to version 184.108.40.206 or higher before exporting your 2.x data. Then, run the following repotools command to prevent potential errors with the export-import process.
Windows: repotools -repairRequests
Unix/Linux: ./repotools.sh -clean -repairRequests
NOTE: Users of versions prior to 2.0.1 iFix02 can ignore this step.
You can find guidance by referring to the upgrade topology examples.
For a full / new CLM deployment, you will need 4 databases: one each for the QM and CCM applications, one for the Jazz Team Server (JTS) and one for the data warehouse.
For an upgrade of all CLM 2.x applications, you will need new databases for the JTS and the data warehouse. For a RQM 2.x upgrade, it is recommended but not required that a new database be created. For a RRC 2.x upgrade, the RRC 2.x database will not be used in the 3.0.1 topology. The RRC 2.x repository will be migrated to the Jazz Team Server 3.0.1 repository database as part of the upgrade process.
For DB2 and SQL server:
You must use separate databases for each application and JTS, but they can be hosted on the same or separate database servers
- You will need to plan for 1 db user for each application (QM and CCM) and the JTS
- You will need to plan for 1 db user for the data warehouse
- You must use separate users for each app and JTS, but they can be hosted on the same database, separate databases, or separate db servers
- Using latest Oracle JDBC driver (currently 220.127.116.11.0) is required
Note: All CLM applications require the databases use UTF-8 for character encoding.
For most upgrades the answer is No. You can upgrade the applications in any order. However, there are outage considerations to be considered so plan the order in a way to minimize outage time.
One exception is in the case where the existing environment is using Rational Common Reporting or Rational Insight. Refer to this topic for more information: Reporting and the upgrade process
Refer to this topic for more information: Understanding the deployment and upgrade process.
No. In fact, we recommend a staged approach in order to manage the complexity and outages. Integrations to other 2.x products (RTC, RQM, RRC) will continue to work after any one of the CLM applications is upgraded to v3.0.1.
No. To benefit from LPA, applications must be at v3.0.x and be connected to a shared JTS. Once the applications are upgraded to v3.0.1, LPA is compatible with the existing projects.
Yes for RTC. If attempting to connect from a 2.x client, a dialog will open with instructions.
RQM and RRC clients are now web-based.
- The Eclipse and Visual Studio RTC 3.0 client and the ClearQuest synchronizer are compatible with CCM 3.0.1 (shared amongst several CCM instances).
- The build engines for z/OS need to be refreshed
Note: RTC 3.0.1 client is not compatible with RTC 3.0 server
I have multiple RTC servers upgrading from 3.0 to 3.0.1. When do I instruct users to upgrade their RTC clients to 3.0.1?
Instruct users to upgrade after you have upgraded the last RTC server. The RTC 3.0 client can operate either against a RTC 3.0 or 3.0.1 server.
RTC 3.0.1 clients are compatible with either Eclipse 3.5 or Eclipse 3.6. Please check compatibility with other co-located products.
- The application can be moved to different physical machines as long as they keep the same public server root URI
- Stable server URI can be preserved by DNS or reverse proxy.
It is not currently supported to change the public URI. Development is exploring possible workarounds for silo installations that will result in some data loss.
I saw the article on jazz.net about link migration. Will that not fix everything?
This was targeted to a specific use case where a Clear Quest (CQ) server is moved to allow fixing work item artifact links in the RTC repository. This is not a general purpose server move solution, although it will likely be a part of any solution available in the future.
It was, but it was not enforced. There may be instances where a server was configured without a public URI.
We recommend you set it, and choose a common stable URL that users have been using to access the server. An upgrade to v3.0.1 will fail without a public URI so you must configure a public URI for your RTC 2.x server prior to upgrading to v3.0.1.
Yes. We have added better guidance in the infocenter and in the server setup. Setup also performs more validation to discourage configuring a potentially unstable URL (e.g., using an IP address, short name, localhost, etc).
There are numerous internal references, such as links in opaque resources (dashboards, RTC enterprise extensions), project area URLs, user URLs, facts in the data warehouse, fully qualified URLs in plans or workitems, and others. The development team is assessing the impact and possible workarounds.
The structure of the database is an internal implementation detail. The table structure is optimized for reads, and thus item contents are stored in blobs. Additionally, the format of some resource content is opaque to the framework and component specific (e.g. binary, rdf, xml, etc). There is not a trivial solution mechanism to reliably process all the data in the database.
Repotools export and import commands are for database migration: e.g., migrating from one db vendor to another or from one version/platform of a database to another, where native backup and restore is not supported by the database vendor. Generally the offline backup and restore facilities provided by an enterprise db vendor will be much faster than repotools export and import.
There is currently not any processing in repotools export or import that will fix all URL references.
Yes. The database location is configured in the teamserver.properties configuration file, and it is not persisted anywhere else. Remember though that you want to minimize latency between the app server and the database server, and it is not recommended to distribute it over a WAN.
I need to replicate a repository to a testing and staging environment. How can I do that if I cannot change the public URL?
You can set up an isolated network where the hostnames are resolved to the test machine(s). See http://publib.boulder.ibm.com/infocenter/clmhelp/v3r0/topic/com.ibm.jazz.install.doc/topics/c_upgrade_staging_env.html
I have a test DB that I use to give demos. I thought I could use export and import to put this on different machines or share it with others. What can I do?
Choose a test host name for your URL, e.g, rtcdemo.example.org. Anyone executing the demo can add this entry to their local hosts file and resolve it to the loopback address.
Yes, but the database must have already been upgraded to be compatible with Rational Insight v18.104.22.168. You will need to upgrade Rational Insight first when planning a CLM 2011 upgrade.
- RTC data mart continues to work until the common data warehouse is configured via JTS setup and the first ETLs run. When the Java ETLs run for the first time, (that is, when they detect empty target tables), they attempt to fill them in with historical information:
- For Work Items, the history is re-computed from scratch, and there is no need to consult the data mart.
- For SCM and Build data, there is a one-time migration of data from data mart to the data warehouse which preserves data history.
- RQM upgrade requires additional repotools commands to be run. Refer to this topic for more information: Migrating report data from version 2
- Existing Rational Common Reporting (RCR) or Rational Insight users should upgrade first before configuring the data warehouse.
What is the meaning of ‘Data Mart’ mode vs ‘Data Warehouse’ mode on the Reports tab of the JTS Admin UI?The reporting framework has a service property named “Data Warehouse Provider” which can have one of two values. These values affects which data warehouse is populated (the RTC 2.x-era warehouse, called ‘data mart’, or the new CLM 3.0.1.x warehouse called “data wareouse”), which ETLs run, and where BIRT reports get their data.
The new warehouse covers the entire CLM domain, whereas the data mart covers only the RTC/CCM domain and is primarily meant for those who wish to continue using BIRT with their existing RTC 2.x reports and do not plan to adopt RRDI. The out-of-the-box RQM BIRT reports do not work in data mart mode.
The com.ibm.teamserver.*.datawarehouse.provider teamserver property values are as follows and correspond to the mode visible from the Reports tab of the JTS Admin UI:
- Local (Data Mart Mode). This is the RTC 2.x-style behaviour, where the old-style data mart Java ETLs run and store information in the data mart. BIRT reports get their data from the data mart.
- Remote (Datawarehouse Mode). This is the default on a new CLM 2011 installation. The new Java ETLs run and store information in the new data warehouse. BIRT reports get their data from the data warehouse. In order to access the CLM data, it is recommended that RRDI be used instead. If you wish to keep the BIRT reports, it is still possible
Note that even in Remote mode, some information is still stored in the local data mart, including the repository sizing/count information (we don’t have tables for these in the data warehouse), so it doesn’t truly get rid of the data mart.
If you plan to move to RRDI (and hence CLM), use the new warehouse. It is an integral to the out-of-the-box reporting of CLM configurations.
Back to top
work item 160608). Thus, if you start with your DW in Oracle, it cannot later be moved to DB2. It is important to contrast the supported database vendors of CLM 3.0.1.x and RRDI since there are some database vendors that are supported for CLM 3.0.1.x but not supported by RRDI 1.0.2. For example, SQL Server 2008 R2 is not supported by RRDI. Once you select the DW for your CLM 3.0.1 environment, it cannot be moved without some loss of data.
Back to top
No. If you have a distributed topology where the CCM and JTS applications were not in the same app server, you must upgrade the Jazz Team Server (JTS) to v3.0.1 prior to upgrading the CCM application (version 2.x or 3.0).
Yes. Applications can be upgraded to all use a shared JTS. However, existing application instances still need to be deployed to distinct app servers to preserve URL stability and avoid collisions on the ‘/jazz’ context root.
You must decide in the beginning of an upgrade where your JTS is located. It cannot be changed later.
Note: There can only be one RM application per JTS.
Yes. A new installation can share the same application container because of the use of distinct 3.x context roots. An installation for the purposes of an upgrade cannot share the same application container due to collisions on the 2.x application context roots (/jazz).
Note: The installer provides a panel to select using either the 3.x or 2.x context roots.
No. The upgrade wizard path is NOT supported. A side-by-side installation or installation on a different machine must be completed in order to begin the upgrade migration process.
This applies to Windows Tomcat users. During the first phase of the upgrade process, there are configuration files that are migrated from a 2.x or 3.0 application instance. The upgrade process asks the user to compare the updated/migrated configuration files with the original ones. For one of these files, server.xml, there is an issue with the EOL characters which makes them different.
There is a bug in the xalan transformer code that causes the updated server.xml file to have incorrect EOL for comments. If one opens the updated server.xml in notepad (vs another editor which will correctly interpret the LF characters and display it correctly) it is very unreadable. Using a more advanced editor will allow things look correct.
Yes, it is possible. Please refer to this article that discusses Advanced Upgrade scenarios: Advanced Upgrade Scenarios
Yes. There is a new licensing model for CLM 2011 that requires new licenses be installed. However, RTC 3.0 licenses WILL continue to work with RTC 3.0.1.
No. This is not supported.
No. All applications that will share a common JTS must use a common authentication realm. For instance, if one application uses LDAP for authentication, all applications must use LDAP. The key issue is that the user IDs must match when migrating to a common JTS.
The upgrade from the Jazz 2.x products to 3.x introduces a change to the basic Jazz deployment architecture, but not to the logical architecture. The big change is the addition of the JTS as a real component of the deployed architecture. The JTS provides central administration including licensing and users. In the past, the JTS functions were dispersed in each of the Jazz products, and thus administrative duties had to be replicated in each collaborating product. Now as the Jazz products begin to get more widely deployed and adopted by our customers (and IBM as well), an individually deployed JTS allows us to scale more easily, and allows a greatly simplified administrative experience.
We don’t anticipate doing any more radical changes to the architecture in the future, so this should be the last time that the upgrade experience is this complex. In the future we look to have the JTS, and all of the Jazz applications, be N+1 and N-1 compatible. This will allow our customers to upgrade their Jazz applications one at a time, for a more orderly and measured upgrade experience.
In RQM v3.0.1, requirements are no longer managed locally. They are managed in RRC v3.0.1. There is a process which will migrate existing local work-item based requirements to a RRC v3.0.1. It is documented via this link: Migrating work-item based requirements.
Note: You must install and configure RRC v3.0.1 prior to running this upgrade step.
If you had IBM Rational RequisitePro requirements in RQM v2.x, follow this additional process to ensure that the requirement data in testing artifacts is accurate after the migration to RQM v3.0.1: Migrating Rational RequisitePro requirements
This could be the result of an issue with the way attribute group IDs were mapped in RRC 2.x when there were multiple RRC 2.x projects with attribute groups having the same group ID. It is common to have two or more projects with custom requirement types of the same name. When a RRC 2.x setup has this characteristic, artifacts with those types are not visible in 3.0.1 after the upgrade. This is fixed with 22.214.171.124, thus upgrading directly to 126.96.36.199 would be the solution here. See 46656: RRC 2.x to 3.0.1 migration – AttributeGroups can map onto AttributeDefinitions from other projects for more details.
Back to top
I upgraded to RRC 3.0.1 and I notice that my browsing experience with IE8 is sluggish, what can I do?There is a memory leak when IE 8 is used with RRC 3.0.1. Use Firefox 3.6 instead or ask support for additional information and options. See
Back to top
RRC3UpgradeErrors. For any future updates related to RRC 3.0.1.x upgrade, periodically check the parent page: RRC3Upgrade
Back to top
Back to top
I have errors that mention ‘Invalid consumer key’ either in the RRC Web UI or the server logs or I noticed that the User interface controls are disabled in for the setup wizard. Is there any assistance for this?See this technote for details:
Troubleshooting issues with OAuth in consumer keys in Rational Requirements Composer version 3.0.1
Back to top
Back to top
For more information
Here are some links to other Jazz.net articles and workshops that are available to assist with the CLM 2011 migration process.CLM 2011 infocenter
SupportCLM Upgrading Knowledge Collection technote
Check the IBM Support portal for other technotes related to upgrade or the 3.0.1.x applications you have deployed.
About the author
Rosa Naranjo is a member of the Jazz Jumpstart team. The Jazz Jumpstart team is a worldwide group of development specialists who bring new and advanced Jazz-based technologies to customers. Please direct feedback and comments to firstname.lastname@example.org
Copyright © 2011 IBM Corporation