Interactive upgrade guide

Complete the planning checklist

Use this planning checklist to ensure that you are ready to upgrade.

	Planning task	More information
	Use the software product compatibility reports: On this page, you can search and generate reports for a specific product. The information includes prerequisites, product translation into a specific language, end of service, server virtualization environments, and more.	Software product compatibility reports
	Gather required information: Before starting the upgrade process, you must gather and record specific data that is required during the upgrade process, such as URLs, user IDs and passwords, database locations, name of databases installed, and so on.
	Verify that your hardware and software meet the minimum system requirements: New requirements exist for version , and a few older versions might be deprecated. To learn about the new requirements and to see whether your system meets the minimum requirements, click the System requirements link.	System requirements
	Get the product installation media: For a local repository download, you need approximately 5 GB of hard drive space to download and extract your product installation media.	You can download the server installation files from jazz.net or Passport Advantage.
	Review an upgrade topology example.	Distributed enterprise topology Standard single-server departmental topology
	Synchronize the clocks on all servers: In a distributed environment, ensure that the clocks on all servers are synchronized by using the Network Time Protocol (NTP).	For more information about NTP, visit ntp.org
	Understand the upgrade process: Learn about the upgrade process and how the upgrade might affect your deployment.	Understanding the deployment and upgrade process
	Plan for your applications to be unavailable: Your applications will be unavailable for a brief period while you back up everything and update your applications to version . All of the applications that are connected to will be offline while is offline. Be sure to provide time to completely back up your existing applications.
	Meet your database prerequisites: You can access the previous release database and copy the derby/repositoryDB directory. You have the correct user name and password. On UNIX systems, use the password for the Db2 instance owner, which is typically the db2inst1 user. Before you start the upgrade process: For each application that you are upgrading Make sure you have applied the latest iFix for the version you are upgrading from. Verify the integrity of the repository databases by running the Online Verify tool. You can start the Online Verify tool from the application interface by using the https://://onlineVerify link. You backed up your database before you started the upgrade process. It is recommended to discuss with your database administrator (DBA) to determine what values are appropriate within the context of your Enterprise setup. When altering the `BUFFERPOOL`, make sure you reset to the original value when you run `db2 get db cfg` after the upgrade. IBM Db2i® database is preconfigured on your IBM® i system. Creat a backup of your IBM Db2 for z/OS® database before the upgrade. You have the correct user name and password. Before you start the upgrade process: Verify the integrity of the database by running the -verify repotools command. Verify the integrity of the repository databases by running the Online Verify tool. Change the COMPATIBE setting for the database to 12.2.0 or later by running: `alter system set COMPATIBLE='12.2.0' scope=spfile; shutdown immediate startup mount ALTER DATABASE OPEN;` You backed up your database before you started the upgrade process. For more information about backing up databases, see your database vendor documentation. The required Java Database Connectivity (JDBC) driver is `ojdbc8.jar`. You backed up your database before you started the upgrade process. For more information about backing up databases, see your database vendor documentation. The required Java Database Connectivity (JDBC) driver is `ojdbc8.jar`. Restriction: Because of a defect in Oracle JDBC driver 12.1.0.2.0, this version of the driver cannot be used. For details, see repotools -createTables command fails with ORA-01000 on Oracle 12 on the IBM Support portal page. You created an environment variable named ORACLE_JDBC_DRIVER_FILE and pointed to the JDBC driver. To avoid performance issues, ensure that Oracle Bug ID 13077335.8 is applied and enabled on the Oracle system hosting . See the Oracle documentation for details. Make sure you have sufficient TEMP tablespaces with the ability to auto-extend if necessary. If you do not have enough TEMP space, the upgrade might fail with the following message: `ORA-01652: unable to extend temp segment by 128 in tablespace TEMP`. You have the correct user name and password. Before you start the upgrade process: Verify the integrity of the database by running the -verify repotools command. Verify the integrity of the repository databases by running the Online Verify tool. If the current database version is not supported, perform the following steps: Perform the pre-requisite steps to upgrade. Backup the current database. For information about backing up databases, see your database vendor documentation. Upgrade the backend database to the supported version. Run the repotools upgrade commands in the newer version You backed up your database before you started the upgrade process. For information about backing up databases, see your database vendor documentation. You ensured that the Java Database Connectivity (JDBC) driver is installed, and you are using sqljdbc42.jar. You created an environment variable named SQLSERVER_JDBC_DRIVER_FILE and pointed to the JDBC driver. In previous versions, the Requirements Management data was stored as RDF text in the database. In the new release, the data is directly stored in the backing database without deleting the old RDF data. As a result, the database requires double the space. Ensure that you have adequate disk space on your database server for this data growth. Important: Before you start the Quality Management - application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours. Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows: DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL EXEC sp_updatestats EXEC DBMS_STATS.GATHER_DATABASE_STATS For information about the Db2 database REORGCHK command, see the Db2 website. For information about the Oracle database DBMS_STATS command, see the Oracle website. For information about the SQL Server database Update Statistics command, see the SQL Server website.
	Learn about licensing: Click the link to learn about licenses in this release. Important: You need to obtain new license for . See the "Obtain licenses" step for details.	Managing licensing
	Check the browser compatibility: Enable JavaScript in your web browsers so that wizards can be displayed. For web browsers that are used for migrations, make sure that pop-up blockers are disabled.
	Check the client and server compatibility: must be at the same level as or newer than the applications that are registered with it, but the applications cannot have a newer version than .	For more information, see Client and server version compatibility
	Check your Java Virtual Machine options: Make sure that the Java Virtual Machine has the appropriate heap size setting. If you are installing all applications on one server for trial or demo, ensure you have enough memory installed. The JVM settings for the server can be adjusted in the server.startup file. To set these properties in WebSphere Integrated Solutions Console, click Servers > Server Types > WebSphere application servers > server1. Under Server Infrastructure, click Java and Process Management > Process definition. Under Additional Properties, click Java Virtual Machine. In the Generic JVM arguments field, check that the following lines exist: -Xmx4g -Xms4g -Xmn1g -Xgcpolicy:gencon -Xnocompressedrefs -Xmx4g -Xms4g -Xmn1g -Xgcpolicy:gencon Tip: If you need more heap size, then you can use the following setting, replacing {N} with the amount of memory to be used and {N/4} with 1/4 of the total memory. For example, if -Xmx is set to 8g, -Xmn should be set to 2g. -Xmx{N} -Xms{N} -Xmn{N/4} For Lifecycle Query Engine only: If Lifecycle Query Engine application pages become unresponsive as a result of memory issues, see this technote for troubleshooting. For only: The -Xmn value should be 33% of the -Xmx value. For example, if the -Xmx size is 4gb, the -Xmn should be 1365m. In addition, for large deployments you should increase the Xmx value in the repotools files from the default 1500M to 8192M or higher. This increase in the Xmx value is necessary to improve performance and avoid out of memory errors during the execution of repotools -reindex all command. For more information on how to adjust the repotools command, see the technote link in the More information column. Before you upgrade the application, make sure you verify the Jena index. Validate the indexes using the repotool_rm verifyJFSIndexes command. If the Index verification reports an error, rebuild the Jena indexes using the repotools-rm -reindex all command.	Technote: Running the "repotools-jts -reindex all" or "repotools-rm -reindex all" command results in Java out of memory CRJZS5856E errors in Sizing and tuning guide for 6.0: configuration management repotool_rm verifyJFSIndexes repotools-rm -reindex all command

Stage a test environment for the upgrade process

Note: Do not copy the text indices. Starting in version 6.0.6.1, the Apache Lucene full-text search engine was upgraded to a more recent version. As a result, all existing full-text search indexes that were created in 6.0.6 or earlier must be rebuilt. For details, see this workaround article.

Migrating ELM from WebSphere Application Server to WebSphere Liberty

Engineering Lifecycle Management version 7.0.0 - 7.0.2 supports two application servers; WebSphere® Application Server and WebSphere Liberty. The support of WebSphere Application Server is no longer available in ELM starting with version 7.0.3. Due to this change, you must migrate ELM on WebSphere Application Server to WebSphere Liberty. You must migrate from WebSphere Application Server to WebSphere Liberty before you upgrade to ELM version 7.0.3

Before you begin

Download and install a new instance of ELM in parallel with your existing installation. Ensure to select the option to install WebSphere Liberty Profile. This installation must be the same version as your current application version. The new installation deploys WebSphere Liberty Profile with most of the required settings preconfigured to run ELM applications. It is recommended that each application run on its own server or at least its own WebSphere Liberty Profile (for process isolation). Each profile has its own JVM resources. For detailed installation instruction, see Interactive Installation Guide.

