Moving CAD data to cloud is not the same as moving documents to cloud. A SolidWorks assembly references its component parts by absolute path. A drawing references a model. A PDM revision history records who checked what out on which date. Generic cloud storage (SharePoint, OneDrive, Dropbox) treats every file as an independent entity and breaks all of this silently — the files land in the bucket, the directory looks right, and then the first engineer to open a top-level assembly watches it rebuild with hundreds of “file not found” dialogs.

This guide covers what actually happens during a CAD cloud migration, platform by platform, and what to do about the reference problem before it turns a three-month migration into a six-month rollback.

What “Cloud” Means for CAD Teams — Three Different Models

Before planning a migration, identify which model you’re actually moving to, because the migration path differs substantially:

Cloud-native CAD (Onshape, Fusion 360, SolidWorks xDesign): The CAD data lives natively in the vendor’s cloud database. There are no files — models are documents stored server-side. References are managed by the platform. Migration means converting your existing SOLIDWORKS/Inventor/DWG files into the platform’s native format, accepting the geometry-import limitations (loss of parametric history, configurations, and design intent for assemblies).

Cloud-hosted desktop CAD (Autodesk Vault cloud on AWS/Azure, PDM Professional with SolidWorks Connected): The CAD application still runs on a desktop or virtual machine, but the vault or PDM server runs in a cloud VM rather than on-premises hardware. Native files are still used. Migration means moving the server infrastructure and preserving file references through the transition.

Cloud storage for CAD files (SharePoint, OneDrive, Google Drive with CAD sync tools): The least disruptive option and the highest-risk for reference integrity. See below for why.

Most engineering teams migrating for the first time think they want the third option and discover they actually need the second. The cloud CAD vs. desktop CAD comparison covers the capability tradeoffs; this guide focuses on the execution of the migration itself.

Step 1: Map Your File Dependencies Before Touching Anything

The migration can’t proceed safely until you know what references what. Run a dependency audit on the current vault or file server:

For SOLIDWORKS PDM Standard/Professional: Export a BOM report from the PDM vault for every top-level assembly. PDM stores the full reference graph internally. Open a top-level assembly in PDM, right-click → References to see every component path. For a programmatic sweep, use the PDM API (IEdmVault5.GetFileFromPath) to walk every file and collect its external references.

For Inventor Vault: Run the Pack and Go utility on every top-level assembly to a test folder. Inventor Pack and Go resolves all references recursively, and any file it can’t find will show as unresolved before you start the migration.

For AutoCAD with Vault: Check the Vault client’s “Where Used” panel for every drawing that uses external references (Xrefs). Xref paths are stored as absolute or relative paths inside the DWG; the Vault client tracks them as references in the vault database.

Output a flat list of every file, its path, and its dependencies. This becomes your migration manifest. Any file that doesn’t appear in the manifest as either a root or a dependency is an orphan — confirm it’s truly unused before leaving it behind.

Step 2: Decide on Folder Structure Before Migration Day

Whatever folder structure you use in the source system, the destination folder hierarchy must be decided before any files move. References in CAD files resolve at runtime by looking for a file at a specific path. If the folder structure changes during migration, every reference breaks.

The safest approach: preserve the relative folder structure exactly. The vault root moves to a new host, but the directory tree under it stays identical. This is how Autodesk’s recommended Vault-to-cloud migrations work — the vault database contains the reference graph, and the physical files are restored to an identical directory structure on the new server.

If you must reorganize (combining product-line vaults, consolidating legacy folders), do it as a separate project after the cloud migration is validated. Doing both at once doubles the failure modes.

Step 3: Platform-Specific Migration Paths

SolidWorks PDM → 3DEXPERIENCE Cloud

Dassault Systèmes provides the 3DEXPERIENCE Transition Assistant for migrating SolidWorks PDM data to the 3DEXPERIENCE platform. This is the supported path for teams moving from PDM Standard or Professional to SolidWorks Connected.

What the Transition Assistant handles:

  • CAD file revision history (versions, states, date/author metadata)
  • PDM workflow state mapping to 3DEXPERIENCE lifecycle stages
  • Custom attribute/property mapping
  • Assembly references (resolved in the new platform’s database)

What it does not handle automatically:

  • CAD geometry translation (SolidWorks files open natively in SolidWorks Connected — this isn’t a format conversion)
  • Custom PDM add-ins, Dispatch scripts, and task configurations (these require manual recreation in the 3DEXPERIENCE environment)
  • Non-CAD attachments (PDFs, Excel BOMs linked to PDM files need separate migration)

Typical migration timeline for a PDM Standard vault: three months from kickoff to validated production sign-off. For PDM Professional with custom workflows, budget six months.

Critical pre-check: Run SWTaskHost.exe /verify on the PDM client before migration to confirm the vault is internally consistent. A vault with orphaned references or corrupted version history will fail partway through the Transition Assistant import — discovering this during migration is worse than discovering it beforehand.

Autodesk Vault → Cloud (AWS/Azure/GCP)

Autodesk’s recommended path for Vault cloud deployment is to run the Vault Server on a cloud VM (typically Windows Server 2019 on AWS EC2 or Azure Virtual Machines) with the file store on a high-IOPS block storage volume (AWS EBS gp3 or Azure Premium SSD).

The migration steps:

  1. Backup the source Vault: Vault Administrator → Utilities → Backup. This produces a .zip containing the SQL Server database and the file store.
  2. Restore to the cloud VM: Install MSSQL and Vault Server on the target VM, then restore the backup. The SQL restore preserves the entire reference graph and revision history.
  3. Remap the file store path: Vault stores the physical file location in the SQL database. After restore, update the file store path via Vault Administrator → File Store to point to the new location.
  4. Update client configuration: Distribute the new server hostname/IP to all clients. Vault clients connect by server address, not path, so the CAD file references themselves don’t change.

