Supported scenarios for using server rename

Edit online

This topic describes the scenarios that are supported in this release.

Important: Server rename operations change the public URLs of referenced artifacts in an IBM® Engineering Lifecycle Management (ELM) deployment and might affect external links. For example, URL changes can invalidate external references such as those in email notifications, or external Open Services for Lifecycle Collaboration (OSLC) references from tools that do not support server rename. If you perform a server rename in a production environment, these changes might disrupt users. However, the server rename operation is useful for routine administrative tasks, such as refreshing data in a staging environment by using a snapshot of the production environment.

To perform a server rename, you must obtain a feature key file from IBM Software Support. When you contact IBM Support, mention that you are requesting a server rename feature key file. The key file is named ImportURLMappings.activate. Copy the file to the JazzInstallDir/server/conf directory for the applications that you will rename. The key is only needed to execute the repotools importURLMappings command.

You can rename the server to move a pilot deployment into production or to move an existing production deployment to new hardware. The server rename operation moves all existing projects and artifacts from one deployment to another. The operation does not support a selected project move function; that is, you cannot move only selected projects when you rename a server.

Read the description of the supported and non-supported scenarios below. See Server rename process for the high-level steps in performing a server rename. See Software version requirements for information about the requirements for each scenario.

Supported scenario: Setting up a test staging environment with production data

This scenario allows you to create a copy of an existing IBM Engineering Lifecycle Management (ELM) deployment for test purposes only. In this scenario, when running in production, you can also install ELM in the test staging environment and copy the data and configuration files from production to the staging environment. You then use server rename to change the URLs in the staging environment.

This is useful for trying out new features or functions with real data without impacting the production database. One such example might be trying out a change to your process configuration or Engineering Workflow Management work item type definitions. This scenario requires that the production server and the copied test server must never cross-link.

In addition, it is important not to connect a Engineering Workflow Management client to both the production and staging repositories. Always use a staging workspace for connecting to the staging server.

For additional details, see Topologies and mapping files for setting up a test staging environment and Setting up a test staging environment with production data.

Important: This scenario cannot be used to stage an upgrade from version 3 to version 4, which requires an isolated network where the URLs remain constant before and during the upgrade procedure. For details about this upgrade scenario, see Staging a test environment for the upgrade process.

Supported scenario: Moving a pilot deployment to production

This scenario starts out as a small, pilot deployment that has been set up for evaluation purposes. The pilot has a limited number of users, who test-drive product features and create data. After the evaluation period, the goal is to scale up, add more users and data, and not lose any existing data that was created during the pilot.

For several reasons, such as a need to move the pilot to more robust hardware or a need to comply with corporate naming standards, a server rename is required. The pilot to production scenario must meet the following requirements:

  • The pilot must be a single ELM deployment (Jazz® Team Server with the registered ELM applications) with no linkages to other ELM deployments.
  • All user clients and build engines must be at version 6.0 or later prior to the rename.
  • After performing the server rename, the pilot deployment must be permanently taken out of service.
  • No integrations to third-party products are allowed, except for integrations to Rational® ClearQuest® and Rational ClearCase®. Rational ClearQuest and Rational ClearCase must be production systems that can communicate with the ELM deployment in the pilot environment. At this time, moving Rational ClearQuest or Rational ClearCase from a pilot system to a production system is an unsupported scenario.
  • You must not be using the Derby database, or must migrate off of the Derby database prior to the rename.

For additional details, see Topologies and mapping files for the pilot to production scenario and Moving a pilot or full production deployment by using server rename.

Supported scenario: Moving an existing production deployment

You can perform a server rename on an ELM deployment that is in full production. You can move your deployment to new hardware or perform a rename in place on the existing hardware. This production to production scenario must meet the following requirements:

  • Unlike the pilot to production scenario, multiple ELM deployments, such as two linked Jazz Team Server, are now supported.
  • If you are switching to new hardware, the old hardware must be permanently taken out of service.
  • More integrations to third-party products are allowed than was allowed previously. For information about supported integrations, see Impact of server rename on integrated products and the Jazz.net Deployment wiki.
  • It is assumed that you are using an enterprise database and not using the Derby database.

Non-supported scenarios

The following scenarios are not supported:

  • Cloning an ELM application or deployment for production use
    Note: However, you can use command-line setup to automate new deployments. See Running the setup from the command line.
  • Splitting an ELM production deployment by cloning and renaming, and then archiving parts of the repository data
  • Switching any ELM application to a different Jazz Team Server
  • Moving, copying, or deleting selected projects or artifacts between online ELM applications.