You must stop the WebSphere Application Server before starting the WebSphere Liberty instance.

About this task

The task does not include component-specific WebSphere Application Server to WebSphere Liberty migration steps because there are parts of WebSphere Application Server configurations that do not exist or are not needed in WebSphere Liberty.

Migrating ELM configuration files

Stop the WebSphere Application Server.
If you have your server setup as a service, ensure to disable automatic startup. Once the migration from WebSphere Application Server to Liberty completes, you might want to remove the application server service. See instruction in step 4 from here.
Back up your databases.
Copy the entire content of the OLD_ELM_install\server\conf\app directory (used by WebSphere Application Server) to the New_ELM_install\server\conf\app directory (WebSphere Liberty), replace the existing files.

Liberty Configuration files update

About this task

Although the embedded Liberty Profile comes with most of the required settings to run the ELM applications, there are the following settings that need to be configured manually:

Procedure

If your ELM WebSphere Application Server installation is configured to use LDAP as the user registry, perform the following steps:

User Registry

Start the Liberty server:
1. (For Linux)Change directory to New_ELM_install/server Run the ./server.startup script
2. (For Windows) Change directory to New_ELM_install/server Run the server.startup.bat script
Follow the steps to configure LDAP connection in WebSphere Liberty.
If the ELM WebSphere Application Server installation is configured to use the default internal user registry, you must migrate the user records to WebSphere Liberty. See, Configuring a basic user registry for Liberty.

Certificate

The security certificate bundled with ELM applications is self-signed to localhost. If your ELM installation on WebSphere Application Server uses a certificate from a well-known or corporate-trusted certificate authority, you must import these certificates into the keystore that is used by the WebSphere Liberty Profile.
The keystore file is located in New_ELM_install\server\liberty\servers\clm\resource
- The file name for CLM 6.x is ibm-team-ssl.keystore
- The file name for ELM 7.x is ibm-team-ssl.p12
- For instructions on how to import certificates into the WebSphere Liberty Profile keystore, see Receive Certificate and Add it to Keystore.
If you have IHS and use self-signed certificates for your ELM applications, perform the following steps to extract the certificate from the WebSphere Liberty installation and import it into IBM HTTP Server (IHS). The example shown assumes that the host name, domain name, and port number for WebSphere Liberty Profile installation is myelm.com:9443.

(For Linux)

Run the following command on the WebSphere Liberty server where ELM is installed:
openssl s_client -connect myelm.com:9443
From the output, copy the certificate only (see the sample certificate at the end of this document). Be sure not to include spaces or any other text.
Create a certificate file (for example elm.crt) by pasting the copied text in a text editor and saving the file.
Open ikeyman from IBM HTTP Server directory (/opt/IBM/HTTPServer/bin/ikeyman).
Open the keystore referenced by your plugin-cfg.xml file (and enter the keystore password).
Import certificate by using iKeyman.
Restart IHS (/opt/IBM/HTTPServer/bin/apachectl stop/start/restart).

(For Windows)

Open a browser session from a machine where ELM on WebSphere Liberty is being accessed.
Navigate to the Certificate Manager section, click Servers, and then select myelm.com:9443.
Click Export to extract the certificate into a certificate file (for example elm.crt).
Open ikeyman within IBM HTTP Server directory (C:\IBM\HTTPServer\bin\ikeyman).
Open the keystore referenced by your plugin-cfg.xml file and enter the keystore password.
Import certificate by using iKeyman.
Restart IHS (C:\IBM\HTTPServer\bin\apachectl stop/start/restart).
Sample certificate:
-----BEGIN CERTIFICATE----- MIIDGTCCAgGgAwIBAgIEFInHnjANBgkqhkiG9w0BAQsFADA9MQswCQYDVQQGEwJ1 czEMMAoGA1UEChMDaWJtMQwwCgYDVQQLEwNjbG0xEjAQBgNVBAMTCWxvY2FsaG9z dDAeFw0xNzA1MTMxMDA5MzdaFw0xODA1MTMxMDA5MzdaMD0xCzAJBgNVBAYTAnVz MQwwCgYDVQQKEwNpYm0xDDAKBgNVBAsTA2NsbTESMBAGA1UEAxMJbG9jYWxob3N0 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl5hSpIR+gmyX8t8Cei02 b9GilUqkdfpWZ5kkJaRmJraLKdPlLMPhEEuIfYEb2cKl3livGMVUfZkxgXLNL7rN UOemBaDb882R66sAJ1MZOYAQ976QGRY59hnGiXcX2d7KndCqXmtF7qw6BPS6R7nX 6nog4P7tMjV1XFY6N6aN5OL6URBaPwf+7EDWPIF7vVlSDM6CFOAWHqt8HjyeGMPO Rcnmwg21+NhcUwT467mneEWyavgevdNcfRLm9FOjdwRGZnCnqhcjDKkd9yRyjI8h QS2IFPRQVWLPVRQJxDBKBU66k7xhv68bpW4sdkVni26UPzoxQrXNVjETGFxWxfaJ QQIDAQABoyEwHzAdBgNVHQ4EFgQUdEkGyXMjCHunNJi3aHAxdIzpYn4wDQYJKoZI hvcNAQELBQADggEBAI+A7EffStJJC8+wKbulLaesqOED1eml9JY6kqL7ltMI0HEG WRGbYNK0htHmQtzOaHM8gAHd5X5RxHZhOhbaTQ+CH2C4b0MJ+gl9hJGIvt28yiW2 tS4s/Dt1IJ8Cy7/Xz84YJ1VPn4oFy36lJTGgSM+Bg6aItbbx9vNOflDf8C6tyZbg ujMxF2o6BBeKCdBM+Aft164l2uFmVBGIgYQv2aWBNTmxirr72mZnLgo8vGUqc/nA 1T/CJIz8dq6byclfiOjCBkqDr4XlcXtbD6yjdlRqTusiJ17iZvlNPpoYoGGjqS9z JhKmsi2mxWzz7a5ZgsdiK6u+1sn/55MWAabz23I= -----END CERTIFICATE-----

Special instructions for upgrading on IBM i

Record server name, profile name, node name, heap size values, and previously installed application names

During the upgrade you need to know some information about your current environment. Make sure you record the following information.

Log on to WebSphere Application Server Integrated Solutions Console.
Expand Servers > Server types, and then click WebSphere Application Servers.
Record the server name and node name.
Click server1, expand Java and Process Management and then click Process definition > Java Virtual Machine.
Record the values under Generic JVM arguments.
Expand Applications > Application types, and then click WebSphere Enterprise Application.
Record the names of the following installed applications:

(jts_war)
(ccm_war)
Quality Management (qm_war)
(rm_war)
(relm_war)
Global Configuration Management (gc_war)
Link Index Provider (ldx_war)
Report Builder (rs_war)
Lifecycle Query Engine (lqe_war)
Data Collection Component (dcc_war)

Repair multiple versions of an artifact marked as current in the configuration

If you used Configuration Management in 6.0.2 or earlier versions of Requirements Management or Quality Management applications, if multiple users updated an artifact in a configuration at the same time, inconsistent versions of the artifact might be displayed in the configuration. This problem occurs because multiple versions of the artifact are internally marked as the current version. For example, you might experience the following issues:

Different views show different versions of an artifact for the same configuration.
An artifact cannot be found.

This issue no longer occurs in version 6.0.3 and later, but might be present in those versions if you upgraded from an earlier release. You can run the following query to detect if a configuration has more than one current version of an artifact:

SELECT DISTINCT CONFIGURATION_ITEM_ID FROM VVCMODEL.VERSION WHERE CURRENT_COL = 1 GROUP BY CONFIGURATION_ITEM_ID, CONCEPT HAVING COUNT(CONCEPT) > 1

SELECT DISTINCT CONFIGURATION_ITEM_ID FROM VVCMODEL_VERSION WHERE CURRENT_COL = 1 GROUP BY CONFIGURATION_ITEM_ID, CONCEPT HAVING COUNT(CONCEPT) > 1

If the query finds more than one current version, open a command windowshell and enter the following commands:

Important: The -repairMultipleVersionsMarkedAsCurrent repository tools command is available in the latest Interim Fix of each release. You must apply the latest iFix before you can use the command. If you run the query and there are more than one current version of an artifact but the -repairMultipleVersionsMarkedAsCurrent repository tools command is not available, do not upgrade to version .

For Requirements Management

