SOLIDWORKS PDM Implementation & Legacy Data Migration

01 It Is a Change Programme

Vault implementations rarely fail on technical grounds. The software installs, the servers work, the workflow functions. They fail because the organisation was not ready to work differently, and nobody treated that as part of the project.

Introducing managed data changes how engineers work every hour of the day. Files must be checked out before editing and checked in afterwards. Released documents cannot be modified. Approval becomes a system event rather than a signature. Work in progress becomes visible to colleagues. Each of these is defensible, and each is friction relative to a shared drive.

Scoping the work as an IT installation guarantees that this friction is discovered at go-live, by the people least prepared for it, with no time allocated to address it. The implementations that succeed allocate as much effort to process definition, migration preparation and adoption as to installation.

ProcessDefined and agreed before any configuration begins

CleansedLegacy data repaired before migration, not after

ReferencesIntegrity preserved through migration is the critical risk

CutoverA single date — dual running does not work

Scope and currency

Migration tooling and its capabilities change between releases and differ between capability tiers. Verify available mechanisms against the administration guide for your release and tier, and discuss volume migrations with your reseller — bulk import approaches change more than most parts of the product.

02 Phasing

Phase 1DefineDocument the change process, revision scheme, approval authorities, property schema and folder structure. Agree them with the people who own the process, not just with engineering. Nothing is configured in this phase.
Phase 2BuildInstall the servers, configure the workflow, data cards, permissions and numbering against the agreed design. Test every path with role accounts in a non-production vault.
Phase 3Prepare the dataAudit and cleanse legacy data — duplicate filenames, broken references, orphans, files with no owner. This runs in parallel with build and is almost always underestimated.
Phase 4PilotA small group runs real current work through the vault for several weeks. The purpose is to find process problems, not software faults.
Phase 5MigrateMove the prepared data in, with reference integrity verified as it lands. Set initial states and revisions deliberately.
Phase 6Cut overA defined date after which the shared drive is read-only and all work happens in the vault. Short freeze, clear communication, support available.
Phase 7StabiliseWeeks of active support, workflow adjustment on evidence, and permission corrections. Budget for this rather than treating go-live as the end.

Where the effort actually goes

Organisations consistently expect installation and configuration to dominate, and consistently find that data preparation and adoption dominate instead. Installation is days. Configuration is days to weeks. Data cleansing on a mature file estate is routinely weeks to months, and adoption support runs for a quarter.

Planning on that basis from the outset is the single largest predictor of a smooth implementation, because it means the difficult work has time allocated rather than being discovered.

03 Deciding What to Migrate

The instinct is to migrate everything. It is almost always the wrong decision, because it multiplies the cleansing effort by data that will never be opened again.

Migration scope decision framework
Category	Recommendation	Reasoning
Active projects	Migrate	In daily use; the whole point of the exercise
Current released products	Migrate	Referenced by production, spares and support; needs revision control
Shared libraries and templates	Migrate early	Referenced by everything else; must be in place before dependent data
Recently superseded designs	Migrate selectively	Useful for reference and reuse; migrate at a lower state and lower priority
Obsolete products	Archive in place	Retain as a read-only archive; migrate individual items on demand if ever needed
Abandoned and duplicate work	Do not migrate	Migration is the natural moment to stop carrying it forward
Personal working copies	Do not migrate	By definition not the controlled version; migrating them creates duplicates

Keep the legacy store read-only, do not delete it

Whatever is not migrated should remain available as a read-only archive, backed up, with someone able to find things in it. Deleting unmigrated data at cutover is a decision that cannot be revisited and will eventually be regretted over one obscure drawing.

Read-only matters as much as retained. A legacy store that remains writable becomes a shadow system, and the organisation ends up with two places where current work might live — which is worse than either alternative.

04 Pre-Migration Cleansing

Every defect in the legacy data becomes a defect in the vault, and correcting it afterwards is harder because the data is now under version control. This phase determines the quality of the result.

Defects that must be fixed first

Duplicate filenames. The vault enforces uniqueness, so duplicates will block migration or resolve unpredictably. Identify and rename with reference-aware tooling before migrating.
Broken references. An assembly that cannot resolve its components will migrate incomplete. Repair before, not after.
In-context references across projects. These carry dependencies that will behave unexpectedly once files sit in a controlled structure. Resolve or break them.
References to personal locations. Anything pointing at a user's own drive will not survive.

Defects worth fixing if time allows

Missing or inconsistent properties. Bulk property population is far easier before migration than after.
Unassigned materials. Parts reporting no mass will populate blank columns in the vault.
Old file format versions. Files not opened in years may need conversion, which is better done deliberately than discovered.
Orphaned drawings. Drawings whose models no longer exist should be identified and dealt with as a decision.

