CAD Version Control for Engineering Teams — Which System to Use at Each Team Size

The same question comes up on every growing engineering team: “We’re using a shared network folder and emailing DWG files. What should we move to?”

The answer depends on how many engineers you have, whether you use SolidWorks, and whether your existing team already runs Git for software or firmware. This guide gives you a decision framework by team size, then walks through the actual tradeoffs of each approach.

For the technical setup details — Git LFS configuration, PDM Standard installation, file naming schema design — the CAD version control technical reference covers those in depth. This guide focuses on the selection decision.

The Core Constraint That Doesn’t Change

Before discussing systems: CAD files are binary. A SolidWorks .sldprt can’t be diffed, merged, or rebased. Two engineers working on the same file simultaneously will always produce a conflict where one person’s work wins and the other’s is lost.

Every version control system for CAD either enforces file locking or ignores this problem. If your system doesn’t enforce locking, one of your engineers will eventually lose a day’s work.

Team Size 1–5: Shared Folder + Rigid Naming Beats Almost Everything

For teams of one to five engineers, a properly structured network folder with a locked naming convention is often the right answer — not because it’s ideal, but because the overhead of any “real” VCS system is disproportionate to the risk.

What makes this work:

• One-per-file ownership: each part or assembly is assigned to one engineer at a time. “Checked out” is tracked in a shared spreadsheet or Teams channel message, not software.
• Revision in the filename: pump-housing_v03.sldprt, not just pump-housing.sldprt. Every release gets a new file; nothing overwrites.
• Folder by release state: /working/, /released/, /archive/. Files in /released/ are read-only enforced by OS permissions.

This breaks down when the team reaches ~5 engineers and multiple people regularly need to work on related assemblies simultaneously. At that point, the coordination overhead of a manual checkout spreadsheet exceeds the setup cost of a proper system.

CAD file management best practices covers how to structure these folders to avoid the most common failure modes — assembly references breaking when files are renamed or moved.

Team Size 5–15: Git + LFS vs SolidWorks PDM Standard

This is where the decision actually gets difficult.

Git + LFS works if:

• Your team already uses Git for software, firmware, or documentation
• You have access to GitHub, GitLab, or Azure DevOps with LFS enabled
• File sizes are manageable (< 2 GB total active CAD data)
• Your engineers are willing to learn basic Git CLI (or have a GUI like Fork or Sourcetree)

The critical limitation: Git does not enforce file locking by default. You can use git lfs lock to lock individual files, but this requires discipline. There’s no UI that prevents two engineers from opening the same file and diverging. LFS locking is opt-in, not enforced by the checkout workflow.

For SolidWorks specifically: when two assemblies reference the same sub-assembly, and that sub-assembly is modified, both assemblies go out of sync. Git will show you the file changed, but it won’t tell you which 14 other assemblies now need their references updated. SolidWorks PDM tracks these dependency graphs; Git does not.

SolidWorks PDM Standard works if:

• Your team uses SolidWorks as the primary CAD tool
• You want enforced check-in/check-out across the full team without relying on discipline
• You need assembly reference tracking (PDM rebuilds the reference graph when files are renamed or moved)
• Budget is available: PDM Standard is licensed per user (~$1,500–$2,000/seat for CAM, varies by VAR)

What PDM Standard includes that Git doesn’t:

• Enforced file locking via check-out
• Version history stored in the vault with diff comparisons (binary-aware, shows thumbnail previews)
• Assembly reference graph maintained automatically
• Workflow states (in-progress, under-review, released) enforced at the vault level
• Notifications when a checked-out file you depend on is modified

What PDM Standard lacks that PDM Professional has:

For teams of 5–15 engineers working from a single site, PDM Standard covers 80% of what you actually need. The cases where PDM Professional pays for itself quickly:

• You have a formal ECO (Engineering Change Order) process with approval chains
• Remote engineers access the vault from outside the office
• You want to batch export or batch plot directly from the vault
• Your ERP system needs to pull BOM data from CAD directly

The hybrid many teams land on

Teams that already use Git for non-CAD work often split: SolidWorks files go into PDM, documentation and firmware go into Git. The boundary is “anything SolidWorks touches.” This works well and avoids forcing engineers to learn Git LFS for large binary files when a purpose-built tool handles it better.

Team Size 15–50: PDM Professional or Onshape

At 15+ engineers, the limitations of PDM Standard become concrete:

• Simultaneous multi-site access is effectively broken (one shared server, no replication)
• Approval workflows involving multiple approval stages require manual workarounds
• ERP integration is manual (export BOM to Excel, import to ERP)
• The lack of web access means remote engineers need VPN + CAD workstation

Two realistic options:

SolidWorks PDM Professional: The upgrade path from Standard is well-defined — vault contents migrate directly, user permissions carry over, and add-ins continue working. If you’re already invested in SolidWorks infrastructure, this is the straightforward path.

Onshape: A cloud-native CAD platform that solves version control at the application layer rather than the file system layer. There are no files to version; Onshape’s branching model works like Git but for parametric geometry. The tradeoff is switching cost — migrating 3,000 SolidWorks parts to Onshape requires rework, not just file import.

If cost is the deciding factor: PDM Professional runs ~$3,000–$5,000/seat (check with your VAR). Onshape’s Enterprise plan is seat-based and typically cheaper at scale, but requires migrating your IP to a cloud-hosted platform, which some regulated industries prohibit.

The Transition Sequence

Teams rarely jump from shared folders directly to PDM Professional. The typical path:

1. Shared folder with naming conventions — works until ~5 engineers
2. Git + LFS or PDM Standard — works until ~15 engineers or until multi-site/ERP needs appear
3. PDM Professional or Onshape — for teams where approval workflows and ERP integration are the bottleneck

The costliest mistake is skipping step 2. Jumping from a chaotic shared folder directly to PDM Professional means learning a new system while also trying to establish basic version control discipline for the first time. Teams that do step 2 first arrive at step 3 already understanding what vault-based version control means.

What Version Control Doesn’t Solve

One clarification worth making: PDM manages file revisions but does not manage the downstream BOM coordination problem. When a released part is modified, PDM will record the new version and enforce check-in/check-out. But it won’t automatically update your ERP item, flag your procurement team, or trigger a drawing revision.

That handoff — from CAD version history to the manufacturing BOM — is a separate process. Why PDM doesn’t solve the downstream BOM problem covers that gap, and EBOM vs MBOM for SolidWorks teams explains where the split between engineering and manufacturing BOM management happens.

Summary Decision Matrix

The cheapest version control mistake is the one you undo six months later after outgrowing it. Pick the system that fits your team in one year, not today.