4 Replies Latest reply on Jul 5, 2017 3:36 PM by Paul Wyndham

    Upgrading Workgroup PDM to PDM Professional - Is it necessary to create a new vault?

    Barry Watkins

      We are upgrading Workgroup PDM to PDM Professional. Is it necessary to create a new vault or can we just keep using the old vault?

        • Re: Upgrading Workgroup PDM to PDM Professional - Is it necessary to create a new vault?
          Michael Dekoning

          Yes. It is different software not a new version. You will need to migrate all of your files from your Workgroup vault to a PDM Professional vault.

          • Re: Upgrading Workgroup PDM to PDM Professional - Is it necessary to create a new vault?
            Steve Ostrovsky

            PDMWorks to PDM Pro is not an upgrade but a migration of data. By virtue of moving to new software you will be creating a new vault. The good part is that your old vault should come right over so check with your VAR on migration needs.

            • Re: Upgrading Workgroup PDM to PDM Professional - Is it necessary to create a new vault?
              John Matrishon

              Barry, the two vaults are very different.  As Mike and Steve said, it is not an upgrade.   To migrate your data, you need to go through your VAR unless you are going to put everything in yourself.   Your Workgroup vault is older 32bit flat-file format (kinda like a secure network folder with fancy client controls), PDM Pro is SQL full up true Database.    This is good, if done correctly.   As Steve said, you should be checking with your VAR on this as you want to get it right the first time.  PLAN.TEST. repeat.   You want the software to work for you, not against you.


              • Re: Upgrading Workgroup PDM to PDM Professional - Is it necessary to create a new vault?
                Paul Wyndham

                What you can do in preparation for the data migration is to recreate the WGPDM vault configuration in a new SWPDM Pro vault. I found these to be some key things that the new vault must have that mimic the WGPDM vault:

                • A copy of the revision schema - It not only has to have a revision letter/number of every one in WGPDM's current schema, but it also has to include any revisions that are in any of the files that are still in the vault. (for example: Lets say initially you had AA, A, B, C, D as your schema, then sometime later removed the AA. Now most of your files were created after AA was removed, but 5 of them still have that Revision number attached to them you have to include it in your new vault.)
                • If you have any lifecycles states in WGPDM - ALL of them need to exist in the new vault. A link needs to exist between all the states so that the migration tool can change states at will to follow the flow from the file that was in WGPDM.
                • Any custom properties used in WGPDM need to exist in the SWPDM vault as variables.
                • You don't need to worry about any of the users. It doesn't matter since the migration tool just uses the user that is logged in. The admin account works fine, or you can create an account that has all the needed permissions.
                • It doesn't matter what folders you put in the new vault as the migration tool creates the new folders at the root level of the vault folder. You can move them around after the migration completes.
                • The migration workflow must be applied to the root of the vault during the migration process


                Other requirements or Tips:

                • Have both vaults setup and running on the main SWPDM Archive server - The data server could be different then the archive server by should be on the same LAN.
                • Have 3 times the WGPDM vault size available on the server
                • If possible have on-access virus scanning turned off for the duration of the migration. I found that on-access scanning would scan the file 3 times during the migration.
                • Have WGPDM and SWPDM of the same version
                • Have SWPDM client installed on the archive server doing the migration and of course make sure it can access a PDM license
                • Make sure the WGPDM vault is rebuilt recently
                • Have everyone release ownership of everything if possible. Or use an administrator account to release it for them or for those that are no longer with the company.
                • WGPDM allowed duplicate names, so make sure that is allowed during the migration or you might have duplicate name issues.
                • Don't have any automatic transitions or state change requirements in the migration workflow during the migration.
                • Make sure the workflow is setup with the correct revision schema.


                That is off the top of my head so forgive me if I missed anything.

                As others said - testing is important as you might not find all the issues until you have run a test migration a couple times. I found that when one issue was corrected it would progress farther and maybe find a different one that it didn't get to or you missed the first time.