cd \/server
repotools-rm.bat./repotools-rm.sh -repairMultipleVersionsMarkedAsCurrent credentialsFile=credentials.properties

Sample credentials.properties file:

adminUserId=yourAdminUserId
adminPassword=yourAdminPassword
repositoryURL=https://hostname.example.com:port/rm
smartCard=<none>
certificateFile=<none>
kerberos=<none>

For Quality Management

cd \/server
repotools-qm.bat./repotools-qm.sh -repairMultipleVersionsMarkedAsCurrent credentialsFile=credentials.properties

Sample credentials.properties file:

adminUserId=yourAdminUserId
adminPassword=yourAdminPassword
repositoryURL=https://hostname.example.com:port/qm
smartCard=<none>
certificateFile=<none>
kerberos=<none>

For

cd \/server
repotools-rm.bat./repotools-rm.sh -repairMultipleVersionsMarkedAsCurrent credentialsFile=credentials.properties

Sample credentials.properties file:

adminUserId=yourAdminUserId
adminPassword=yourAdminPassword
repositoryURL=https://hostname.example.com:port/rm
smartCard=<none>
certificateFile=<none>
kerberos=<none>

For Quality Management

cd \/server
repotools-qm.bat./repotools-qm.sh -repairMultipleVersionsMarkedAsCurrent credentialsFile=credentials.properties

Sample credentials.properties file:

adminUserId=yourAdminUserId
adminPassword=yourAdminPassword
repositoryURL=https://hostname.example.com:port/qm
smartCard=<none>
certificateFile=<none>
kerberos=<none>

For more information about the repairMultipleVersionsMarkedAsCurrent repository tools command, see Repository tools command to repair multiple versions of an artifact marked as current.

Depending on the size of your database, the utility might take a while to scan the entire database. The server must be running when you run the repository tools command and no restart is required after the command is complete.

If you are prompted for the following message, you can safely ignore it:

repair: YYYY-MM-DD HH:MM:SS,### [Number of configurations] Configurations Modified. Please shutdown the server and run the reindex command.

Move the or application to a new location

In order to perform the migration of the or applications that are installed into the same group, two instances of the application must be installed into a target folder. However, does not allow to install two or more instances of the same application into the same group. You can use server rename to move either the or application into a separate installation folder.

If you are using a reverse proxy in your deployment, see the following resources:

Understanding reverse proxy

In order to perform a server rename procedure, you must install a separate application along with your old installation. There are two options for installing the application:

Install the application on the same server as the old application: In this case, you must change the port number during the rename process.
Install the application on a separate server as the old application: In this case, you must change the fully qualified hostname during the rename process.

Examples:

In the following examples, the installation folder corresponding to the existing 6.x is referred to as old_install_dir, and the new 6.x that you will be installing for server rename is referred to as new_install_dir.

The application is deployed in

The following procedure is for the basic registry to manage users. For LDAP, see Configuring an LDAP or an LDAP/SDBM connection.

Install 6.x (the same version as the existing installation) into a new folder (new_install_dir). Ensure to select Install with WAS Liberty.
Prepare a mapping file for the server rename procedure:
1. Ensure the existing server is up and running.
2. Open a command window and enter the following commands:
  cd old_install_dir (Server 1)\server
  repotools-jts.bat -generateURLMappings toFile=MAPPINGS.TXT adminUserId=adminUserId adminPassword=adminPassword repositoryURL=https://hostname:port/jts
  
  cd old_install_dir (Server 1)/server
  ./repotools-jts.sh -generateURLMappings toFile=MAPPINGS.TXT adminUserId=adminUserId adminPassword=adminPassword repositoryURL=https://hostname:port/jts
3. Update the generated MAPPINGS.TXT file: Comment out or remove the source and target lines for applications that should not be renamed and keep only one pair related to the application:
  source=https://hostname:old_https_port/am
  target=https://hostname:new_https_port/am
  
  Note: new_https_port is a random port number that should manually be changed since it is not automatically added to the generated mapping file.
Veify the MAPPINGS.TXT file by entering the following command:
repotools-jts.bat./repotools-jts.sh -verifyURLMappings mappingFile=MAPPINGS.TXT adminUserId=adminUserId adminPassword=adminPassword repositoryURL=https://old_hostname:port/jts
Go to the old_host/server and stop the server.
Back up the existing source environment.
Go to the new_install_dir/server and enter the following command to create the server.
repotools-am -help

This command creates the new_install_dir/server/liberty/servers/clm/ folder.
Copy the application indices and configuration files into the new installation folder:

xcopy /s old_install_dir\server\conf\am\indices new_install_dir\server\conf\am\indices

xcopy old_install_dir\server\conf\am\teamserver*.properties new_install_dir\server\conf\am

xcopy old_install_dir\server\conf\am\am.properties new_install_dir\server\conf\am

cp -R old_install_dir/server/conf/am/indices new_install_dir/server/conf/am/indices

cp old_install_dir/server/conf/am/teamserver*.properties new_install_dir/server/conf/am

cp old_install_dir/server/conf/am/am.properties new_install_dir/server/conf/am
Copy the Apache Derby® database:
First, enter the following command to delete the new_install_dir Apache Derby® database:

del /s /f new_install_dir\server\conf\am\derby\repositoryDB

Enter Y to confirm the delete operation.

rm -rf new_install_dir/server/conf/am/derby/repositoryDB

Then, enter the following command to copy the Apache Derby® database:

xcopy /s old_install_dir\server\conf\am\derby\repositoryDB new_install_dir\server\conf\am\derby\repositoryDB

cp -R old_install_dir/server/conf/am/derby/repositoryDB new_install_dir/server/conf/am/derby/repositoryDB
Copy the basicUserRegistry.xml file:
xcopy old_install_dir\server\liberty\servers\clm\conf\basicUserRegistry.xml new_install_dir\server\liberty\servers\clm\conf

cp old_install_dir/server/liberty/servers/clm/conf/basicUserRegistry.xml new_install_dir/server/liberty/servers/clm/conf
Copy the ltpa.keys file:
First, make a backup and delete the ltpa.keys file from the old_install_dir server:

del old_install_dir\server\liberty\servers\clm\resources\security\ltpa.keys

rm old_install_dir/server/liberty/servers/clm/resources/security/ltpa.keys

Then copy the ltpa.keys file to the new server:

xcopy old_install_dir\server\liberty\servers\clm\resources\security\ltpa.keys new_install_dir\server\liberty\servers\clm\resources\security

cp old_install_dir/server/liberty/servers/clm/resources/security/ltpa.keys new_install_dir/server/liberty/servers/clm/resources/security
Go to the new_install_dir/server/liberty/servers/clmnew_install_dir\server\liberty\servers\clm folder and open the server.xml file for editing.
Modify the HTTP and HTTPS ports:
<httpEndpoint id="defaultHttpEndpoint"
host="*"
httpPort="<new_http_port>"
httpsPort="<new_https_port>" />

Note: <new_http_port> is a random port number for HTTP protocol.
Uninstall the application form the old_install_dir. Ensure that am.war and am.war.zip files are deleted from the following folders:
old_install_dir/server/liberty/servers/clm/appsold_install_dir\server\liberty\servers\clm\apps
old_install_dir/server/liberty/clmServerTemplate/appsold_install_dir\server\liberty\clmServerTemplate\apps
Go to the old_install_dir/serverold_install_dir\server folder and create a file called serverConf.txt with the following content:
#RMM
new_install_dir/server/conf
Copy the ImportUMLMappings.activate file to the old_install_dir/server/confold_install_dir\server\conf folder.
Open a command window and enter the following commands:
cd old_install_dir\server
repotools-jts.bat -importURLMappings fromFile=MAPPINGS.TXT serverConfFile=serverConf.txt

cd old_install_dir/server
./repotools-jts.sh -importURLMappings fromFile=MAPPINGS.TXT serverConfFile=serverConf.txt
Verify that the rename is successful by checking the console output and the jazz_install_dir/server/\server\repotools-jts_importURLMappings.log file.
Start both servers:
cd old_install_dir\server
server.startup.bat

cd old_install_dir/server
./server.startup

cd new_install_dir\server
server.startup.bat

cd new_install_dir/server
./server.startup
Log in to and open the following URL in a browser:
https://hostname:old_https_port/jts/serverRenameStatus
Verify that the Rename process completed successfully by going through all the project areas that are in read only mode. Check that all application friend URLs are correct.
After verifying everything, select the checkbox to remove the read only mode and complete the rename process.

Install the new version applications

