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

  1. Start the modeling tool and log in to Teamwork Cloud.
  2. In the main menu, go to Collaborate > Migrate Projects to Version X.
  3. 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.




  4. 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.
  5. 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. 

  • 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 you do not want to migrate multiple projects with their branches at once, you can migrate these projects manually. You can also use this approach if automatic project migration was only partially successful and some projects were not migrated.


To migrate server projects manually

  1. Start the modeling tool and log in to Teamwork Cloud.
  2. Open the server project that was not migrated.
  3. When the Incompatible Standard/System 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

This section explains if you need 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 into the main project. When you migrate the main project, the embedded copies of used projects start using the same updated standard/system profiles that the main project uses. The same thing happens if you use a non-migrated project (committed with an earlier version of a modeling tool) in a migrated project. In other words, project usages (embedded copies) become migrated in the context of the main project, even if the used projects themselves are not migrated. This behavior helps to avoid version conflicts inside the main project and enables you to keep working with the historical versions of used projects without migrating them.

To sum up, even if used projects are not migrated, you can still do the following:

  • Work with the main project as usual.
  • Change the versions of used projects in the main project.
  • Continue to modify used projects using an earlier version of a modeling tool (as long as it is compatible with the version of the upgraded server).

However, if you do not migrate used projects, you will not be able to modify them with a new version of a modeling tool. They can only be opened in the read-only mode.


Frequently asked questions

Q: Do I need to migrate all of the used projects?

A: No, in most cases you do not need to migrate your used projects. You will be able to work with the main project as usual and even change the versions of the usages if needed.

Q: Do I need to change used projects to their latest versions after migration?

A: No, you do not need to change the versions of used projects after migration. Even if you migrate a used project and a new version of that project becomes available on the server, the project content stays the same.

Q: What happens during migration if the main project uses a historical used project version?

A: When you migrate the main project, used projects are migrated automatically but only in the context of the main project. (The embedded copies of the used projects start using the same updated standard/system profiles as the main project.)