Migrating Projects (Standard) Considerations

Before you migrate:

Be sure that you have Integration defined for the CBS shells you plan to use for migration
Examine the shell hierarchy of your CBS shells and determine the location for the new migrated shells. You can migrate several projects at once into a shell type, creating a new shell instance under that shell type for each migrated project.
Examine the set ups for the original projects and also for the destination shells, and think about the mapping from the project to the shell. You might have to add data elements on the project side or the shell side to ensure that the data you need is migrated correctly and completely. For example, the shell name is limited to 128 characters, and shell description is limited to 250 characters. However, standard project name is limited to 250 characters, and the project description is limited to 2000 characters. In order for the migration from project to CBS shell to be successful, you must modify the project name and description to be within the limits for these fields that exist for the shells (128 characters for a shell name, and 250 characters for a shell description).
As a best practice, do not migrate projects that have the Active status. Modify the projects as needed to get them as finished as possible and then put them in the Inactive status before migration. Make your project as complete as you can before you migrate it to a CBS shell.
Test your migration in your Test environment before implementing it in your Production environment to ensure that the migration is successful and yields the desired result.
You can use user-defined reports to gather data regarding which projects to migrate and the location they should occupy in the shell hierarchy.
Understand that migration cannot be undone; when you migrate a project to a CBS shell, you cannot go back to that project. The project is converted completely to a CBS shell when the migration completes successfully.

Last Published Thursday, December 8, 2022