Install the new version applications into a new package group, but do not run the setup wizard. For distributed configurations, install the version applications that correspond to the previously installed applications.

At this point, you can also install the new applications that you did not have in your previous deployment, such as Jazz Reporting Service, Global Configuration Management, and so on. The setup of the upgraded and newly installed applications is completed in a later step.

For information about installing the server, see Installing by using IBM Installation Manager or Installing by using command-line commands.

Install the version applications, but do not run the setup wizard after the installation. For distributed configurations, install the version applications that correspond to the previously installed applications. For information about installing the server, see Installing on IBM i using licensed programs.

Note: You must also install the trial license keys if you use the Enterprise Extension builds.

The extension can be installed in two modes: Model Management Server and Model and Code Management Server. When you are prompted to select the Rhapsody Model Management Deployment mode, choose the mode applicable to your deployment topology. To understand the difference between these two modes as well as to define a list of required licenses, see Client access license management. Select Model and Code Management Server mode, if you use the functionalities provided by application that are not listed for inclusion in Model Management Server mode in your current deployment.

Note: In a clustered environment, you can install a new () application on each node and modify the properties files, or install a new application on the first node and, after modifying the files, copy the entire installation directory to the other nodes and change the node ID.

For the application:

Ensure to install with the application.
When you are prompted to select a context root option, choose Use your own context root values (advanced) and enter your previous application context root. For example: /am.
The extension can be installed in two modes: Model Management Server and Model and Code Management Server. When you are prompted to select the Rhapsody Model Management Deployment mode, choose the mode applicable to your deployment topology. To understand the difference between these two modes as well as to define a list of required licenses, see Client access license management. Select Model and Code Management Server mode, if you use the functionalities provided by application that are not listed for inclusion in Model Management Server mode in your current deployment.

Important: Before upgrading, make sure you apply the latest interim fix to your current installation. After you install version , apply the latest interim fix for version if any. This ensures that your new version applications are up-to-date. Make sure you run the repotools-clean command after the application is updated with the patch and restarted before running the addTables command. To check if there are any interim fixes available for your product, visit Fix list for IBM Engineering Lifecycle Management.

Important: Before upgrading, make sure you that you have the latest IBM i OS and Java fixes applied to your system. See IBM i PTFs.

Important: If you use SameSite-enabled browsers, you must edit the server.xml file to add the samesite tag. See Customize the WebSphere Liberty server for SameSite for more details.

Configuring ELM on stand-alone WebSphere Liberty Server

ELM is shipped with an embedded WebSphere Liberty server to ease the installation process. However, you can also configure ELM to deploy ELM applications on a stand-alone WebSphere Liberty server. There are certain configurations that you need to do to deploy ELM on stand-alone WebSphere Liberty server.

Navigate to the Server folder.
For example, if the ELM applications are installed at C:\ELM_Liberty_Setup\JazzTeamServer_1 location. The Server folder is available within the JazzTeamServer_1 folder.

For example, if the ELM applications are installed at /opt/IBM/JazzTeamServer_1 location. The Server folder is available within the JazzTeamServer_1 folder.
Update value of the following properties in the liberty.server.bat liberty.server.shfile:
- The CLM_LIBERTY_HOME property must point to the Liberty folder of the WebSphere Liberty server. For the example, the WebSphere Liberty server is installed at C:\Program Files\IBM\WebSphere\Liberty property must be: CLM_LIBERTY_HOME=C:\Program Files\IBM\WebSphere\Liberty
- The CLM_LIBERTY_SERVER_DIR property must point to the servers folder in the WebSphere Liberty server you recently installed. For example, CLM_LIBERTY_SERVER_DIR=C:\Program Files\IBM\WebSphere\Liberty\usr\servers\%CLM_LIBERTY_SERVER_NAME%
- The WLP_USER_DIR property must point to the WebSphere Liberty server user directory. For example, WLP_USER_DIR=C:\Program Files\IBM\WebSphere\Liberty\usr
- Optional: The CLM_LIBERTY_SERVER_NAME property to change the name of the server. For example, CLM_LIBERTY_SERVER_NAME=clm
- The CLM_LIBERTY_SERVER_TEMPLATE property to move the ELM server template to the new WebSphere Liberty server. For example, CLM_LIBERTY_SERVER_TEMPLATE=C:\Program Files\IBM\WebSphere\Liberty\templates\clmServerTemplate
- The CLM_LIBERTY_HOME property must point to the Liberty folder of the WebSphere Liberty server. For the example, the WebSphere Liberty server is installed at /opt/IBM/WebSphere/Liberty property must be: CLM_LIBERTY_HOME=/opt/IBM/WebSphere/Liberty
- The CLM_LIBERTY_SERVER_DIR property must point to the servers folder in the WebSphere Liberty server you recently installed. For example, CLM_LIBERTY_SERVER_DIR=/opt/IBM/WebSphere/Liberty/usr/servers/%CLM_LIBERTY_SERVER_NAME%
- The WLP_USER_DIR property must point to the WebSphere Liberty server user directory. For example, WLP_USER_DIR=/opt/IBM/WebSphere/Liberty/usr
- Optional: The CLM_LIBERTY_SERVER_NAME property to change the name of the server. For example, CLM_LIBERTY_SERVER_NAME=clm
- Optional: The CLM_LIBERTY_SERVER_TEMPLATE property to move the ELM server template to the new WebSphere Liberty server. For example, CLM_LIBERTY_SERVER_TEMPLATE=<JazzHome>/server/Liberty/clmServerTemplate
Optional: If you want to use the WebSphere Liberty server's JRE instead of the ELM server's JRE, you must update the following properties in the server.startup.bat and server.shutdown.bat files:
- The JAVA_HOME property should point to the Java directory of the WebSphere Liberty server. For example, JAVA_HOME=C:\Program Files\IBM\WebSphere\Liberty\java\11.0 JAVA_HOME=/opt/IBM/WebSphere/Liberty/java/11.0
- The JRE_HOME property should point to the jre directory of the WebSphere Liberty server. For example, JRE_HOME=C:\Program Files\IBM\WebSphere\Liberty\java\11.0\jre JRE_HOME=/opt/IBM/WebSphere/Liberty/java/11.0/jre

Increase temporary tablespace in Oracle for large repository

If you have a large Quality Management application repository with millions of artifacts, the default temporary tablespace QM_TEMP is not enough to handle the temporary files. You must add an additional temporary tablespace to avoid issues. To create an additional temporary tablespace, open a SQL *Plus window and log in as SYSTEM or SYSDBA and enter the following command:

alter tablespace QM_TEMP add tempfile 'ORACLE_BASE/oradata/CLMDB/QM_TEMP2.DBF' size 20m reuse autoextend on next 1m maxsize unlimited;

Where QM_TEMP is the temporary tablespace name, ORACLE_BASE is the absolute path where Oracle is installed, CLMDB is the database name, and QM_TEMP2.DBF is the additional temporary file name that you want to create.

Optional: Increase Db2 configuration settings for large repositories

If you have a large Quality Management application repository with millions of artifacts, you can increase some of the Db2 configuration settings to ensure that a successful data migration is achieved. The examples given here are for a repository of about ten million artifacts. Adjust the values according to the size of your data repository. Open a Db2 command window and enter the following commands to increase the configuration settings:

db2 update db cfg for QM using APPLHEAPSZ 60000
db2 update db cfg for QM using LOGFILSIZ 4096
db2 update db cfg for QM using LOGPRIMARY 50
db2 update db cfg for QM using LOGSECOND 100

Optional: Maximize the Quality Management application upgrade performance and execution

If you have a large Quality Management application repository with millions of artifacts, you can minimize the upgrade time and maximize the upgrade performance by adding the following Java system variables to the repotools-qm script file:

Number of threads for migrating the version table records: You can increase the number of threads (default value 30) for migrating the version table records. For example:

DEFINE="$DEFINE -Dcom.ibm.team.repository.service.internal.rdb.AbstractDatabaseService.ThreadPoolCount4MigratingVTables=40"

set DEFINE=%DEFINE% -Dcom.ibm.team.repository.service.internal.rdb.AbstractDatabaseService.ThreadPoolCount4MigratingVTables="40"

Thread timeout duration in hours: You can also set the timeout duration (default value 12 hours) for thread execution time. For example:

DEFINE="$DEFINE -Dcom.ibm.team.repository.service.internal.rdb.AbstractDatabaseService.ThreadTimeoutHours4MovingRecords=16"

set DEFINE=%DEFINE% -Dcom.ibm.team.repository.service.internal.rdb.AbstractDatabaseService.ThreadTimeoutHours4MovingRecords="16"

