On this page:
Once you have successfully migrated your data to a new version of Teamwork Cloud, you should also migrate the projects if you want to be able to edit them with a new version of a modeling tool. Migrating projects updates their standard/system profiles. Projects that are not migrated can only be opened in the read-only mode.
- To migrate a project, you need to have the Administer Resources, Edit Resources, Edit Resource Properties, and Read Resources permissions for that project.
- While a project is being migrated, other users are prevented from modifying it. Therefore, we highly recommend that the same person migrates all projects.
Migrating server projects automatically
Automatic project migration allows you to migrate a large number of projects at the same time and is the recommended approach after upgrading the Teamwork Cloud server.
To migrate server projects automatically
- Start the modeling tool and log in to Teamwork Cloud.
- In the main menu, go to Collaborate > Migrate Projects to Version X.
- In the Migrate Projects to Version X dialog, select the projects you want to migrate.
In the dialog toolbar, click
to select all server projects.Select a category (or categories) to migrate all projects inside it.
Optionally, select one or several of the following check boxes:
- Speed up model-history related operations - Migrates the cache of the earlier project versions to speed up model history-related operations after migration. However, selecting this check box may slow down the migration.
- Enable migration of password-protected projects - Allows you to select password-protected projects. You will be prompted to enter the password for each password-protected project in the selected scope. If you do not select this check box, password-protected projects will be excluded from the migration scope.
- Skip archived branches - Excludes archived project branches from the migration scope. Selecting this check box may speed up the migration.
- Click OK.
Note that it may take a while to migrate a large number of projects. Once you receive a message saying that Teamwork Cloud projects were migrated successfully, the migration is complete. If you get the list of projects that were not migrated, it means that migration was only partially successful and you have to migrate these projects manually.
Migrating UAF and UPDM projects
- UPDM projects cannot be migrated from the modeling tool with the UAF environment. If you want to migrate UPDM projects to UAF, open the <install_root>\bin\<modeling_tool>.properties file and change the value of the -Dmigrate.project.from.updm2.to.uaf\=false property to true. By default, the value of this property is false, which means, that UPDM projects will not be migrated.
- For more information about UAF project migration issues, see Project migration issues on Teamwork Cloud.
Migrating server projects manually
If automatic project migration is only partially successful and you get the list of projects that were not migrated, migrate these projects manually.
To migrate server projects manually
- Start the modeling tool and log in to Teamwork Cloud.
- Open the server project that was not migrated.
- When the Incompatible System/Standard Profiles dialog opens, click Continue to update the profiles and commit the changes to the server.
When you get the message that the profiles were successfully updated, you can continue working with the project as usual.
Migrating used projects
In this section, you will learn how to decide whether or not to migrate used projects depending on your situation.
To begin with, it is important to understand how project usages work. Every time you use a project, a copy of that project is embedded in the main project. That embedded copy remains unchanged until you update the used project version, e.g., when a new project version becomes available on the server. When you migrate the main project, the embedded copies of used projects are migrated together with the main project, even if the used projects itself are not migrated. In other words, the embedded copies of used projects remain unchanged, but they start using the same updated standard/system profiles that the main project is using. This behavior helps to avoid version conflicts inside the project and enables you to keep working with a historical version (embedded copy) of a used project. If the main project is migrated, but the used project is not, you can still change the version of that usage. However will not be able to modify the used project with a new version of the modeling tool.
Let's analyze the example shown in the figure below. Imagine that you have a project (main project) that uses two other projects. This means that the copies of the used projects are embedded in the main project. in the The used project 1 is modified on a regular basis and you want to always use the latest version of that project. The used project 2 is finished and will not be updated in the future, so you will never have to update the version of this usage. In this case, you need to migrate the main project and the used project 1. Then you must update the version of the used project 1 in the main project, because a new version has been created during migration. However, you do not have to do anything with the used project 2. You only want to use a specific historical version of this project and its local copy has been already migrated together with the main project.
The logic behind used project migration.
Frequently asked questions
Q: Do I need to migrate all of the used projects?
A: No, you only need to migrate used projects if you want to be able change their version in the main project or modify them.
Q: Do I need to change used projects to their latest versions after migration?
A: Yes, if you migrate a used project, you need to change the version of it usage in the main project.
Q: What happens during migration if the main project uses a historical used project version?
A: When you use a project, a local copy of that project is created in the main project. That local copy is migrated together with the main project even if the used project itself is not migrated. Therefore if you migrate a project which uses a historical version of another project, you do not need to migrate the used project itself.