How do you migrate a shared drive into SOLIDWORKS PDM?
Inventory and classify the source first, then move controlled batches through a rehearsed cutover. Resolve duplicate names and broken references, map source paths to vault destinations, test representative assemblies, freeze the source, import with traceable logs, validate counts and references, and leave one authoritative location after release.
CAD administrators, engineering managers, IT teams, and manufacturing groups replacing mapped-drive folders with a managed SOLIDWORKS PDM vault.
Migration tools and procedures vary by vault type, release, file volume, and data condition. Preserve backups and use an isolated test or pilot before production cutover.
Treat the shared drive as evidence, not as a folder tree to copy
Mapped drives accumulate years of shortcuts, copied projects, renamed assemblies, neutral exports, customer folders, templates, macros, tool libraries, and personal staging areas. The visible folder tree does not tell you which copy is authoritative or which references still point somewhere unexpected. Start with a read-only inventory that records paths, file types, sizes, dates, owners, duplicate names, and obvious archive groups.
Classify the data into active controlled work, reusable libraries, released records, historical reference, temporary output, and excluded material. Assign an owner to ambiguous sets. A migration team should not decide whether “Final,” “Final2,” or “Customer-approved” is the released design without a process owner and supporting evidence.
Capture the file relationships that matter to manufacturing: assembly references, drawings, design tables, external references, derived parts, templates, linked spreadsheets, PDFs, DXFs, STEP files, inspection reports, NC programs, and setup documents. Use SOLIDWORKS Find References on representative source assemblies and record dependencies that the inventory cannot infer from filenames alone. If a downstream file remains outside PDM, document the boundary and owner.
| Source class | Typical decision | Validation |
|---|---|---|
| Active CAD projects | Move with references and searchable metadata | Open representative top-level assemblies and drawings |
| Released records | Move read-only or through a released-state process | Revision and approval evidence agree |
| Libraries and templates | Central controlled destination with limited editors | Known test files resolve the intended resource |
| Historical archives | Import separately, retain externally, or exclude | Owner and retrieval method documented |
| Exports and temporary files | Regenerate, retain selectively, or exclude | No required manufacturing deliverable is lost |
Give every migration decision a row
The downloadable register connects each source path to its class, owner, duplicate group, reference status, destination, metadata, state, import result, validation result, exception, and acceptance.
Repair references and naming conflicts before import
Duplicate filenames are dangerous because a search can reveal several plausible results while a stored reference still resolves to a different file. SOLIDWORKS PDM can allow duplicates, prohibit them vault-wide, or prohibit them for selected extensions, so the migration rule must match the configured vault policy. Build a collision report and classify identical copies, customer-specific files, revision candidates, and unrelated same-name items.
Use representative top-level assemblies to expose reference problems. SOLIDWORKS PDM’s Update References wizard can repair references without opening the parent in SOLIDWORKS, but its Find Files option searches the vault for the same filename. Replace File can point one broken reference at a differently named or outside-vault file. Parent and referenced files containing changes must be checked out before updating.
Remove obvious operating-system debris and personal temporary content from the migration set, but keep an immutable source snapshot. Cleanup decisions need a register because the old drive may be the only way to explain why a file was excluded months later.
- Resolve identical duplicates with hashes and owner approval.
- Assign a rule for customer-supplied files that share common names.
- Test library, toolbox, template, macro, and design-table dependencies.
- Decide how released PDFs, DXFs, and STEP files relate to the controlling CAD revision.
- Document files that require an older application version or manual conversion.
Map destination, metadata, state, and permission together
A source path alone is not a migration specification. For each data class, define the vault folder, data-card values, initial workflow state, revision handling, permissions, and whether the file keeps its date or receives a migration comment. Mapping these together prevents a file from landing in the right folder with the wrong authority.
Keep required metadata small enough to be completed and useful enough to support search and release. Part number, description, customer or project, document type, and lifecycle state may be essential. Fields without a known owner or use often become blank columns that users stop trusting.
Run the mapping against a sample and inspect the result as multiple roles. Search for a part, open its parents and children, review card values, follow history, and confirm that a manufacturing user can retrieve the released package without gaining engineering edit rights. Decide the duplicate-filename policy before the first batch, then test whether the configured warning or prohibition behaves as intended.
Do not preserve chaos as structure
PDM can preserve history and references without reproducing every shared-drive folder. Use folders for stable broad organization, metadata for search, workflows for maturity, and permissions for authority.
Use pilot batches to prove the method and the timing
Select pilot batches with different risk: one clean recent project, one assembly with reused components, one customer folder with duplicate names, and one released job with manufacturing outputs. Measure inventory time, cleanup time, import time, and validation time separately. Copy speed is rarely the controlling variable.
Validate at three levels. File checks reconcile expected and imported counts. Relationship checks open assemblies and drawings, inspect Contains and Where Used, and export exception lists where useful. Process checks verify search, state, revision, permissions, and downstream deliverables. A green count cannot prove that the right revision will reach the machine.
Interpret PDM relationship views carefully. Where Used is based on the vault database and checked-in information, so local changes that have not been checked in are outside that evidence. Results can also be limited by user permissions. Run acceptance from controlled accounts, reconcile missing parents, and preserve the exported review record with the batch.
Record each failed pattern and update the migration rule before the next batch. If every batch requires a different manual rescue, the method is not ready for production volume. Stop and improve the classification or mapping instead of hiding uncertainty in a larger import.
Choose contrasting batches
Include clean, reused, duplicated, and released data so one easy project does not define the method.
Run the complete sequence
Inventory, repair, map, import, validate, and capture every exception.
Reconcile the evidence
Compare expected counts, hashes where useful, references, metadata, state, and user-role behavior.
Repeat after rule changes
A changed mapping or cleanup rule needs another representative test before cutover.
Freeze writes before the production move
The cutover plan needs an exact freeze time, source snapshot, owner for late changes, migration batch order, validation owners, go-live authority, rollback criteria, and communication plan. Turn the shared drive read-only or otherwise prevent normal edits during the final move. A warning email is not a technical control.
Keep a change register for emergency work that cannot wait. The owner records the file, user, reason, source and target handling, and final validation. Without that register, a legitimate overnight edit can disappear between the source snapshot and the released vault.
Before opening normal access, pilot users should retrieve and revise representative jobs from their production workstations. Verify references, local views, add-ins, search, permissions, workflows, and released outputs. If a stop condition occurs, follow the written rollback. Improvised partial reversals create two libraries that both appear current.
| Cutover task | Owner evidence | Acceptance question |
|---|---|---|
| Source freeze | Read-only control and timestamped snapshot | Can any normal user still create a competing edit? |
| Final import | Batch logs and exception register | Did every approved source set reach its mapped destination? |
| Technical validation | Counts, references, services, backup status | Is the vault complete and operable? |
| Business validation | Role-based job tests | Can each team perform day-one work with the correct revision? |
| Go-live decision | Named approval or rollback record | Is one system now authoritative? |
Retire the old write path and watch for shadow data
Leave the source snapshot protected according to the retention plan, but remove ordinary write access and shortcuts that make it look like the production workspace. Users will follow the fastest familiar path when pressure rises. If the old path remains writable, the migration continues indefinitely and revision authority becomes a conversation again.
During the first weeks, review files created outside the vault, missing card values, reference errors, permission requests, and support tickets. Correct training and configuration issues quickly, but route structural changes through the vault owner and process owner. A stable release window makes the actual defects visible.
Close the migration only when the register reconciles, exceptions have owners, the old environment has a defined retention state, and business owners accept the migrated data. The final deliverable is not an imported file count. It is a controlled source of truth the shop can operate and recover.
Frequently asked questions
Can SOLIDWORKS files be copied directly into a PDM vault?
Files can be added, but a production migration also has to preserve and validate references, resolve duplicate names under the configured vault policy, assign metadata and state, and control the source during cutover. A direct bulk copy without those controls can move existing uncertainty into the vault.
Should the shared drive remain writable after PDM goes live?
Normally, no. Keep a protected snapshot according to the retention plan, but remove normal write paths so the vault becomes the single authority. If emergency work must continue during cutover, capture it in a controlled change register and reconcile it explicitly.
How do you validate a SOLIDWORKS PDM migration?
Reconcile file counts and exceptions, open representative top-level assemblies and drawings, inspect references, verify metadata and lifecycle state, test search and permissions by role, and confirm that released manufacturing outputs match the controlling revision.
What data should be cleaned before a PDM migration?
Prioritize duplicate filenames, broken or external references, ambiguous revisions, personal temporary files, uncontrolled libraries, obsolete exports, and content with no owner. Preserve a source snapshot and record every exclusion or rename decision.
Vendor references and method
- SOLIDWORKS 2026 Help: Updating File References, official repair options, same-name search boundary, CSV export, and check-out requirement
- SOLIDWORKS 2026 Help: Preventing Duplicate File Names, official configurable vault-wide and extension-specific duplicate policy
- SOLIDWORKS 2026 Help: Where Used, official relationship-view, checked-in database, permission, and CSV-export behavior
- SOLIDWORKS 2026 Help: Find References, official source-side reference inventory for assemblies and drawings
- SOLIDWORKS PDM implementation checklist for machine shops, companion Morphos 3D implementation framework
- Checklists, sequencing, and decision gates on this page are Morphos 3D implementation guidance. Adapt them to the exact software release, infrastructure, machine, controller, quality system, and approved company procedures.
Scope the migration before the freeze date
Start with a source inventory and at least two contrasting assemblies to expose the naming, reference, and ownership decisions that control the project.