Increase the default heap size: For large repositories, the default heap size in the repotools-qm is too small. You must increase the heap size to 8 GB (up to a maximum of 24 GB) to avoid issues during the upgrade.

To increase the heap size, in the repotools-app.bat file, search for :default_mx_size and update its value to VMARGS=%VMARGS% -Xmx8G in the repotools-app.sh file, set VMARGS="$VMARGS -Xmx8G".

Optional: Online migration of quality management data

The Quality Management application online migration is an optional upgrade step that is done while the old server is still running. It migrates data in the live repository to reduce the amount of downtime incurred during normal migration. The data is migrated in such a way as to not affect users on the existing server.

Procedure

Before you start the Quality Management application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours.
Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:

DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL

EXEC sp_updatestats

EXEC DBMS_STATS.GATHER_DATABASE_STATS

For information about the Db2 database REORGCHK command, see the Db2 website.
For information about the Oracle database DBMS_STATS command, see the Oracle website.

For information about the SQL Server database Update Statistics command, see the SQL Server website.
On the server on which you installed the new version of the Quality Management application, open a command window and enter the following command to estimate the data to migrate and to evaluate whether the online migration is appropriate for the repository.
The teamserver.properties parameter must point to an absolute path on the old server.

cd \server\

repotools-qm.bat -onlineMigrateEstimate teamserver.properties=\server\conf\qm\teamserver.properties logFile=repotools_onlineMigrateEstimate.log

cd /server

./repotools-qm.sh -onlineMigrateEstimate teamserver.properties=/server/conf/qm/teamserver.properties logFile=repotools_onlineMigrateEstimate.log

For more information about the -onlineMigrateEstimate command and its parameters, see Repository tools command for evaluating the online migration process.
To start the online migration enter the following command:
The teamserver.properties parameter must point to an absolute path on the old server.

cd \server\

repotools-qm.bat -onlineMigrate teamserver.properties=\server\conf\qm\teamserver.properties logFile=repotools_onlineMigrate.log numStatesPerRun=100 priority=50

cd /server/

./repotools-qm.sh -onlineMigrate teamserver.properties=/server/conf/qm/teamserver.properties logFile=repotools_onlineMigrate.log numStatesPerRun=100 priority=50

For more information about the -onlineMigrate command and its parameters, see Repository tools command for online migration.

You can stop the online migration or revert to a previous state by using other repository tools commands.

To safely stop the online migration at any time, use the -onlineMigrateStop command. For more information, see Repository tools command for stopping online migration.

To revert the database to a previous state, use the -onlineMigrateRevert command. For more information, see Repository tools command for reverting online migration.

Optional: Online migration of data

The application online migration is an optional upgrade step that is done while the old server is still running. It migrates data in the live repository to reduce the amount of downtime incurred during normal migration. The data is migrated in such a way as to not affect users on the existing server.

Note: In a clustered environment, do this procedure only on the first node. You will replicate this node to other nodes in a later step.

Procedure

Before you start the application upgrade, ensure that the database statistics are up-to-date. Otherwise, the migration might take several hours.
Databases generally manage statistics automatically; for example, in a scheduled overnight operation. However, to ensure that the database is fully optimized, you can manually run the statistics as follows:

DB2 REORGCHK UPDATE STATISTICS ON TABLE ALL

EXEC sp_updatestats

EXEC DBMS_STATS.GATHER_DATABASE_STATS

For information about the Db2 database REORGCHK command, see the Db2 website.
For information about the Oracle database DBMS_STATS command, see the Oracle website.

For information about the SQL Server database Update Statistics command, see the SQL Server website.
On the server on which you installed the new version of the application, open a command window and enter the following command to estimate the data to migrate and to evaluate whether the online migration is appropriate for the repository.
The teamserver.properties parameter must point to an absolute path on the old server.

cd \server\
repotools-ccm.bat -onlineMigrateEstimate teamserver.properties=\server\conf\ccm\teamserver.properties logFile=repotools_onlineMigrateEstimate.log

cd /server/

./repotools-ccm.sh -onlineMigrateEstimate teamserver.properties=/server/conf/ccm/teamserver.properties logFile=repotools_onlineMigrateEstimate.log

For more information about the -onlineMigrateEstimate command and its parameters, see Repository tools command for evaluating the online migration process.
To start the online migration enter the following command:
The teamserver.properties parameter must point to an absolute path on the old server.

cd \server\
repotools-ccm.bat -onlineMigrate teamserver.properties=\server\conf\ccm\teamserver.properties logFile=repotools_onlineMigrate.log numStatesPerRun=100 priority=50

cd /server/

./repotools-ccm.sh -onlineMigrate teamserver.properties=/server/conf/ccm/teamserver.properties logFile=repotools_onlineMigrate.log numStatesPerRun=100 priority=50

For more information about the -onlineMigrate command and its parameters, see Repository tools command for online migration.

You can stop the online migration or revert to a previous state by using other repository tools commands.

To safely stop the online migration at any time, use the -onlineMigrateStop command. For more information, see Repository tools command for stopping online migration.

To revert the database to a previous state, use the -onlineMigrateRevert command. For more information, see Repository tools command for reverting online migration.

Improve the application upgrade performance and execution

If you have an AM application repository with a large number of artifacts, you can reduce the server downtime during migration by running the database migration tasks, while keeping the existing server active.

Note: You can use the onlineMigrateEstimate repotools command to retrieve the number of item states that the online migration command, onlineMigrate, processes. It is recommended that you use the onlineMigrate command if the number of states for “Type “ID Mappings (168)”:” exceeds 3,000,000.

The average estimated time needed to perform the online migration can be calculated using the following formula:
Online migration time (in hours) = (number of item states) / 500000

For more details about evaluating the online migration process and running online migration, see onlineMigrateEstimate repotools command and onlineMigrate repotools command.

Important: Additional steps are required before you execute the onlineMigrate repotools command. See onlineMigrate repotools command for more details.

To perform online migration keeping the existing server active, open a command prompt with administrative privileges and enter the following commands:

cd <path to EWM/RMM 7.0.3 installation folder specified by user>/server
repotools-ccm -onlineMigrate teamserver.properties=<path to AM 6.0.x/7.0.x Installation folder specified by user>/server/conf/<RMM context root specified by user>/teamserver.properties

To perform online migration without executing the onlineMigrate command, perform the following steps:

Open the existing file or create a new file named OnlineMigrateSettings.cfg in <path to EWM/RMM installation folder specified by user>/server folder and make sure it contains the following line:

numStatesPerRun=400
(Optional) For DB2 only: Open a DB2 command window and enter the following command to increase the APPLHEAPSZ configuration setting:

db2 update db cfg for <RMM DB name> using APPLHEAPSZ <original value * 2>

Optional: Back up the WebSphere Application Server profile

Create a backup of your WebSphere Application Server profile. If the upgrade fails, you can use the backup to restore the profile.

In a distributed topology, you must complete this step on each application server that hosts the applications.

Note: The command shuts down the server before starting the backup process.

Open a command prompt and change to the bin folder of the WebSphere Application Server profiles directory. For example, cd \bin.
Enter the following command. If WebSphere Application Server security is turned on, you must also supply the user name and password. Make sure that the directory path to the compressed file exists.

backupConfig.bat Path_to_a_new_compressed_file_to_create_backup_of_profile -username WAS_primary_administrative_user_name -password WAS_administrative_password

For example:

backupConfig.bat C:\WAS_backup\version_6.0.x_profile.zip -username WAS admin -password WAS admin password

Tip: You can restore the backed-up profile by running the restoreConfig.bat command. For example, restoreConfig.bat C:\WAS_backup\version_6.0.x_profile.zip

Open a command shell and change to the bin folder of the WebSphere Application Server profiles directory. For example, cd /bin
Enter the following command. If WebSphere Application Server security is turned on, you must also supply the user name and password. Make sure that the directory path to the compressed file exists.

./backupConfig.sh Path_to_a_new_compressed_file_to_create_backup_of_profile -username WAS_primary_administrative_user_name -password WAS_administrative_password

For example:

./backupConfig.sh /root/WAS_backup/version_6.0.x_profile.zip -username admin -password password

Note: The directory path to the compressed file must exist before running the backup command.

Tip: You can restore the backed-up profile by running the ./restoreConfig.sh command. For example, ./restoreConfig.sh /root/WAS_backup/version_6.0.x_profile.zip

Stop and uninstall the previously installed applications from WebSphere Application Server

