Most engineering teams hit the same wall at 3-5 people: the shared drive workflow stops working. Parts go missing, assemblies open with suppressed components, two people overwrite the same file on the same day, and nobody can tell what changed between Tuesday and Thursday.
The standard advice — “use cloud sync” or “put it on Git” — misses the specific ways SolidWorks assemblies break under each of these systems. This post covers the actual failure modes of OneDrive, Google Drive, and Git-LFS for SolidWorks teams, and the specific differences in SolidWorks PDM Standard vs. Professional that matter for distributed workflows.
If you want the complementary perspective on setting up Git+LFS or PDM from scratch, see CAD file version control best practices for engineering teams. This post focuses on the sync question specifically: what happens when files are being shared and edited across machines.
Why OneDrive and Google Drive Break SolidWorks Assembly References
The short answer: SolidWorks encodes absolute file paths inside .sldasm files. Every subassembly and part that an assembly references is stored as a full path string (e.g., C:\Users\james\Projects\Machine\Bracket.SLDPRT). Cloud sync services don’t know about these embedded references — they treat SolidWorks files as opaque blobs, exactly like Word documents or PDFs.
This creates five specific failure modes.
1. Username-embedded paths break cross-machine references
OneDrive stores files under C:\Users\%UserName%\OneDrive\.... On engineer James’s machine, that path starts with C:\Users\james\.... On engineer Sarah’s machine, the same file lives at C:\Users\sarah\OneDrive\....
When James opens an assembly and saves it, the embedded references point to C:\Users\james\.... When Sarah opens that same assembly, SolidWorks looks for parts at C:\Users\james\... — a path that doesn’t exist on Sarah’s machine. Components become suppressed without warning. SolidWorks may show “The file could not be found” or silently gray out components in the feature tree.
This is not a configuration issue. It’s structural: OneDrive’s path layout ensures every user has a different absolute path, and SolidWorks embeds absolute paths.
Workaround that doesn’t require PDM: Map the OneDrive folder to a fixed drive letter (e.g., Z:\) on every machine, with the same base path for all users. This works only if all team members have identical folder structures under that drive letter — fragile, but functional for very small teams.
2. File locks during sync corrupt saves
OneDrive and Google Drive sync agents acquire OS-level file locks when uploading files. If SolidWorks is in the middle of a save when the sync agent holds a lock on the same file, the write either fails silently or produces a corrupted file.
This is particularly dangerous because SolidWorks autosaves frequently and writes backup files during crash recovery. In a high-activity session, the sync agent and SolidWorks are racing to read and write the same files. Engineers have documented “SOLIDWORKS encountered a serious problem in the file” errors that trace back to sync-during-save conflicts.
3. Conflict copies rename files and break references
When two users edit the same part simultaneously, OneDrive creates a conflict copy and appends -<ComputerName> to the filename — e.g., Bracket.SLDPRT becomes Bracket-DESKTOP-H3K.SLDPRT. OneDrive keeps both files. SolidWorks, unaware of the rename, still points to Bracket.SLDPRT. The conflict copy is now an orphan, and the assembly’s reference to the original file has lost the edits made by the second user.
This happens silently. The engineer whose copy won doesn’t know their colleague’s work was discarded.
4. Google Drive File Stream breaks on drive letter remapping
Google Drive File Stream maps to a virtual drive letter (e.g., G:\My Drive\...) rather than a physical local path. If the Drive app restarts or updates, it may remap to a different drive letter. Since SolidWorks embedded the original drive letter in the assembly file, the references break the moment the mapping changes. This has been documented specifically for SolidWorks assemblies in Google’s Drive support forums.
5. No CAD-awareness for renames and moves
When you rename a part in SolidWorks PDM, PDM updates every assembly that references that part. OneDrive and Google Drive have no concept of SolidWorks reference relationships — if you rename Bracket.SLDPRT to Support_Bracket.SLDPRT, every assembly that referenced the old filename now has a broken reference. The cloud service successfully renames the file; SolidWorks sees a missing part.
Both GoEngineer and CadAdmin (major SolidWorks resellers) explicitly classify storing SolidWorks files on non-CAD-aware cloud storage as a “bad practice” — not just “not recommended” but a known source of production data loss.
Git-LFS with SolidWorks Binary Files
Git-LFS (Large File Storage) solves Git’s fundamental problem with binary files: it stores large blobs on an external server rather than in the Git object database, and replaces them with 1KB pointer files in the repository. For SolidWorks teams, it addresses the storage problem. It does not address the reference problem.
What actually works
Git-LFS correctly tracks .sldprt, .sldasm, and .slddrw files as large binary pointers. History is preserved. Old versions are retrievable. The repository stays small because only the file versions you have checked out are physically present on disk.
If your primary need is version history and rollback capability for a solo engineer or a team that never works on the same files simultaneously, Git-LFS is a reasonable solution.
What breaks in team usage
No merge capability. Git cannot perform a 3-way merge on SolidWorks binary files. When two branches modify the same part, Git sees conflicting pointer files (not conflicting geometry). The “merge” produces a corrupted pointer. Resolution requires picking one version and discarding the other’s changes — no integration of both sets of edits is possible.
File locking must be configured manually. Git-LFS includes git lfs lock and git lfs unlock commands that implement pessimistic locking — only one user can hold the lock on a file. But locking must be explicitly enabled in .gitattributes with the lockable attribute, and the server must support lock enforcement (GitHub, GitLab, and Azure DevOps all do). Many teams skip this step, run without enforced locking, and discover the limitation the first time two engineers edit the same part.
No assembly reference awareness. Renaming Bracket.SLDPRT to Support_Bracket.SLDPRT in Git renames the file on disk. Git has no mechanism to update the embedded path inside Assembly.sldasm. References break identically to the OneDrive rename scenario.
Cold checkout is slow. When you clone a repository or switch branches, Git-LFS downloads each binary file individually — no pack-file batching. A 500-part assembly requires 500+ sequential HTTP requests to the LFS server. On enterprise WAN, this is measured in minutes to hours for large product structures. For teams with remote offices, this is the same bandwidth problem PDM Professional’s replication feature is designed to solve.
Storage costs accumulate. SolidWorks binary files do not delta-compress. Each new version of a 50MB assembly is a full 50MB upload. GitHub’s free tier includes 10GB of LFS storage; beyond that, costs are $0.07/GB/month for storage plus bandwidth charges. A mature product with full revision history reaches 10GB quickly.
Git-LFS is appropriate for small teams (1-3 engineers), where files are worked on sequentially rather than simultaneously, and where cross-machine references aren’t an issue (shared network path with consistent drive letter, or single-user workflow). For larger teams working on shared assemblies, the merge/rename/reference limitations make PDM a necessary investment. See also the CAD version control team size guide for a decision matrix by headcount.
SolidWorks PDM: Standard vs. Professional Sync Differences
PDM (Product Data Management) is the only option in this comparison that understands SolidWorks assembly reference structure. When you check out an assembly, PDM can automatically fetch all referenced subassemblies and parts. When you rename a part, PDM updates references in every dependent assembly. The central archive server is the authoritative file store; engineers work from a local vault cache and check files in and out.
The choice between PDM Standard and Professional matters primarily for distributed teams and large vaults.
Multi-site replication (Professional only)
PDM Professional’s most important sync feature for distributed teams is archive server replication. The master archive server replicates file binaries to local archive servers at remote offices on a schedule or on demand. Engineers at a remote office do a “Get” against their local server, not over WAN. For large assemblies, this is the difference between a 2-second local fetch and a 10-minute WAN transfer.
PDM Standard has no replication. All users, including remote offices, hit the single central archive server. For teams spread across geographies, this makes PDM Standard effectively unusable without a VPN with acceptable throughput.
SQL Express database cap (Standard)
PDM Standard uses SQL Server Express, which caps the metadata database at 10GB and 1GB of RAM usage. The 10GB limit covers metadata (part attributes, BOM relationships, workflow states, user permissions, and revision history) — not the binary file archive, which is stored separately as flat files.
For small teams with focused product families, 10GB is sufficient for years. For teams with large configurator-driven product families or long revision histories, the metadata database can reach this limit. When it does, SQL Express throttles queries and PDM performance degrades visibly: vault tree loading slows, BOM queries time out, and check-in/check-out becomes sluggish. PDM Professional uses SQL Server Standard with no database size cap.
Workflow limits (Standard)
PDM Standard supports one workflow with a maximum of 10 states. Every file in the vault, regardless of type, follows the same approval path. Teams that need separate workflows for drawings vs. models vs. purchased parts — or separate approval paths for different product lines — cannot implement this in Standard.
PDM Professional has no limit on workflows or states.
PDM 2026 vault view sync (both editions)
PDM 2026 introduced two notable sync improvements that apply to both Standard and Professional:
Pre-check-in backup. Files are automatically backed up to the archive server while a user is actively editing them — before the formal check-in. If an engineer’s machine fails or is lost while they have a file checked out, administrators can recover the last saved version without waiting for a check-in. This is a genuine improvement over the previous model where in-progress work was at risk between check-ins.
Transfer Ownership. Administrators can reassign a checked-out file from one user’s machine to another. This matters for distributed teams: if an engineer leaves a file checked out and becomes unavailable (illness, departure, time zone gap), another team member can take ownership and continue the work without waiting for IT intervention.
Autodesk Vault vs. SolidWorks PDM for mixed environments
Autodesk Vault uses the same pessimistic locking model as PDM: check-out acquires an exclusive lock, check-in releases it. Both support multi-site archive replication at the Professional/Workgroup tier.
The key difference for SolidWorks teams: Vault integrates natively with Inventor, AutoCAD, Civil 3D, and Revit. For SolidWorks files, Vault treats .sldprt and .sldasm as opaque blobs unless a third-party connector (e.g., coolOrange powerVault) is added. Without the connector, Vault doesn’t track SolidWorks assembly references — renaming a part in Vault doesn’t update its references in dependent assemblies, same as the OneDrive problem.
If your team works exclusively in SolidWorks, PDM is the right choice. If you have a mixed Inventor/SolidWorks environment with Inventor as the primary tool, Vault may be the better fit with a third-party SolidWorks connector added.
Choosing the Right Sync Model
| Team size | Sync approach | Key constraint to watch |
|---|---|---|
| 1-2 engineers | OneDrive with fixed drive letter mapping | Avoid renames; document the path convention |
| 1-3 engineers (sequential work) | Git-LFS with enforced locking | Enable lockable in .gitattributes; avoid parallel edits on same files |
| 3-8 engineers, single office | PDM Standard | 10GB metadata cap; single workflow limit |
| 8+ engineers, or multiple offices | PDM Professional | Cost justified by replication; no metadata cap |
| Mixed Inventor/SolidWorks shop | Autodesk Vault + third-party SW connector | Connector licensing cost; reference tracking depends on connector quality |
The transition point from Git-LFS to PDM is typically when two engineers need to edit different parts of the same assembly at the same time — a daily occurrence on any active design team. Git-LFS’s lack of assembly reference awareness and merge capability makes it inadequate beyond small solo or sequential workflows.
For teams already using PDM who want to improve batch export throughput — exporting DXF flat patterns or drawings from the vault for fabrication — SolidWorks PDM batch plot documents the Task Scheduler integration built into PDM for automating drawing exports. For large assembly performance specifically, managing large CAD assemblies covers the thresholds where each platform starts to degrade.