Audit before you plan

Run a reference and duplicate audit across the intended migration scope before committing to a timeline. The result frequently changes the plan — a data set with thousands of duplicate filenames is a different project from one with a dozen.

The audit output also gives you the argument for scope reduction. It is much easier to agree not to migrate obsolete data when you can show what cleansing it would cost.

05 Migration Mechanics & Reference Integrity

The critical technical risk. Files can be moved into a vault in ways that preserve the reference graph and in ways that quietly break it.

Order matters

Migrate from the bottom of the dependency graph upward. Library content and shared components first, then parts, then assemblies, then drawings. Migrating an assembly before its components means the assembly resolves against files outside the vault, and those references persist.

Where a project is migrated as a unit, the whole dependency set must move together. A project referencing a shared library that has not yet migrated will point outside the vault, and the reference will need repairing later — at which point the file is under version control and the repair itself becomes a revision.

Verify references after each tranche, not at the end

Reference breakage discovered after the entire migration is complete is expensive to trace, because there is no way to tell which tranche introduced it. Verify integrity after each batch: open a sample of assemblies, confirm every component resolves inside the vault, and confirm drawings resolve to their models.

A migration that verifies as it goes can be halted and corrected. One that verifies at the end can only be repeated.

Approach

Migrate in tranches by project or product line. Smaller units are easier to verify and to roll back.
Do it with the vault otherwise quiet. Migration generates substantial archive and database activity.
Preserve the check-in as a single operation per tranche where the tooling allows, so references are established in one pass rather than incrementally.
Take a full vault backup between tranches. A verified backup is the only viable rollback position once data is in.
Record what was migrated and when. A simple log per tranche, with the verification result, is invaluable when something is queried months later.

06 Initial States, Revisions & History

Migrated data arrives with no history and must be given a starting position. These decisions are effectively permanent.

Initial state

Data that was released before migration should arrive in the released state, not in work. Migrating everything as work in progress means the vault initially asserts that nothing is approved, which is both wrong and disruptive — a production function looking for the current released drawing will not find one.

This requires knowing which files were released, which is one reason the cleansing phase matters. Where release status cannot be reliably determined, a defensible position is to migrate at released state anything referenced by a current production item, and at a lower state everything else.

Initial revision

Carry forward the revision recorded in the legacy data where it is trustworthy. Where it is not — inconsistent schemes, revisions in file properties that disagree with the drawing, or no revision at all — a clean start at a defined baseline is preferable to importing unreliable values that will be treated as authoritative afterwards.

Historical revisions generally should not be migrated

The instinct to import every past revision so the vault holds complete history is understandable and usually a mistake. It multiplies migration volume and complexity, the imported history has no genuine workflow record behind it, and it produces a version tree that implies an approval trail which never existed in the system.

The better arrangement is to migrate the current revision as the vault baseline, and retain the legacy store read-only as the historical record. State clearly, in writing, that history before the cutover date lives in the archive and history after it lives in the vault. That is honest, and it is far easier to explain to an auditor than a synthesised version tree.

07 Cutover

A single date, communicated well in advance, after which the legacy store is read-only. Dual running is the most common implementation error and it does not work.

The reasoning is simple: if both systems remain writable, some work will happen in each. Nobody can then say which location holds the current version of anything, which is precisely the condition the vault was introduced to eliminate. The transitional period intended to reduce risk instead creates the exact risk being addressed.

Cutover sequence

T−4wkAnnounce the dateWith what changes, what is expected of each person, and where to get help. Repeat it.
T−2wkComplete trainingEveryone who will use the vault has had hands-on time, not a presentation.
T−1wkFinal migration trancheMigrate active work last so the vault content is current at cutover.
T−1dFreeze the legacy storeAnnounce the freeze, migrate anything changed since the final tranche, then set read-only.
T+0Go live with support presentAdministrator and champions available in person for the first days. Most questions are small and immediate.
T+1wkFirst reviewCollect what is not working. Distinguish genuine workflow problems from unfamiliarity, and fix the former.
T+1mthAdjust on evidenceRefine permissions, conditions and notifications based on a month of real use rather than on the original design assumptions.

Keep the freeze short

A long freeze is disruptive and generates pressure to work around it, which produces exactly the shadow copies the migration is meant to eliminate. Plan a freeze measured in hours or a weekend, not days, by migrating the bulk of data well in advance and only the active delta at the end.

08 Training & Adoption