In a distributed topology, you must complete this step on each application server that hosts the applications.

Click Applications > Application Types > WebSphere enterprise applications.
Click jts_war and then under Detail Properties click Security role to user/group mapping. Write down the security roles mapping for jts_war application. You will use this information to remap the application for its version counterpart.
Click ccm_war and then under Detail Properties click Security role to user/group mapping. Write down the security roles mapping for ccm_war application. You will use this information to remap the application for its version counterpart.

Click am_war and then under Detail Properties click Security role to user/group mapping. Write down the security roles mapping for am_war application. You will use this information to remap the application for its version counterpart.

Click qm_war and then under Detail Properties click Security role to user/group mapping. Write down the security roles mapping for qm_war application. You will use this information to remap the application for its version counterpart.
Click the Enterprise Applications link and then stop and uninstall the following installed applications:
- jts_war
- ccm_war
- qm_war
- rm_war
- converter_war
- relm_war
- lqe_war
- ldx_war
- dcc_war
- rs_war
- gc_war
When you are prompted to save the changes to the master configuration, save them.

Uninstall the previously installed applications from WebSphere Application Server

You can use the clm_undeploy.py script to remove all application WAR files that are installed on a single WebShpere Application Server.

You can use the clm_undeploy_distributed.py script to remove all application WAR files that you specify in your command argument as a comma-separated value.

Start the server by opening a command windowshell and entering the following commands. Replace server1 with the name of your server:

cd \bin
startServer.bat server1

cd /bin
./startServer.sh server1

Continue with the following steps to remove previous installed applications.

If you backed up your WebSphere Application Server profile in the previous step, the command shut down the server. Restart the server by opening a command windowshell and entering the following commands. Replace server1 with the name of your server:

cd \bin
startServer.bat server1

cd /bin
./startServer.sh server1

Enter the following command to remove the application WAR files. The clm_undeploy.py script removes all application WAR files that are installed in the profile. You must also provide the location of WAR files. The default directory for the WAR files during the installation is webapps. If you used a different directory, provide that location in the command syntax.

Note: On Windows platforms you must use forward slash in the paths for the location of the Jython script.

wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy.py /server/webapps JazzInstallDirOldVersion/server/webapps

Enter the following command to remove the application WAR files. The clm_undeploy_distributed.py script removes all application WAR files that you specify as a comma-separated value in the command argument. Ensure there are no spaces between the application names.

On the server that hosts / Link Index Provider enter the following command:

wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py jts,clmhelp,ldx

On the server that hosts the application, enter the following command:

wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py ccm

On the server that hosts the application, enter the following command:

wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py am

On the server that hosts the Quality Management application, enter the following command:

wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py qm

On the server that hosts the application, enter the following command:

wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py rm,converter

On the server that hosts the application, enter the following command:

wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py relm

On the server that hosts the Data Collection Component application, enter the following command:

wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py dcc

On the server that hosts the Report Builder application, enter the following command:

wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py rs

On the server that hosts the Lifecycle Query Engine application, enter the following command:

wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py lqe

On the server that hosts the Global Configuration Management application, enter the following command:

wsadmin.bat./wsadmin.sh -lang jython -user WAS_username -password WAS_password -f JazzInstallDir/server/was/clm_undeploy_distributed.py gc

Update the JAZZ_HOME and configuration location custom properties

In a distributed topology, you must update JAZZ_HOME and configuration location custom properties on each application server that hosts the applications.

Log on to the WebSphere Application Server Integrated Solutions Console at https://hostname:9043/ibm/console/logon.jsp.
Click Servers > Server Types > WebSphere application servers.
Click the server name to open it. The default server name is server1.
Under Server Infrastructure section, click Java and Process Management > Process definition.
Under Additional Properties, click Java Virtual Machine.
Under Additional Properties, click Custom properties.
Click JAZZ_HOME and update its value to file:///_install_dir/server/conf. For example, file:///C:/PROGRA~1/IBM/JazzTeamServer_/server/conffile:///opt/IBM/JazzTeamServer_/server/conffile:///usr/IBM/JazzTeamServer_/server/conf.
Click log4j2.configurationFile and update its value to file:///_install_dir /server/conf/startup_log4j2.xml. For example, file:///C:/PROGRA~1/IBM/JazzTeamServer_/server/conf/startup_log4j2.xmlfile:///opt/IBM/JazzTeamServer_/server/conf/startup_log4j.propertiesfile:///usr/IBM/JazzTeamServer_/server/conf/startup_log4j.properties.
Click lqe.config.location and update its value to file:///_install_dir/server/conf/lqe. For example, file:///C:/PROGRA~1/IBM/JazzTeamServer_/server/conf/lqefile:///opt/IBM/JazzTeamServer_/server/conf/lqefile:///usr/IBM/JazzTeamServer_/server/conf/lqe.
Click ldx.config.location and update its value to file:///_install_dir/server/conf/ldx. For example, file:///C:/PROGRA~1/IBM/JazzTeamServer_/server/conf/ldxfile:///opt/IBM/JazzTeamServer_/server/conf/ldxfile:///usr/IBM/JazzTeamServer_/server/conf/ldx.
If you are connecting to an Oracle database, ensure that ORACLE_JDBC_DRIVER_FILE is pointing to the correct JDBC driver file in .
If you are connecting to SQL Server database, ensure that SQLSERVER_JDBC_DRIVER_FILE is pointing to the correct JDBC driver file in .
Save the changes to the master configuration when prompted.

Update the JRS shared library classpath

In WebSphere Integrated Solutions Console navigation pane click Environment > Shared libraries.
Click the JRS shared library name in the list to open it.
In the Classpath field, update the path to the new installation directory. For example:

\server\conf\rs\WAS_SharedLibrary/server/conf/rs/WAS_SharedLibrary

Click Apply and then Save directly to the master configuration.

Stop Jazz Team Server

In a distributed topology, you must complete this step on each application server that hosts the applications.

Open a command prompt and change to the \bin directory.
Enter the following command:

stopServer.bat server1 -user admin_userid -password admin_password

Open a command prompt and change to the /bin directory.
Enter the following command:

./stopServer.sh server1 -user admin_userid -password admin_password

In QShell, navigate to the old configuration directory, for example, /QIBM/UserData/Old_JazzTeamServer/server
Enter the following command:

./serverShutdown.sh profileName

In addition to QShell, you can use the CL command. Enter QJTS702/STPJAZZSVR on the 5250 command prompt, then press PF4 to prompt for parameters.

Clean up the WebSphere Application Server temp directories

In a distributed topology, you must complete this step on each application server that hosts the applications.

Remove the application-related contents from the following directories in the profile:

Node_Name is the application server node name, for example, ADMINIB-SAQDV6VNode01.

\temp\Node_Name\server1
\temp\wscache
/temp/Node_Name/server1
/temp/wscache

Depending on which applications were installed, these directories might be in the profile and can be removed:

jts_war
ccm_war

am_war

qm_war
rm_war
converter_war
relm_war
lqe_war
ldx_war
dcc_war
rs_war
gc_war

Note: If the temp directories have files that are deeper than your MAX_PATH characters, usually 100 characters long, when you try to delete the directories, you might get an Access Denied error. For instructions to delete the directories, see the documentation for your operating system.

Clean up the logs directory

In a distributed topology, you must complete this step on each application server that hosts the applications.

Remove the application-related log files from the following logs directory in the profile:

\logs
/logs

Clear the WebSphere Application Server class cache

In a distributed topology, you must complete this step on each application server that hosts the applications.

You must clear the WebSphere Application Server class cache to ensure that after the upgrade, the server is not using the previous versions of the classes. There are two types of class cache that must be cleared, the JVM's cache and the OSGi cache. Complete the following steps to clear these caches:

Stop WebSphere Application Server if it is running.
To clear the OSGi class cache, open a command windowshell and enter the following command:
cd \bin
osgiCfgInit.bat/bin
./osgiCfgInit.sh
To clear the JVM's class cache, enter the following command:
cd \bin
clearClassCache.bat/bin
./clearClassCache.sh

Note: If you are using the Windows service to start WebSphere Application Server, the command to clear the class cache might not work. In this case you must manually empty the content of the javasharedresources directory. Make sure the service is stopped before attempting to delete the files. Here is an example of the location of the javasharedresources directory: C:\Users\USER_NAME\AppData\Local\javasharedresources. Also note that AppData might be a hidden directory.

Stop the servers

Open a command prompt and enter the following commands:

cd \server
server.shutdown.bat

Open a command shell and enter the following command:

