From Shared Folders to Cloud PDM: A Practical Migration Checklist

A practical checklist for moving CAD files from shared folders or a file server into cloud PDM, with steps for inventory, pilot testing, validation, and cutover.

Christina Rebel

Sep 28, 2026

Cloud PDM

A move from shared folders to cloud PDM is not just a file-copy exercise. This checklist helps engineering teams inventory CAD data, protect assembly references and revision context, test a representative project, and cut over without leaving two competing sources of truth.

Moving from shared folders or a file server into cloud PDM is different from changing CAD platforms. This guide assumes your team is keeping its CAD authoring tools and changing where engineering data is managed. For a switch from one CAD platform to another, see CAD Migration Without Data Chaos: Why Engineering Teams Need a Neutral PDM Layer.

Before moving files, agree on what is in scope, keep a restorable copy of the source, and test the process on one representative project. Microsoft’s file-share guidance follows a similar assess–prepare–pilot–migrate sequence, though its implementation details are specific to Microsoft 365. Treat the pilot as a way to uncover what the transfer will—and won’t—preserve: CAD references, permissions, revision history, approvals, and supplier access may all need separate checks.

Illustration showing that shared folders stop scaling for growing CAD teams, highlighting the need for a structured migration to cloud PDM. — **Shared folders often work early on, but they become harder to control as CAD data, references, and collaborators grow.**

The migration checklist at a glance

Stage	Main outcome	Do not proceed until…
1. Define scope	A documented boundary and success criteria	The team agrees which data, users, and workflows are in scope
2. Inventory and classify	A reliable map of files, projects, references, owners, and status	Active, released, obsolete, duplicate, and unknown data are distinguishable
3. Prepare the source and destination	A protected source snapshot and a mapped target structure	Backup and restore are tested, and metadata/history limits are understood
4. Run a pilot	Evidence that a representative project works in the new environment	CAD references, permissions, versioning, and release checks pass
5. Migrate in controlled batches	Reconciled project data with exceptions recorded	Each batch has been checked against its source manifest
6. Cut over and stabilize	One authoritative working location and a controlled archive	Users know where to work, how to report issues, and when the old source becomes read-only

1. Define the scope and the rules before moving files

Start by deciding what “migration complete” means for your team. A target system can contain every file and still fail operationally if engineers cannot identify the current revision, open the right assembly, or tell a supplier which package is approved.

Document these decisions before the first transfer:

Data scope: Which active projects, released packages, libraries, templates, and historical projects will move? Will old or obsolete material be migrated, archived read-only, or excluded with an owner’s approval?
Team scope: Which engineers, reviewers, managers, suppliers, and other external participants need access, and what should each group be able to do?
Source of truth: Which location controls active work during each migration stage? Name one owner who can resolve conflicts.
Record continuity: Which identifiers, revision labels, approval records, comments, and file dates must remain available? Separate information that can be transferred from information that must be documented or retained separately.
Success criteria: Define measurable checks, such as required files present, critical assemblies opening with their expected references, permissions matching the approved matrix, and the release workflow completing as intended.
Cutover and rollback: Set the freeze window, the final change-sync method, the decision-maker for cutover, and the conditions that would pause or reverse it.

Do not treat a folder tree as a complete process definition. The existing structure may reflect years of local habits rather than a deliberate project, revision, or release model. Preserve useful context, but decide explicitly what the new system should make easier to find and control.

2. Inventory and classify the engineering data

Start the inventory with the details you’ll need to reconcile the move: source path, filename, file type, size, last-modified date, project, owner, and current status. Add revision, approval, access, and related-record details when the source system provides them.

Classify files into practical groups:

Active native CAD files, assemblies, drawings, and their referenced components
Released manufacturing or supplier packages
Neutral exports such as STEP or PDF, when they are part of the controlled record
Libraries, templates, standard parts, and other shared resources
Historical, obsolete, superseded, or unowned files
Non-CAD project documents that should remain alongside engineering work
Temporary, cache, backup, or duplicate candidates that need an owner’s review

Treat apparent duplicates as candidates, not automatic deletions. Two files with the same name may contain different designs; identical file contents may still serve different projects or have different approval context. If you use file hashes to find byte-identical copies, retain the source paths and have an owner decide which record remains authoritative.

Build a reference map for representative assemblies. Include the top-level assembly, subassemblies, parts, drawings, external references, and any linked files the CAD application needs. Note broken links and unresolved ownership while the source is still available. A successful copy of an assembly file is not proof that the complete design has moved.

