Migrating Data to SOLIDWORKS PDM: The Complete Checklist

Migrating data to SOLIDWORKS PDM succeeds when you treat it as a project with phases, not as a drag and drop. The short version: inventory and clean the source data, map metadata to PDM variables, design the folder structure, decide how much history to bring, rehearse the full migration in a virtual machine, then run a planned cutover and validate the result against the source. This checklist is the one we use on SOLIDWORKS PDM data migration projects, from small network drive imports to multi-terabyte moves from another PDM system.

Know your source

The source system shapes everything else. Identify it precisely before you plan.

Source	What you get	Main challenge
Network drives / shared folders	Latest files only, properties inside SOLIDWORKS files	Duplicates, broken references, inconsistent naming
SOLIDWORKS PDM Standard	Vault with history and variables	Usually an upgrade path to Professional rather than a migration; ask your reseller first
SOLIDWORKS Workgroup PDM	Files with revision history and metadata	Workgroup PDM is retired; history must be extracted and replayed or left behind
Another PDM or PLM system	Files plus a database of metadata and revisions	Export format, mapping lifecycle states, licensing of the old system during cutover
Another SOLIDWORKS PDM Professional vault	Full vault data	Vault to vault moves, merging variable and workflow definitions

If your source is a legacy system that will be switched off, check how long you can keep it read-only after cutover. That safety net changes how aggressive you can be about leaving old history behind.

Phase 1: Inventory and cleanup

Most migration problems are data problems that existed long before PDM. Find them while the data is still on a drive you can fix freely.

Inventory checklist

Check	Why it matters
Total file count and size by extension	Sizes the archive server and sets the batch plan
Duplicate file names	PDM can enforce unique file names; duplicates must be resolved first
Broken references in assemblies and drawings	Broken references will migrate broken
Files referenced from outside the migration scope	Missing children after import
Illegal or very long paths and file names	Import failures and path length issues on clients
SOLIDWORKS version distribution	Decide whether to upgrade files before or after import
Temporary and junk files (~$, backups, autosave)	Do not pollute the new vault
Custom property names in use	Input for the variable mapping

Duplicates and references

Duplicate names are the single most common blocker. Two files called bracket.sldprt in different project folders are fine on a network drive but conflict in a vault that enforces unique file names. Decide per duplicate: is it a true copy (keep one, redirect references), or a different part with the same name (rename and fix parent references)?

Fix references before the import, using SOLIDWORKS Pack and Go, rename tools that update parents, or a scripted pass with the Document Manager API. Then check again. A reference report from the source data is your baseline for validation later.

Properties

Export every custom property from the source files into a spreadsheet so you can see what you are really dealing with: five spellings of “Description”, part numbers stored in three different properties, units written as text. PDMShell’s docmanprops command reads custom and configuration properties through Document Manager without opening SOLIDWORKS:

docmanprops -directory "D:\Migration\Source" -csv "D:\Migration\props.csv" -recursive -extension "solidworks"

Clean the CSV, then write the corrected values back with -update before the import, or use it later as a property map.

Phase 2: Design the target

Metadata mapping to variables

For every property you keep, define the PDM variable, its attribute mapping to the SOLIDWORKS custom property (file level and configuration level), and its data type. Document it in a table like this:

Source property	PDM variable	Type	Config specific	Notes
Description, DESC, Desc	Description	Text	Yes	Normalize to one name before import
PartNo, Number	Number	Text	Yes	Join key to ERP
Material	Material	Text	Yes	Comes from SOLIDWORKS material
Rev	Revision	Text	No	Set by workflow, not by property

Set up data cards and variables in the test vault before the first trial import, so properties are picked up as files are added.

Folder structure

Resist copying the old drive structure. Design folders around how people find data (customer, project, product line, or a library folder for purchased and standard parts), and keep the depth reasonable. If you plan to use serial numbers, decide on number ranges per folder now. Our article on serial numbers and folder number ranges covers why this matters for performance.

Build a mapping file that lists every source file and its target vault folder. This file becomes the backbone of the scripted import.

History: latest only or full revisions?

Option	Effort	When it makes sense
Latest version only	Low	Network drive sources; old history stays in an archive
Latest plus released revisions	Medium	You need released revisions searchable in PDM
Full version history	High	Regulatory or contractual requirements

Replaying history means adding the oldest version, checking in, then overwriting with the next version, setting revisions and states along the way. It multiplies migration time. Many teams bring the latest released data, archive the rest read-only, and never miss it.

Workflow states

Decide what state migrated files land in. A common approach is a dedicated migration workflow or a “Migrated” state, with transitions into the normal workflow once files are reviewed. Files that were released in the old system can be moved to Released and given their legacy revision.

Phase 3: Test migration in a virtual machine

Never run the first real import against production. Build a VM with a copy of the vault database and archive, run the full migration end to end, and measure. Our virtual machine checklist for large data migrations lists what the VM needs, from SQL Server memory to disk layout.