cd /server
./server.shutdown

In a distributed topology, you must complete this step on each application server that hosts the applications.

Stop all applications first before stopping .

On the server, open a command prompt and enter the following command:

Note: In a clustered environment, shut down all nodes. You can leave the load-balancer (HAProxy) running unless changes are specifically needed for the new version.

cd \server
server.shutdown.bat

On the AM server, open a command prompt and enter the following command:

cd \server
server.shutdown.bat

On the QM server, open a command prompt and enter the following command:

Note: In a clustered environment, shut down all nodes. You can leave the load-balancer (HAProxy) running unless changes are specifically needed for the new version.

cd \server
server.shutdown.bat

On the RM server, open a command prompt and enter the following command:

cd \server
server.shutdown.bat

On the server, open a command prompt and enter the following command:

cd \server
server.shutdown.bat

On the LQE server, open a command prompt and enter the following command:

cd \server
server.shutdown.bat

On the DCC server, open a command prompt and enter the following command:

cd \server
server.shutdown.bat

On the JRS server, open a command prompt and enter the following command:

cd \server
server.shutdown.bat

On the GC server, open a command prompt and enter the following command:

cd \server
server.shutdown.bat

On , open a command prompt and enter the following command:

cd \server
server.shutdown.bat

On the server, open a command shell and enter the following command:

Note: In a clustered environment, shut down all nodes. You can leave the load-balancer (HAProxy) running unless changes are specifically needed for the new version.

cd /server
./server.shutdown

On the AM server, open a command shell and enter the following command:

cd /server
./server.shutdown

On the QM server, open a command shell and enter the following command:

Note: In a clustered environment, shut down all nodes. You can leave the load-balancer (HAProxy) running unless changes are specifically needed for the new version.

cd /server
./server.shutdown

On the RM server, open a command shell and enter the following command:

cd /server
./server.shutdown

On the server, open a command shell and enter the following command:

cd /server
./server.shutdown

On the LQE server, open a command shell and enter the following command:

cd /server
./server.shutdown

On the DCC server, open a command shell and enter the following command:

cd /server
./server.shutdown

On the JRS server, open a command shell and enter the following command:

cd /server
./server.shutdown

On the GC server, open a command shell and enter the following command:

cd /server
./server.shutdown

On , open a command shell and enter the following command:

cd /server
./server.shutdown

Stop the Distributed Cache Microservice (DCM)

To stop the microservice, open a command windowshell and enter the following commands:

cd Path_To_DCM_Folder
distributedCache.stop.bat JRE_Bin_Path

cd Path_To_DCM_Folder
./distributedCache.stop.sh JRE_Bin_Path

In these commands, Path_To_DCM_Folder is the location where the Distributed Cache Microservice is installed and JRE_Bin_Path is the location of the JRE/Bin folder. The path to the Bin folder is optional. If you do not specify a path, the system uses the default location for the microservice and uses the JRE that is provided by the application.

Delete persisted data

Starting in version 6.0.6, persistence is enabled by default for the Distributed Cache Microservice. When persistence is enabled, the microservice backs up in-memory distributed caches to disk. This persisted backup is used to initialize local caches on a node that is brought online after going offline in an unplanned manner. The persisted backup enables the node to initialize to the current state.

Also, in version 6.0.6 and later, the Distributed Cache Microservice monitors the online status of the applications' nodes. When a server on a node is shut down, a signal is sent to the microservice. After all nodes of a cluster are offline, the microservice clears all persisted distributed data for that cluster.

Cluster-specific data is stored in a subfolder of the clustering folder, which is specified in the configuration file as shown in the following example:

[Cache]

# Relative or absolute location on the file system to save cache data when the microservice is offline.
# This persisted data is only needed if DCM is restarted while clustered applications are running.
# When a planned shutdown of a clustered application using the cache is underway, it is advisable to delete the persisted data.
-persistentStore = $E{PERSISTENT_STORE, distributedData}

By default, the subfolder is called distributedData. The subfolder contains a directory for each cluster with data on the Distributed Cache Microservice.

After a planned shutdown of ALL nodes in a cluster occurs, delete the folder at this location: server/clustering/cache/<distributedData>/<clusterName>. This deletion allows distributed objects to reinitialize as expected when the nodes come back online.

Copy the Lifecycle Query Engine (LQE) configuration files

Before copying the LQE configuration files, go to the directory where you just installed the version application and delete the following directories if they exist. In a fresh installation, these directories should not exist. Alternatively, you can open a command prompt and enter the following commands to delete the directories.

       del /s /frm -rf \server\conf\lqe\indexTdb
Enter Y to confirm the delete operation
/server/conf/lqe/indexTdb

       
        del /s /frm -rf \server\conf\lqe\textIndex
Enter Y to confirm the delete operation
/server/conf/lqe/textIndex

        
        del /s /frm -rf \server\conf\lqe\shapeText
Enter Y to confirm the delete operation
/server/conf/lqe/shapeText

        
        del /s /frm -rf \server\conf\lqe\shapeTdb
Enter Y to confirm the delete operation
/server/conf/lqe/shapeTdb

        
        del /s /frm -rf \server\conf\lqe\historyText
Enter Y to confirm the delete operation
/server/conf/lqe/historyText

        
        del /s /frm -rf \server\conf\lqe\historyTdb
Enter Y to confirm the delete operation
/server/conf/lqe/historyTdb


    	del /s /frm -rf 
    	\server\conf\lqe\versionTdb
Enter Y to confirm the delete operation
/server/conf/lqe/versionTdb

    	

Enter the following commands to copy the configuration files to the new installation directory:

        xcopy /scp -R \server\conf\lqe\indexTdb/server/conf/lqe/indexTdb \server\conf\lqe\indexTdb
If prompted, enter D to copy the directory structure
/server/conf/lqe/indexTdb
        

        
        xcopy /scp -R \server\conf\lqe\textIndex/server/conf/lqe/textIndex \server\conf\lqe\textIndex
If prompted, enter D to copy the directory structure
/server/conf/lqe/textIndex

        
        xcopy /scp -R \server\conf\lqe\shapeText/server/conf/lqe/shapeText \server\conf\lqe\shapeText
If prompted, enter D to copy the directory structure
/server/conf/lqe/shapeText

        
        xcopy /scp -R \server\conf\lqe\shapeTdb/server/conf/lqe/shapeTdb \server\conf\lqe\shapeTdb
If prompted, enter D to copy the directory structure
/server/conf/lqe/shapeTdb

        
        xcopy /scp -R \server\conf\lqe\historyText/server/conf/lqe/historyText \server\conf\lqe\historyText
If prompted, enter D to copy the directory structure
/server/conf/lqe/historyText

        
        xcopy /scp -R \server\conf\lqe\historyTdb/server/conf/lqe/historyTdb \server\conf\lqe\historyTdb
If prompted, enter D to copy the directory structure
/server/conf/lqe/historyTdb


    	xcopy /scp 
    	-R \server\conf\lqe\versionTdb/server/conf/lqe/versionTdb \server\conf\lqe\versionTdb
If prompted, enter D to copy the 
    	directory structure
/server/conf/lqe/versionTdb

    	
        copy cp  \server\conf\lqe\lqe.properties/server/conf/lqe/lqe.properties \server\conf\lqe
Enter Y to overwrite the existing file
/server/conf/lqe

        
        copy cp  \server\conf\lqe\lqe.node.id/server/conf/lqe/lqe.node.id \server\conf\lqe
Enter Y to overwrite the existing file
/server/conf/lqe

        
        copy cp  \server\conf\lqe\lqe.key/server/conf/lqe/lqe.key \server\conf\lqe
Enter Y to overwrite the existing file
/server/conf/lqe

        
        copy cp  \server\conf\lqe\dbconnection.properties/server/conf/lqe/dbconnection.properties \server\conf\lqe
Enter Y to overwrite the existing file
/server/conf/lqe

    
        If prompted, confirm that you want to overwrite the files.
        
        

Copy the Link Index Provider (LDX) configuration files

Before copying the LDX configuration files, go to the directory where you just installed the version application and delete the following directories if they exist. In a fresh installation, these directories should not exist. Alternatively, you can open a command prompt and enter the following commands to delete the directories.

       del /s /frm -rf \server\conf\ldx\indexTdb
Enter Y to confirm the delete operation
/server/conf/ldx/indexTdb

        del /s /frm -rf \server\conf\ldx\textIndex
Enter Y to confirm the delete operation
/server/conf/ldx/textIndex

    	del /s /frm 
    	-rf \server\conf\ldx\versionTdb