Latency constraint: Autodesk recommends less than 1ms effective latency between the Vault server and the CAD workstations for reliable check-in/check-out. This means a VM in the same region as the engineers, not a shared multi-region deployment. For distributed teams in different geographies, Vault Gateway provides a replication layer to reduce write latency.

For Inventor specifically: Inventor resolves references through the Vault client library. As long as the Vault client is configured and the user is logged in, Inventor finds referenced files via the Vault database rather than by filesystem path — which is why Vault cloud migration doesn’t break Inventor references even when the physical file store moves.

AutoCAD with AutoCAD Web / Autodesk Docs

For 2D AutoCAD teams moving drawings to Autodesk Docs (the cloud document store in the Autodesk Construction Cloud), the process is simpler but the Xref problem is real.

Internal Xrefs (Xrefs that point to files in the same folder tree): Upload the entire folder hierarchy to Autodesk Docs maintaining the same structure. AutoCAD Web resolves Xrefs relative to the host drawing’s location, so structure preservation is enough.

Absolute-path Xrefs (Xrefs with drive-letter paths like C:\Projects\Site\Sheet-1.dwg): These break regardless of what cloud platform you use, because the absolute path doesn’t exist on the cloud server. Before migrating, convert all absolute Xrefs to relative paths using the XREF manager → change path type to Relative. Alternatively, use ETRANSMIT to package all drawings with their dependencies — this rebuilds the Xref paths as relative to the transmittal folder.

Step 4: The Generic Cloud Storage Problem

SharePoint, OneDrive, and Dropbox can serve as CAD file stores only under narrow conditions. The problem is not the files themselves — SolidWorks, Inventor, and AutoCAD files are just files and sync correctly. The problem is what happens when an engineer opens a file while it’s being synced.

SOLIDWORKS locks the .sldprt file during editing via a Windows file lock. OneDrive uses a different mechanism for sync conflict detection, and when those two locking mechanisms interact on the same file, you get sync failures that silently produce corrupt files or incomplete uploads. The symptoms show up later when another engineer opens what looks like a valid file and gets corrupted geometry.

For teams committed to SharePoint/OneDrive, the only safe configuration is: engineers work on a local copy, with sync to SharePoint as a backup, not as the live working location. The CAD file sync guide covers the five failure modes in OneDrive sync for SolidWorks, and when PDM is worth the additional cost.

The cloud CAD limitations post addresses the latency and assembly performance constraints that are separate from the migration — relevant reading for teams evaluating whether cloud makes sense at all before committing to the migration.

Step 5: Migration Execution

With the dependency manifest and folder structure confirmed, the actual migration follows this sequence:

  1. Freeze the source system. Set the vault or PDM to read-only mode (check-in permitted, no check-out) for the migration window. Engineers work on locally-checked-out copies during the window.
  2. Migrate in dependency order. Leaf files (parts with no outgoing references) first, then assemblies that reference only parts, then top-level assemblies. This ensures that when the import tool tries to resolve references, the referenced files already exist in the destination.
  3. Validate spot-checks before declaring done. Open five representative assemblies in the target environment, resolve all references, check that revision history is intact, and run a rebuild. If any of these fail, stop and investigate before migrating the remainder.
  4. Run the full dependency check again in the target. Re-export the dependency graph from the destination vault and diff it against the source manifest. Any missing or remapped reference needs investigation.
  5. Cutover. Redirect all clients to the new server. Retire the source system (don’t delete immediately — keep the source vault accessible read-only for 30 days as a rollback target).

Common Failure Modes

Broken references after migration: Usually caused by a file that existed on disk but was not checked into the vault, so it doesn’t appear in the migration manifest. The assembly opens on the source system because the out-of-vault file is on the same machine. Post-migration, the file doesn’t exist on the new server. Fix: before migration, run a full “find external references” sweep to catch files on disk that aren’t in the vault.

Slow performance on the cloud vault: Most often a latency problem, not a bandwidth problem. A 1GB assembly with 500 parts needs to perform 500 reference lookups against the vault during open. At 5ms per lookup that’s 2.5 seconds of pure vault overhead before any geometry loads. Solution: ensure cloud VM is in the same region as engineers, and consider enabling Vault’s local file cache to avoid repeated lookups.

Configuration loss for SolidWorks models: If SolidWorks configurations are used to drive derived BOMs, verify that the PDM/vault correctly imports all configuration-specific custom properties, not just the active configuration. The Transition Assistant has a known edge case where configuration-specific properties are imported only for the configuration that was active at the time of last check-in.

PDM workflow states lost in translation: 3DEXPERIENCE lifecycle states (Draft, In Work, Released, Obsolete) don’t map one-to-one to PDM workflow states. Work through the state mapping table with the Transition Assistant configurator before the migration — states that don’t map will default to Draft, erasing the released status of parts that shouldn’t be editable.

Validation Checklist

Before declaring migration complete:

  • Open 10 top-level assemblies at random and confirm all references resolve
  • Check that revision history shows correct date/author for at least 5 spot-check files
  • Open a drawing that references a multi-configuration model and confirm the correct configuration is shown
  • Confirm that PDM workflow states (or vault Xref states) transferred correctly
  • Run a check-out, edit, and check-in cycle on a test file to validate write access
  • Verify that at least one engineer on each affected continent/region can access the vault with acceptable performance

A migration that passes the validation checklist in 30 minutes of spot-checking is not validated. Budget a week for validation, with engineers from each product line testing their own assemblies.