Also map access deliberately. Record which folders are restricted, which suppliers have access, and whether that access should continue after migration. Avoid reproducing every historical permission exception without review; access in the destination should follow an approved role or project rule.

3. Prepare the source and the destination

Protect the source before cleanup

Take a complete backup or snapshot of the source and test that a sample can be restored. Keep an inventory or manifest with the original paths and relevant file details. If the migration will take more than one session, decide how new or changed files will be captured between the initial copy and final cutover.

Do not reorganize or delete source files as part of the same step as the first transfer. Keeping the source intact gives the team a comparison point and a recovery path while the destination is being checked.

Map folders and metadata intentionally

Design the target structure around how engineers find and control work, not simply around reproducing every nested folder. Define the project or workspace boundaries, naming conventions, owners, and any required properties before the pilot. Common fields to consider include part or document number, revision, lifecycle status, project, owner, and release date, but only require fields the team will maintain.

Agree on the meaning of version and revision. A saved iteration, a formal engineering revision, and an approved release are related but not interchangeable. Decide which existing values will be mapped, which will be preserved as descriptive metadata, and which historical values cannot be represented directly in the new workflow.

Decide what history can actually move

Before promising continuity, ask the source and destination owners which information can be migrated: prior file versions, revision labels, approval records, comments, audit events, timestamps, and file relationships. Verify each item separately. If an item cannot be transferred, agree whether it will be captured in a migration log, retained in a read-only archive, or handled another way under your retention policy.

Do not label a newly uploaded current file as though its earlier engineering history has also been imported. Keep the original history available until the team has verified what the new system records and what must remain in the archive.

4. Pilot one representative project

Pick a pilot project that reflects how your team actually works. If engineers rely on assemblies, drawings, supplier packages, or more than one CAD tool, include those in the test; moving a single part file won’t reveal whether the real workflow holds up.

Include, where relevant:

A top-level assembly with several referenced parts and at least one drawing
A mix of active and released files
A project library item or external reference
A user with each important role, plus an external reviewer if supplier collaboration is in scope
One representative edit, review, and release scenario

Run the pilot from a controlled copy of the source. Record the file set and expected relationships before upload, then test the workflow with the intended users. Confirm that:

The expected files are present and can be found in the agreed project structure.
The native CAD application can open the assembly and resolve the expected references. A browser preview alone is not a substitute for testing the working CAD file.
The team can distinguish current work from a released or superseded version.
The intended users can perform their permitted actions, and restricted users cannot access files outside their scope.
A user can complete the agreed editing and handoff process, including check-in/check-out if those controls are part of the selected workflow.
A reviewer or supplier can access only the files and actions approved for that role.
Exceptions, missing history, unsupported formats, or manual steps are recorded with an owner and a resolution decision.

Write down the pass criteria before testing. For example: “The top-level assembly opens with all listed references from the destination; the released drawing is identifiable; the supplier account sees only the approved package; and the source remains recoverable.” If a test fails, fix the mapping or workflow and repeat the pilot before scaling up. A pilot is also the right time to confirm any format-specific limitations before setting a migration date.

For CAD ROOMS, check the current supported file-format list against the exact files in your pilot, then validate the intended workflow with the check-in and check-out guide. Format support, viewing, native editing, and the handling of a specific assembly are separate questions, so test the files and tasks your team actually uses.

5. Migrate in batches and reconcile each one

After the pilot passes, migrate by project or another boundary that keeps ownership clear. Avoid uncontrolled parallel edits in both locations. If users must keep working during the transfer, specify which location is authoritative and how changes will be captured and reconciled.

For every batch:

Record the source scope and the transfer date.
Keep a manifest of expected files and paths.
Transfer the agreed files without silently renaming or overwriting conflicts.
Compare the destination against the manifest, including file counts and relevant file details. Where the source and destination allow file-level verification, use checksums to confirm byte-level copies.
Re-test critical assembly references and released packages, not only a random sample of standalone files.
Review permission assignments and confirm the project owner has accepted the result.
Log exceptions such as missing references, duplicate candidates, unreadable files, or metadata that needs manual entry.

Resolve exceptions visibly. Do not let an incomplete project appear complete simply because its top-level folder has been copied. A batch should have a clear status such as ready, blocked, or accepted, with a named person responsible for unresolved items.

6. Plan cutover as a controlled change

Before the final cutover, tell users when the source will become read-only, where they should work afterward, and whom to contact if a file or reference is missing. Schedule a freeze or a defined final-sync window so changes are not split between two live locations.

