How to Migrate From Network Folders to PDM Without Chaos

Almost every SOLIDWORKS PDM project we get called into has the same backstory. The design team has been working off a network share for eight, ten, fifteen years. There are folders called OLD, OLD_OLD, 2019_backup_DO NOT USE. Somebody's desktop is the only place the latest version of one assembly exists. Two parts share the same filename, and one drawing references a part that was renamed in 2021.

Then the vault gets installed, the files get dragged in, and within six weeks the team is quietly working around PDM again — emailing zips, saving to the share "just for this one job."

The installation was never the hard part. Getting the existing data in cleanly is the hard part, and it is the step most often skipped. Here is the approach that keeps a network-folder migration from turning into chaos.

Why migrate off network folders at all?

It helps to be able to answer this before you start, because the answer decides how much effort is justified. A shared drive gives you storage. It does not give you:

• A single source of truth. Nothing stops two engineers editing the same assembly at once, and nothing tells you who won.
• Revision history that means anything. "Copy of Bracket_rev2 (Rahul's conflicted copy)" is not a revision trail.
• Reference integrity. Move or rename a file in Explorer and every drawing that pointed at it silently breaks.
• Access control and auditability. Everyone who can open the folder can read, overwrite or delete your intellectual property — and there is no record of who did.
• Search. You cannot find "every part made from 316 stainless, approved this year" in a folder tree.

That last point matters commercially: legacy design data is often the most valuable asset a manufacturer owns, and most of it is effectively unsearchable and unprotected.

The four things that actually cause the chaos

1. Duplicate file names. Two different parts called Bracket.SLDPRT in two different customer folders. In a vault with unique-name enforcement, one of them cannot exist. This is the single biggest source of migration pain.
2. Broken references. Assemblies and drawings pointing at files that were moved, renamed or deleted years ago. These files look fine on the share because nobody has opened them.
3. Inconsistent metadata. Material, description and part number typed by hand — or not typed at all — into custom properties. What maps to what?
4. Nobody owning the cleanup. "We'll tidy it up after go-live" is how you end up with a vault that is just a network folder with check-in buttons.

Phase 0 — Decide what is actually worth migrating

You do not have to move everything. A surprisingly small share of the data is live; the rest is history, superseded revisions, and other people's exports. Agree up front on three buckets:

• Live designs — in production or actively being worked. Full migration, full metadata, correct references.
• Reference archive — older designs that must be retrievable for spares, service and regulatory reasons, but nobody is editing. Migrate read-only into a controlled "Archive" state, or leave on a read-only share if volume justifies it.
• Dead weight — personal copies, zips, other people's exports, trial files. Leave them behind on a read-only share and put a date on when it gets deleted.

Write that decision down and get it signed off by the engineering manager. This one page saves weeks.

Phase 1 — Audit before you touch anything

You cannot fix what you cannot see, and no one can inspect 40,000 files by hand — and sampling a few folders never shows the real picture. Run an automated scan of the share first. Tools built on the SOLIDWORKS Document Manager, AutoCAD and Windows APIs will give you a health report on:

• duplicate file names across the dataset
• missing files and broken or incorrect reference paths
• files with no metadata, or metadata that contradicts the filename
• the true age profile of the data — what is genuinely still in use

That report is what tells you whether this is a two-week tidy-up or a managed migration project, and it gives you a defensible effort estimate instead of a guess. Do this before quoting the customer a timeline.

The most common migration failure is not a technical one. It is promising a go-live date before anyone has scanned the data.

Phase 2 — Design the vault before a single file moves

Importing into a vault you haven't designed is how you get a network drive with extra steps. Settle these five decisions first:

1. Folder structure. Map the current tree to the target vault structure. Very often the right answer is a flatter structure organised by project or product line, with metadata doing the work the folder tree was doing badly. Keep it shallow — deep folder hierarchies are a symptom of not having properties.

2. Metadata and variables. Decide which properties become PDM variables, which are mandatory, and what happens to the inconsistent ones. Plan any concatenation, splitting or injecting of values from an ERP export or spreadsheet — do this in bulk, not by hand.

3. Lifecycle and workflow states. Both PDM Standard and PDM Professional use workflow states for security and revision labels. Decide which state migrated data lands in — usually "Released" or "Archive" for finished work, "In Work" for anything mid-design. Never import historical files into a state that makes them look editable and current.

