We will soon be migrating our database from SW 2014 -> SW 2019.
Being under EPDM, I would like to know what are your practices / feedback for this kind of update of all the files in the database:
1) you block the work of all your SW users and migrate the entire database using the "SOLIDWORKS PDM File Version Upgrade Tool" using all stations as slaves. It takes as long as it takes, but once finished, all your users open their files normally with their new Solidworks. Last time I did this and migrated the files starting with the .sldprt then the .sldasm to finish with the .slddrw. But our database has swollen in 5 years and I'm afraid that the conversion time is ultra long and that we will block users for several days.
2) you migrate your database 'as you go' using the "SOLIDWORKS PDM File Version Upgrade Tool": like you make batches of 5000 files to migrate every night. It is on this option that I would like to have feedback from people who have managed their migration in this way. What happens to the way users work when we are in the transition phase where the entire database is not yet converted? Does cutting the conversion 'into a puck' pose any particular problems? Management of the different types of files (you follow the order .sldprt then the .sldasm to end with the .slddrw or you do the directory by directory migration without differentiating the file types)?
3) you don't use the "SOLIDWORKS PDM File Version Upgrade Tool" at all: I'm also interested in that
Note: I only plan to migrate the latest version of the files and create a special version of the converted file.
Personally, it's as you go. Files are migrated as they are used.
The only elements I update are the libraries, and that I start the conversion on Friday evening, and via remote connection to my machine I take a look from time to time
Edit: I still use data recovery from mycadtool to output a broken list of references just in case
With us we identify files to be converted and an order to convert them (without distinction of prt, asm and drw) starting for example with our library files (screws, nuts, crimped elements...).
To do this, we use the File Version Upgrade utility and we cut off access to the database to prevent extracting files. In addition, as we delete the trunk views to redo them (automated installation since there are a good twenty workstations to install), any extracted file would be lost. This year we had 7 conversion workstations available (take the fastest if you don't have a homogeneous pac to have a short processing time since the utility does not distinguish between a large assembly that would have to be opened on a powerful set and could just as easily open it on a "slow" set).
To avoid blocking everyone for too long, in general we cut off the accesses on Fridays from 12 noon to reopen them on Monday around 9 a.m. (this year the conversion time was shorter than in previous years so we could have opened the accesses as early as 7 a.m. on Monday).
We have also implemented a variable to identify the files to be converted for the next few years (it is estimated that a file that does not move state in certain folders is therefore no longer used and does not need to be converted).
For now, I do advise you to create an additional version rather than a version replacement. We had a problem this year with this version replacement feature (this is not related to the utility but to this PDM function at first glance).
Edit: on the other hand, taking a version can significantly increase the volume of the archive database depending on the number of files converted.
On the other hand, your environment is rather a special machine with a directory per machine and no common components except the screws?
For us, assemblies are specific, but there are still many parts that are not in library directories but are used in dozens of assemblies. Roughly speaking, in an assembly we have 5 to 10% specific, 30% bolts/library parts and 60% 'common' parts (parts managed like specific ones but with many use cases). These common pieces must represent at least a thousand pieces and they are scattered in about 40 repertoires each containing 1000 pieces (it's a bit of a needle in a haystack)
Froussel, in this case I would update the common files and the library with a machine like a conversion robot connected to a PDM administrator.
At home the common elements and the library are locked in modification for ordinary users, only the admin has the right to modify these files, or super user but they have to go through changes of state and justification for the passage to modification.
edit, ah yes I forgot any common file and library are in specific folders which makes it easier to search
So if you reopen an old assembly that is not converted, you convert all the files contained in the assembly? Or you just make the changes you need and you don't update all the components used by the assembly (so opening with half of the files converted and half not converted the next opening)?
If the whole is modified, and therefore set up as an index, then it is converted. But if in the batch some file does not go up in index then it remains in the previous version.
I noticed that this is not a problem since a recent version easily opens files after SW 98
On the other hand, what I did some time ago is to use integration and make it rebuild the SW files before 2010 in systematics.
If your database remains entirely in 2014 it won't be a problem to use and update as changes are made
In our case, few components are common between the projects, except for a few components of screws in the library.
So I never used the update tool, because usually once the project is finished you don't come back to it, and when this is the case since our assemblies are not too large, the component updates are quick to do (if you need to).
So out of curiosity I think I'm going to do a test on the screw library.
You should know that on some functions/parts the update is really essential: on my very large library functions (up to 380 configurations representing different sizes) if you try to edit in 2019 a library function that remained in SW 2014 grinds for 5 to 10 minutes (it converts all the configurations) while if the library file is converted beforehand you just have to change the configuration and it takes 5s.
A quick test I did also shows that an unconverted assembly opens 2x slower than the converted assembly. A nice thing on the other hand is that my converted drawing opens faster than the original drawing under SW2014.