Page History
On this page:
| Table of Contents | ||
|---|---|---|
|
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.
| Note |
|---|
|
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.
Tip 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.
| Warning | ||
|---|---|---|
| ||
|
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 is was only partially successful and you get the list of some 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 Standard/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 This section , you will learn how to decide whether or not 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 in into 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 start using the same updated standard/system profiles that the main project , even if the used projects itself are not migrateduses. 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, the project usages (embedded copies of used projects remain unchanged, but they start using the same updated standard/system profiles that the main project is using) 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 a historical version (embedded copy) of a used project. If the main project is migrated, but the used project is notthe historical versions of used projects without migrating them.
To sum up, even if used projects are not migrated, 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 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.
The logic behind used project migration.
Frequently asked questions
Q: Do I need to migrate all of the used projects?
A: No, in most cases you only do not need to migrate your used projects if you want to be able change their version in the main project or modify them. 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: Yes, No, you do not need to change the versions of used projects after migration. Even if you migrate a used project , you need to change the version of it usage in the main projectand 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 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. 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.)