Hi Pascal

This is only an issue if users don't have any concept about where they store their own data and simply use the default mechanisms of the software they use.

If they would store their projects, templates, TMs and TBs in their own folder structure, they would never face  this problem.

Maybe these freelance users need some training on project handling[:)]

And yes, Paul's articles are very helpful to understand the way it works and also to manage a version migration (especially with the new "Migration Utility").

Walter

Hi Walter,

Thanks for your reply!

> If they would store their projects, templates, TMs and TBs in their own folder structure, they would never face  this problem.

So a new Studio version would automatically know where the projects from the old version are stored? How so?

> Maybe these freelance users need some training on project handling[:)]

I certainly agree. However, if users are more or less compelled to work with Studio because their clients demand it, their motivation to get the necessary training will often be quite low. You might say that's their own problem, but making the software more intuitive to use, thereby facilitating adoption by new users, also helps supporters – and improves the brand image in the long run.

Pascal

Pascal Murer said:

So a new Studio version would automatically know where the projects from the old version are stored? How so?

Hi Pascal

It is not fully automatic, but if one works with project templates, he would simply need to import his project templates once after migration.

In addition, the latest CU3 now offers the ability to include the project path into the project settings, which will make things even easier. 

Have a look at this other interesting article from Paul. 

Walter

Unknown said:

It is not fully automatic, but if one works with project templates, he would simply need to import his project templates once after migration.

Hi Walter,

I would recommend not to do this unless the migration is from one computer to another (same version of Studio) as opposed to one version of Studio to another.  This is because you potentially introduce bugs from the old version that have been fixed into the new one, particularly around filetypes.  the migration of project templates is something I have on my wishlist for the migration app and it's not a trivial task.

Regards

Paul

Unknown said:

BTW: what procedure would you suggest for project templates at migration time (until the migration app to come does this for us)?

Not a good one I'm afraid!  I would recreate them manually.  I appreciate how painful this is for many users who have lots of templates, but after seeing the problems that can occur I think this is still preferable to having to resolve the problems afterwards and still end up having to migrate manually.

I guess it might be a bit faster if you create one generic project template with everything you need across all templates and then copy it in windows as many times as needed, renaming each one as you go with the appropriate naming convention you need.  Then enter each one and make any project specific changes you need.

You might be able to find a sensible workaround using projects as the basis of new templates, or perhaps create them as needed as you go.  So when you create a project set it up as needed and then save it as the new template.  Probably the same amount of work but merged into more productive tasks.

Regards

Paul