During an upgrade to PPM version 9.50, you must specify the system language for your instance. You can also select additional languages to deploy in the system, although this is optional.
Before you begin the upgrade, read the following part Issues to Consider Before You Upgrade.
This section addresses how upgrading to PPM version 9.50 affects the data in your current instance.
The only direct upgrade path supported is from version 7.5 to 8.00. If you are upgrading from versions earlier than 7.5, you must first upgrade to 7.5, and then upgrade to 8.00. For information about how to upgrade to PPM version 7.5, see the version 7.5 Upgrade Guide.
If you upgrade to version 7.5, and you then install one or more language packs, the content for translatable columns in the LOOKUPS table is overwritten. If you have customized this content on a version 7.1 instance, these changes are lost.
If you are upgrading from PPM version 7.1, and you plan to deploy additional non-English languages on your instance, it is recommended that you not deploy language packs after you upgrade to version 7.5. Instead, continue the upgrade process and deploy new languages only during the upgrade to PPM version 8.00.
Note: There is a known issue related to deploying a language pack in PPM version 7.5. If you install the language pack on an instance upgraded to version 7.5, default translations are automatically applied for drop-down list items that are part of the generic set of PPM configurations. If you have customized any of these items, your changes are lost. However, this issue does not apply to language pack deployment in PPM version 8.00.
You must consider the following issues before you upgrade:
When you deploy a language pack during the upgrade to PPM version 8.00, the following occur automatically:
The new language becomes available as a session language that user a PPM user can select from the Language list at logon.
All boilerplate text translations are deployed into the PPM system.
Boilerplate text is the text that hard-coded in the PPM user interface (both the standard interface and the PPM Workbench), and is not configurable by PPM users. (This does not include custom attributes that you have configured for your business in PPM, such as the prompts for custom request fields.)
.propertiesfiles that contain the default translations for basic PPM configurations (such as Bug and Enhancement request types and workflows, Best Practices request types and workflows, and so on) are placed on the PPM Server filesystem.
The translations contained in these property files are not automatically installed into PPM; rather, you must assess whether you want to import all, some, or none of these default translations, depending on which of the generic configurations your organization uses, and how much of the default configuration has been customized.
Note: For information about the text
.propertiesfiles, see Using Translation Management Tools.
If you want to make the translations that OpenText provides for the default configurations available, you must run the
kImportAttributes.shscript after you upgrade. However, before you import these translations, it is important that you determine whether your current configurations have been tailored to your specific business processes. If they have, then the translated content for the upgraded default configurations may not apply in your environment.
It is strongly recommended that, after you upgrade to PPM version 9.50, you run the
kImportAttributes.shscript in test mode to generate the Translation Impact report. The details of this report indicate how importing the translations will affect your PPM environment. You can then decide which of the default translations you want to import, and which to exclude.
For information on how to run the
kImportAttributes.shscript in test mode, see Running Import Script. For information on the Translation Impact report, see Translation Impact Report. For information on how to selectively import translated content, see Using Translation Management Tools.
Any flexible time period customizations that were created on your current PPM instance are removed from the database schemas during upgrade. Existing resource-planning data remains, but is grouped according to fiscal time periods rather than flexible time periods, which no longer exist as entities in PPM version 8.00. For detailed information about changes to time periods introduced in PPM version 8.00, see the Upgrade Guide.
If the system language on your pre-upgrade (version 7.5) PPM instance is English, then when you upgrade to PPM version 9.50, you have the option of changing the system language. If the system language on your pre-upgrade (version 7.5) PPM instance is not English, then the system language does not change during upgrade.
Note: Keep in mind that, if you change to a non-English system language, all seeded data and all custom data are set to the new non-English system language.
The Upgrade Guide provides the detailed instructions on how to prepare to upgrade your PPM instance and how to perform the upgrade, including the steps for deploying languages. The following procedure focuses only on the upgrade steps that are specific to the MLU.
Caution: Before you deploy languages during an upgrade, make sure that you have correctly set the
NLS_LENGTH_SEMANTICSparameter, as described in the Installation and Administration Guide.
Follow the instructions provided in the Upgrade Guide to start the upgrade wizard.
The upgrade wizard prompts you to select the language you want it to use.
From the list, select the language for the wizard to display as it guides you through the upgrade process.
Later in the upgrade, you have the option of selecting a system language other than English.
The wizard asks whether you want to run the prevalidation step. To perform prevalidation, leave Yes, I would like to run prevalidation step now selected, and click Next. To skip prevalidation, select No, I would like to skip the prevalidation step, and then click Next.
Note: We strongly recommend that you perform this step as part of the upgrade. Prevalidation checks for data inconsistencies that might cause upgrade problems. For more details, see the Upgrade Guide.
If you run prevalidation:
PreValidationResultsIndex.htmlfile, which is located in the
If prevalidation revealed problems, cancel the upgrade, resolve the problems, and then begin the upgrade again.
If prevalidation uncovered no problems, click Next.
The report lists all issues that you must resolve before you can successfully upgrade to PPM9.50.
Note: If you need assistance with database issues, consult your database administrator.
When prompted, select the system language.
On the next step, you can select languages to deploy on the upgraded PPM instance.
Select the checkboxes for the languages to deploy, and then click Next.
Note: If you do not select additional languages during the upgrade, you can deploy them later by running the
kDeploy.shscript. For instructions, see Deploy languages using kDeploy.sh and server clustering.
Complete the upgrade procedure as instructed in the Upgrade Guide.
Complete any tasks you want to perform after language deployment. For descriptions of these tasks, and instructions on how to perform them, see After Language Deployment
(Optional, but strongly recommended) For each language deployed on your PPM instance, run the
kImportAttributes.shscript in test mode, and then, based on the results in the Translation Impact report, decide which of the default translations to import and which to exclude.
Note: To use the
kImportAttributes.shscript, you must have the Sys Admin: Manage Translations access grant. For instructions on how to run the script in test mode, see Running Import Script
For information on the Translation Impact report, see Translation Impact Report.
For each language deployed on your PPM instance, run the kImportAttributes.sh script to import the translated user interface content.
Note: For instructions on how to selectively import translated content, see Using Translation Management Tools.
After you import the PPM-provided translations, not all content is available in the deployed languages. You must manage the translation of custom entities and data manually.