Enter Y to confirm the delete operation
/server/conf/ldx/versionTdb

Enter the following commands to copy the configuration files to the new installation directory:

        xcopy /scp -R \server\conf\ldx\indexTdb/server/conf/ldx/indexTdb \server\conf\ldx\indexTdb
If prompted, enter D to copy the directory structure
/server/conf/ldx/indexTdb

        
        xcopy /scp -R \server\conf\ldx\textIndex/server/conf/ldx/textIndex \server\conf\ldx\textIndex
If prompted, enter D to copy the directory structure
/server/conf/ldx/textIndex

        
    	xcopy /scp 
    	-R \server\conf\ldx
    	\versionTdb/server/conf/ldx/versionTdb \server\conf\ldx\versionTdb
If prompted, enter D to copy the directory 
    	structure
/server/conf/ldx/versionTdb

    	
        copy cp  \server\conf\ldx\lqe.properties/server/conf/ldx/lqe.properties \server\conf\ldx
Enter Y to overwrite the existing file
/server/conf/ldx

        
        copy cp  \server\conf\ldx\lqe.node.id/server/conf/ldx/lqe.node.id \server\conf\ldx
Enter Y to overwrite the existing file
/server/conf/ldx

        
        copy cp  \server\conf\ldx\lqe.key/server/conf/ldx/lqe.key \server\conf\ldx
Enter Y to overwrite the existing file
/server/conf/ldx

        
        copy cp  \server\conf\ldx\dbconnection.properties/server/conf/ldx/dbconnection.properties \server\conf\ldx
Enter Y to overwrite the existing file
/server/conf/ldx

        If prompted, confirm that you want to overwrite the files.
        

Copy the Derby database from previous installation directory to the new installation directory

Before copying the Derby database, go to the directory where you just installed the version application and delete the content of Derby directory if exist. Alternatively, you can open a command prompt and enter the following commands to clear the default version Derby directory.

Note: In a fresh installation, there is no derbyDB under the lqe directory. But if you have already started the server, there might be a derbyDB directory that should be deleted.

Enter the following command to delete the Lifecycle Query Engine Derby database if exists:

del /s /f \server\conf\lqe\derbyDB
Enter Y to confirm the delete operation

Enter the following command to delete the Lifecycle Query Engine Derby database if exists:

rm -rf /server/conf/lqe/derbyDB

Go to the directory where you previously installed the application, copy the Derby database, and paste it in the equivalent directory for version . You can also open a command prompt and enter the following commands to copy the Derby database.

Note: The following commands work if you are using the Derby database that is provided with the packaged product. If you changed your Derby database location, update the path accordingly.

Enter the following command to copy the database:

xcopy /s \server\conf\lqe\derbyDB \server\conf\lqe\derbyDB
If prompted, enter D to choose directory.

Enter the following command to copy the Lifecycle Query Engine database:

xcopy /s \server\conf\lqe\derbyDB \server\conf\lqe\derbyDB
If prompted, enter D to choose directory.

Enter the following command to copy the Lifecycle Query Engine database:

cp -R /server/conf/lqe/derbyDB /server/conf/lqe/derbyDB

Enter the following command to copy the Lifecycle Query Engine database:

cp -R /server/conf/lqe/derbyDB /server/conf/lqe/derbyDB

Copy the Derby databases from the previous installation directory to the new installation directory

Before copying the Derby database, go to the directory where you just installed the version applications and delete the content of Derby directory. Alternatively, you can open a command prompt and enter the following commands to clear the default version Derby directories.

Note: In a fresh installation, there is no derbyDB under the ldx directory. But if you have already started the server, there might be a derbyDB directory that should be deleted.

Enter the following command to delete the Derby database:

del /s /f \server\conf\jts\derby\repositoryDB
Enter Y to confirm the delete operation

Enter the following command to copy the Derby database:

Note: Since AM is an extension of CCM, no separate command is required for AM.

del /s /f \server\conf\ccm\derby\repositoryDB
Enter Y to confirm the delete operation

Enter the following command to delete the Derby database:

del /s /f \server\conf\am\derby\repositoryDB
Enter Y to confirm the delete operation

Enter the following command to delete the Quality Management Derby database:

del /s /f \server\conf\qm\derby\repositoryDB
Enter Y to confirm the delete operation

Enter the following command to delete the Derby database:

del /s /f \server\conf\rm\derby\repositoryDB
Enter Y to confirm the delete operation

Enter the following command to delete the Derby database:

del /s /f \server\conf\relm\derby\repositoryDB
Enter Y to confirm the delete operation

Enter the following command to delete the Global Configuration Management Derby database:

del /s /f \server\conf\gc\derby\repositoryDB
Enter Y to confirm the delete operation

Enter the following command to delete the Data Collection Component Derby database:

del /s /f \server\conf\dcc\derby\repositoryDB
Enter Y to confirm the delete operation

Enter the following command to delete the Link Index Provider Derby database if exists:

del /s /f \server\conf\ldx\derbyDB
Enter Y to confirm the delete operation

Enter the following command to delete the Link Index Provider Derby database if exists:

del /s /f \server\conf\ldx\derbyDB
Enter Y to confirm the delete operation

Enter the following command to delete the Derby database:

Note: Since AM is an extension of CCM, no separate command is required for AM.

rm -rf /server/conf/ccm/derby/repositoryDB

Enter the following command to delete the Derby database:

rm -rf /server/conf/jts/derby/repositoryDB

Enter the following command to delete the Derby database:

rm -rf /server/conf/am/derby/repositoryDB

Enter the following command to delete the Quality Management Derby database:

rm -rf /server/conf/qm/derby/repositoryDB

Enter the following command to delete the Derby database:

rm -rf /server/conf/rm/derby/repositoryDB

Enter the following command to delete the Derby database:

rm -rf /server/conf/relm/derby/repositoryDB

Enter the following command to delete the Global Configuration Management Derby database:

rm -rf /server/conf/gc/derby/repositoryDB

Enter the following command to delete the Data Collection Component Derby database:

rm -rf /server/conf/dcc/derby/repositoryDB

Enter the following command to delete the Link Index Provider Derby database if exists:

rm -rf /server/conf/ldx/derbyDB

Go to the directory where you previously installed the applications, copy the Derby database, and paste it in the equivalent directory for version . You can also open a command prompt and enter the following commands to copy the Derby database.

Note: The following commands work if you are using the Derby database that is provided with the packaged product. If you changed your Derby database location, update the path accordingly.

Enter the following command to copy the database:

xcopy /s \server\conf\jts\derby\repositoryDB \server\conf\jts\derby\repositoryDB

Enter the following command to copy the database:

Note: Since AM is an extension of CCM, no separate command is required for AM.

xcopy /s \server\conf\ccm\derby\repositoryDB \server\conf\ccm\derby\repositoryDB

Enter the following command to copy the database:

xcopy /s \server\conf\am\derby\repositoryDB \server\conf\am\derby\repositoryDB

Enter the following command to copy the Quality Management database:

xcopy /s \server\conf\qm\derby\repositoryDB \server\conf\qm\derby\repositoryDB

Enter the following command to copy the database:

xcopy /s \server\conf\rm\derby\repositoryDB \server\conf\rm\derby\repositoryDB

Enter the following command to copy the database:

xcopy /s \server\conf\relm\derby\repositoryDB \server\conf\relm\derby\repositoryDB

Enter the following command to copy the Global Configuration Management database:

xcopy /s \server\conf\gc\derby\repositoryDB \server\conf\gc\derby\repositoryDB

Enter the following command to copy the Data Collection Component database:

xcopy /s \server\conf\dcc\derby\repositoryDB \server\conf\dcc\derby\repositoryDB

Enter the following command to copy the Lifecycle Query Engine database:

xcopy /s \server\conf\lqe\derbyDB \server\conf\lqe\derbyDB
If prompted, enter D to choose directory.

Enter the following command to copy the Link Index Provider database:

xcopy /s \server\conf\ldx\derbyDB \server\conf\ldx\derbyDB
If prompted, enter D to choose directory.

The Derby Data Warehouse database for Liberty will be located under the Liberty server. At this point, the Liberty server has not been created. Run the following command to create the Liberty server and then copy the Data Warehouse database:

cd \server
server.startup -create

Enter the following command to copy the Data Warehouse database:

xcopy /s \server\conf\jts\derby\warehouseDB\server\liberty\servers\clm\conf\jts\derby\warehouseDB \server\liberty\servers\clm\conf\jts\derby\warehouseDB

Enter D for directory.