During the test, record:

• Total runtime and files per hour, so you can plan the cutover window.
• Every error and its root cause.
• The vault size after import, for archive server sizing.
• What users see: run a quick acceptance session with a few engineers.

Run the test at least twice. The second run, with all fixes in place, is the one you trust.

Phase 4: Tools

Tool	Use it for
Drag and drop in File Explorer	Small, clean datasets
SOLIDWORKS Task Scheduler (Update Files)	Upgrading files to the current SOLIDWORKS version
PDM Administration data import	Importing variable values from XML using import rules
PDMShell	Scripted, repeatable bulk add, property, move and revision operations
Custom PDM API tools	Complex history replay, vault to vault, non standard sources

PDMShell commands for migration

PDMShell gives you a scripted and repeatable migration. Run it as Administrator for large add operations. A typical sequence looks like this.

Add files using a mapping CSV (source path, target folder), in batches, skipping files already in the vault, applying a property map and labeling everything that was migrated:

addtovault -map "D:\Migration\map.csv" -batch 100 -ignoreexisting -updaterefs -propertymap "D:\Migration\propertymap.csv" -label "Migration;Wave 1" -csv "D:\Migration\add_results.csv"

Files are left checked out after addtovault, so check them in afterwards:

checkin -search % -recursive

Set variables in bulk from a CSV whose first column is the file ID and the remaining columns are variable names:

setvarsfromsource -source variables.csv

Relocate files after import using a CSV of file IDs and target directories (target folders must already exist; PDM updates references and keeps history):

movefromsource -source "D:\Migration\movefiles.csv"

After upgrading SOLIDWORKS files, run a reference check and export problems to a CSV (the command also has a -bumprevision option for adjusting revisions in bulk after a file upgrade):

versionupgrade -search "Name=%.sldasm;Recursive=true" -referencescheck -csv "refcheck.csv"

The -skip and -count options on addtovault -map let you split a large migration into waves and resume from a known row. Full syntax for every command is on pdmshell.com.

Custom API tools

For history replay or unusual sources, a custom tool built on the PDM API is often the right answer. Use the batch interfaces (IEdmBatchAdd, IEdmBatchUpdate2 and friends) rather than file by file calls; the difference at scale is dramatic. See optimizing large scale operations with batch interfaces. Bulk creation through the API is a recurring topic on CADOverflow, for example creating thousands of virtual documents using the SOLIDWORKS PDM API.

Phase 5: Cutover plan

Step	Owner	Done
Announce freeze date and read-only window	PDM admin
Final backup of source data and target vault	IT
Set source to read-only	IT
Run delta inventory (files changed since test)	PDM admin
Run production migration in waves	PDM admin
Check in, set states and revisions	PDM admin
Run validation checks	PDM admin
Deploy client views and cache settings	IT
Go-live communication and support channel	Engineering manager
Keep source read-only for an agreed period	IT

Schedule the cutover over a weekend if the test run showed it will not fit in one evening. Have a rollback criterion written down before you start.

Phase 6: Validation

Validate against the inventory, not against a feeling.

• Counts: files per extension and per folder, source versus vault.
• References: run a reference check on top level assemblies and drawings; compare with the source baseline.
• Metadata: sample files per folder and compare variables to source properties; search for empty required variables.
• Open test: open a set of key assemblies and drawings in SOLIDWORKS from the vault with no missing references.
• Labels: search by the migration label to confirm every migrated file is accounted for.

Post-migration

• Remove migration only permissions and accounts.
• Clean up temporary migration workflows and states once all files have moved on.
• Turn on notifications and tasks only after the data is stable, or users get thousands of emails.
• Monitor archive and database size for the first weeks.
• Keep the mapping files and result CSVs; they are your audit trail.

Community discussions

• What PDM XML Import transaction types are there on CADOverflow
• Data migration Autodesk Vault to Solidworks PDM on the SOLIDWORKS Forum
• Has anyone migrated a PDM workgroup vault to PDM standard yet? on the SOLIDWORKS Forum

FAQ

How long does a SOLIDWORKS PDM migration take?

It depends on file count, history depth and data quality. Your test migration in a VM is the only reliable estimate, which is one more reason to run it.

Can I migrate revision history from network drives?

Network drives rarely contain real history, only copies with suffixes like _old or revB. You can replay those as versions, but most teams import the latest data and archive the rest.

Should I upgrade SOLIDWORKS files before or after migration?

Either works. Upgrading before keeps vault history clean; upgrading after keeps the import fast. If you upgrade after, plan for the extra version and any revision side effects.

What is the biggest PDM migration mistake?

Skipping cleanup. Duplicates and broken references do not fix themselves in a vault; they become harder to fix.

Need help with this?

We plan and run SOLIDWORKS PDM data migrations, including scripted imports, metadata cleanup and custom API tools. Contact us to scope your migration, or try PDMShell on a test vault.