The technical change is small — check out, check in, transition state. The behavioural change is not. Engineers accustomed to a shared drive are being asked to accept constraints in exchange for benefits that are mostly invisible to them individually and accrue to the organisation.

Adoption 01

Explain the why

Not the mechanics of check-out, but the problem it solves — two people editing the same file, the wrong revision manufactured, work lost.

Effect: constraints understood as protective rather than bureaucratic.

Adoption 02

Train hands-on

On their own data, in the configured vault, doing the tasks they actually do. A demonstration is not training.

Effect: people arrive at cutover having already done it once.

Adoption 03

Identify champions

One or two respected engineers involved from the pilot who can answer questions locally.

Effect: most questions never reach the administrator, and scepticism is answered by peers.

Watch for workarounds in the first month

Files being copied out of the vault to work on, long-running check-outs, or a folder on a shared drive quietly reappearing are all signals that something in the workflow is genuinely obstructive.

Treat these as design feedback rather than as compliance failures. An engineer working around the vault has usually found a real problem, and finding it in the first month while the configuration is still fluid is considerably better than finding it in a year.

09 Implementation Checklist

Process agreed before configuration. States, authorities, revision scheme and property schema signed off by the process owner.
Scope decided deliberately. What migrates and what stays in a read-only archive, with reasoning recorded.
Audit completed before planning. Duplicate filenames, broken references and orphans quantified before a timeline was committed.
Cleansing done pre-migration. Duplicates renamed, references repaired, cross-project in-context references resolved.
Libraries migrated first. Shared content in place before anything that references it.
Migration in verified tranches. Reference integrity checked after each batch, with a backup taken between them.
Initial states set correctly. Previously released data arrives released, not in work.
Revision baseline decided. Carried forward where trustworthy, reset to a defined baseline where not.
History position documented. Written statement that pre-cutover history lives in the read-only archive.
Legacy store read-only, not deleted. Retained, backed up, and searchable.
Single cutover date. No dual-running period.
Freeze kept short. Bulk migrated in advance; only the active delta at cutover.
Hands-on training completed. Everyone has performed their own tasks in the configured vault before go-live.
Champions identified. Respected engineers from the pilot available to answer local questions.
Stabilisation resourced. Weeks of support and configuration adjustment budgeted after go-live.

10 Frequently Asked Questions

How long does a vault implementation take?

The variable is data preparation, not installation. Servers and configuration are days to weeks. Cleansing a mature file estate is weeks to months depending on how much duplicate and broken data exists, which is why the audit should precede the timeline commitment.

For a small team with reasonably disciplined data, a few months from start to stable operation is realistic. For a larger organisation with a decade of accumulated shared-drive data, plan considerably longer and expect data preparation to be the critical path throughout.

Can we run the shared drive alongside the vault for a while?

Not writable. If both remain writable, work will happen in both and nobody will be able to say which location holds the current version — which is the exact condition the vault exists to eliminate. The transitional period intended to reduce risk creates the risk instead.

What does work is a read-only legacy store retained indefinitely as an archive. Engineers can find and reference historical data; they cannot modify it or add to it. That gives the safety net people are actually asking for without the ambiguity.

Should we migrate historical revisions?

Generally no. It multiplies volume and complexity, and the imported history has no real workflow record behind it — the version tree implies an approval trail that never existed in the system, which is arguably worse than having no history at all.

Migrate the current revision as the vault baseline and retain the legacy store read-only as the historical record. Document the position plainly: history before the cutover date is in the archive, history after it is in the vault. That is straightforward to explain and defensible in an audit.

Engineers are resisting. What actually helps?

Distinguish two things that look identical. Resistance to unfamiliarity fades with use and is addressed by hands-on training and visible support. Resistance to genuine obstruction does not fade, and is addressed by changing the workflow.

The diagnostic is whether people can articulate a specific problem. "It is slower" is usually unfamiliarity. "I cannot get a drawing released without chasing someone who is on leave" is a design fault in the transition authority, and it is correct to fix it. Treat the first month's complaints as design feedback, fix what is real, and explain what is not — dismissing everything as resistance is how a vault ends up being worked around permanently.

Series context. This page is part of the KEVOS® SOLIDWORKS environment administration series. It presents general administration practice and is written to be release-independent wherever possible. Where specific versions, limits or supported platforms are cited, they reflect the SOLIDWORKS 2026 release family and should be verified against current vendor documentation before being relied upon for procurement, platform or upgrade decisions.

SOLIDWORKS is a registered trademark of Dassault Systèmes SolidWorks Corporation. Product names are used here for identification and reference only. KEVOS® is independent and is not affiliated with, endorsed by, or a reseller for Dassault Systèmes.