On this page:
Once you have successfully migrated your data to a new version of Teamwork Cloud, you must update the projects in the database as well. A project that is not updated will open in the read-only mode. When you open a project in a modeling tool, the following notification appears.
You will not be able to edit a project until you update the project to the latest version.
You can see the same notification in the Notification Window. Therefore, you must update the project before you can edit it.
Editing a project that has not been upgraded to the latest version is not allowed.
- To upgrade a project by migrating it, you need the Administer Resources, Edit Resources, Edit Resource Properties, and Read Resources permissions.
- While a project is being migrated, other users are prevented from any modifications in that project. We highly recommend that the same person migrates all projects.
Migrating server projects automatically
To migrate server projects automatically
- Start the modeling tool and log in to the Teamwork Cloud server.
- From the Collaborate menu, select Migrate Project to Version X. The dialog Migrate Project to Version X opens.
Select projects to migrate. Do one of the following:
On the dialog toolbar, click
to select all server projects.Select category (or categories) to migrate with all projects inside it.
Select separate projects from category (or categories).
Migration of UAF and UPDM projects
- The UPDM project migration from the modeling tool with the UAF environment will not be performed. However, if you want to migrate the UPDM project to UAF, you need to open the magicdraw.properties (or cea.properties) file and change the value of the system property -Dmigrate.project.from.updm2.to.uaf\=false to True. By default, the value of this property is False, which means, that your UPDM projects will not be migrated.
- For more information about UAF project migration issues, see Project migration issues on Teamwork Cloud.
- The cache data format was changed since version 2024x. To avoid slowing down history-related operations and the initial post-migration project load when migrating projects to version 2024x or later, consider using the Speed up model history-related operations option. This will generate new project caches on the server during migration.
- Select Enable migration of password-protected projects to enable selection of password-protected projects. During the migration process, you will be prompted to enter a password for each of the password-protected projects you selected to migrate. If this option is not selected, after the project migration is completed, you will get a message with a list of password-protected projects that were not migrated. You must migrate those projects manually.
After the project migration is completed, you will either get a message about successful project migration or a list of projects that were not migrated. You must migrate those projects manually.
Migrating server projects manually
To migrate server projects manually (for a user role with the Administer Resources permission)
- Start the modeling tool and log in to the Teamwork Cloud server.
- On the main menu, click Collaborate > Projects. The Manage projects dialog opens.
- Select a project and click Open. A dialog prompts you to update the System/Standard Profiles in the project to allow project editing.
- Click Continue. After the System/Standard Profiles are updated, the modeling tool opens a notification showing that the model was successfully updated.
You can also see the same notification in the Notification Window.
You can open the Notification Window by pressing Ctrl + M or clicking Window > Notification Window.
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.)