At cutover:

Freeze edits in the source or apply the agreed change-control rule.
Transfer and reconcile the final changes since the earlier batch.
Recheck the highest-risk assemblies, released packages, access rules, and required records.
Confirm project owners accept the destination and the team knows the new workflow.
Make the old source read-only or otherwise clearly mark it as non-authoritative, subject to company retention and access requirements.
Keep a migration log with the cutover date, accepted scope, exceptions, and archive location.

Do not delete the source just because the first week goes well. Set a review period and obtain the appropriate engineering, IT, and records-management approvals before retirement. The duration and retention rules depend on your organization’s obligations and policies.

Common migration mistakes to avoid

Copying first and defining the workflow later. Decide ownership, revision, release, and permissions before users begin working in the destination.
Assuming a successful upload proves assembly integrity. Test the complete reference set in the native CAD workflow.
Treating file history as engineering revision history. Define exactly what each status and revision means, and preserve records that do not transfer.
Cleaning up during the transfer. Preserve a recoverable source and handle duplicate or obsolete files as reviewed exceptions.
Recreating the old folder tree without considering retrieval. Keep useful organization, but make project boundaries and the source of truth clear.
Leaving both systems writable indefinitely. Dual live locations create ambiguity about which revision is current.
Declaring success without user acceptance. Project owners and the people who edit, review, and release files should test the real workflow.

Where cloud PDM fits

A cloud PDM is worth evaluating when shared folders make it difficult to coordinate changes, identify the approved revision, control external access, or keep connected engineering data understandable. The case is stronger when the team needs one managed workflow across several CAD environments, but the exact format and reference behavior still needs to be checked against the team’s files.

CAD ROOMS provides version control, multi-CAD data management, and engineering collaboration workflows. Evaluate the platform separately from the migration itself: test your actual files and workflows, then confirm what source history and metadata can be retained before you set a cutover date.

The PDM workflow guide explains how controlled editing, review, and release fit together. If external handoffs are part of the move, also review secure supplier collaboration. The right next step is to test one real project and document the pass criteria, not to promise a frictionless transfer. Book a demo to discuss the workflow against your team’s files.

Frequently asked questions

Q: Do we need to migrate every file from the shared drive?

A: No. Decide which projects are active, which released records must remain available, and which obsolete or duplicate candidates need review. Keep an approved inventory and retain excluded or archived data according to your organization’s policy. Avoid deleting source files until ownership and retention decisions are documented.

Q: Will moving files preserve CAD assembly references?

A: Do not assume so. References can depend on file paths, names, and the way a project was assembled. First confirm that your exact formats appear in the Multi-CAD Compatibility guide, then pilot a representative assembly and open it from the destination in the native CAD application. You can also use CAD ROOMS’ file-relationship view to inspect connections between assemblies and parts, but native CAD validation is still required before migrating similar projects at scale.

Q: Will cloud PDM import all previous versions and approvals?

A: That depends on the source, the destination, and the migration method. Verify prior versions, revision labels, approvals, comments, and audit records individually. If a history item cannot be transferred, preserve it in an approved archive or migration record rather than presenting the current upload as the complete history. After cutover, CAD ROOMS can record new project changes in Version History and track formal file updates through Revision History; these new records do not replace source history that was not imported.

Q: Should we keep the old shared folder after cutover?

A: Usually, keep it available in a clearly non-authoritative, read-only state until the destination is accepted and the organization’s retention requirements are satisfied. Set an owner and review date so the archive does not become a second working location.

Sources

About the author

💡

Christina Rebel

CEO of CAD ROOMS | Co-founder of Wikifactory

I’m Christina Rebel, CEO of CAD ROOMS. For over a decade, I’ve worked at the intersection of cloud engineering collaboration, digital manufacturing, and distributed product development.

Throughout my career, I’ve worked closely with engineers, designers, and manufacturing teams to improve CAD data management, version control, supplier collaboration, and browser-based design review. My focus is on making modern engineering workflows more accessible, secure, and efficient, particularly for SMEs and startups.

I also write about engineering collaboration, with contributed articles published by Design News and DEVELOP3D.

Follow the author: LinkedIn

Illustration showing that shared folders stop scaling for growing CAD teams, highlighting the need for a structured migration to cloud PDM.

PDM–ERP Integration: How Engineering Data Flows to Procurement PDM vs SharePoint for CAD Files: When Is SharePoint Enough?