4. Revision strategy. Carry over existing revision labels (best for traceability, and what auditors want) or start clean (simpler). Carrying over is usually the right call for anything with a customer or compliance history.

5. File naming and unique names. Turn on unique file names across the vault. This is non-negotiable for reference integrity — and it is exactly what forces you to resolve duplicates before import, when it is still cheap.

One more decision most people forget: which PDM edition are you building? SOLIDWORKS PDM Standard is included with active subscription and covers up to 10 CAD-Editor seats at a single site — which is where most network-drive teams start. If there is more than one office, more than 10 users, or the company wants branching approval workflows, web access or ERP integration, plan for PDM Professional from the beginning. Retrofitting Professional mid-migration means doing the mapping work twice.

Phase 3 — Clean up in place, before the vault

Fix the data on the share, where you can still see the original folder context. Resolve duplicate names (rename with a real part number or project prefix), repair broken references, and normalise the custom properties. Then re-run the audit scan and compare the two reports — that delta is your proof the migration is ready, and it's a great thing to show a customer's engineering manager.

This is also the moment to point out that the cleanup is not wasted effort: every duplicate resolved and every reference repaired is a problem the team would otherwise have hit in the vault, at the worst possible time.

Phase 4 — Rehearse, twice

Migrate a representative pilot: one product line, or roughly 5–10% of the data, including at least one large assembly with drawings. Into a test vault, never production. Then check:

• do assemblies open with no missing components?
• do drawings resolve to their models and show the correct revision?
• do the metadata, workflow state and revision labels land where you planned?
• do where-used and search return sane results?
• do toolbox and library parts behave?

Fix, throw the test vault away, wipe it and run the whole thing again from scratch. The second rehearsal is where the real timing comes from — the final migration should be a script you have already executed, not a first attempt.

Phase 5 — Cutover: own the freeze window

The actual transfer of prepared data can be a matter of hours. The discipline is around it:

1. Announce the freeze. A hard date and time when the share goes read-only. Give people at least a week's notice and name a person they can appeal to, so exceptions are rare and documented.
2. Take a final backup of the share. This is your rollback, and it is not optional.
3. Capture the delta. Files touched between rehearsal and freeze get migrated last and checked individually.
4. Migrate, then validate against your rehearsal checklist — not by spot-checking whatever looks interesting.
5. Unfreeze into the vault. From this moment the share is read-only, permanently. Point shortcut icons at the vault. Nothing gets written back to the old tree, ever, or you have two sources of truth and the migration has failed.

Run cutover over a weekend or a planned shutdown if you can. Migrating while people are still designing is how the delta capture becomes unmanageable.

Phase 6 — The first 30 days decide whether it sticks

Adoption is a data problem, not a training problem. If the old share stays writable, people will use it — usually the most experienced engineer first, and everyone else follows. So:

• Make the old share read-only within 24 hours of go-live, and delete it on a published date.
• Get all the live data in at go-live. Partial migration creates a permanent two-system habit.
• Train on the team's own models, not a demo assembly. Check-in, get latest, where-used, and how to find a part — nothing more, on day one.
• Put one person in charge of the vault: permissions, new users, workflow tweaks. A vault with no owner rots.
• Watch the first month's activity. Files that never get checked out, folders nobody touches, and repeated "missing reference" tickets tell you what the audit missed.

The checklist, condensed

• Decide what migrates, what archives, what dies — in writing, signed off
• Automated data audit before committing to a date
• Design folder structure, variables, workflow states, revision policy, unique naming
• Clean duplicates and broken references on the share, then re-audit
• Pick PDM Standard vs Professional knowingly, not by accident
• Rehearse into a test vault twice; time it from the second run
• Hard freeze, backup, migrate, validate, unfreeze into the vault
• Old share read-only immediately; no dual systems
• Name a vault owner and train on real models

None of this is exotic. It is just sequencing — assess, design, clean, rehearse, cut over once, then hold the line. Teams that skip the middle three steps spend the following year blaming the software for a data problem they imported themselves.

If you are still on a network share and want to know what a migration would actually involve for your data, the useful first step is not a demo — it is an audit of the share. That tells you the scope, the risks and the realistic timeline, and it is a much better basis for a decision than a gut feel about how messy things are.