Supported scenarios for using server rename

Scenarios that are supported in this release.

Important: Server rename operations change the public URLs of referenced artifacts in an IBM® Engineering Lifecycle Management 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 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 want to rename. The key is only needed to run 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.

Note: You can perform a server rename on a server that is already renamed and does not have any negative impact.

Read the description of the following supported and non-supported scenarios. 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 deployment for test purposes only. In this scenario, when running in production, you can also install Engineering Lifecycle Management 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 an Engineering Workflow Management client to both the production and staging repositories. Always use a staging workspace for connecting to the staging server.

For more 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 Engineering Lifecycle Management deployment (Jazz Team Server with the registered Engineering Lifecycle Management applications) with no linkages to other Engineering Lifecycle Management deployments.
All user clients and build engines must be at version 6.0 or later before you rename the server.
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 ClearQuest® and ClearCase® . ClearQuest and ClearCase must be production systems that can communicate with the Engineering Lifecycle Management deployment in the pilot environment. Currently, moving ClearQuest or 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 Engineering Lifecycle Management 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 Engineering Lifecycle Management 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 the 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.

Nonsupported scenarios

The following scenarios are not supported:

Cloning an Engineering Lifecycle Management 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 Engineering Lifecycle Management production deployment by cloning and renaming, and then archiving parts of the repository data
Switching any Engineering Lifecycle Management application to a different Jazz® Team Server
Moving, copying, or deleting selected projects or artifacts between online Engineering Lifecycle Management applications.