Autodesk Vault instead of Shared Folders: Implementation and Migration Plan

Why shared folders don't work for CAD files

Shared folders seem like a simple solution while the team is small and there are few changes. But in CAD work this quickly becomes a source of errors: several people open the same file, save at different times, and in the end no one is sure whether the file on disk is the current version or a stray copy.

The problem is deeper because CAD files are linked. A part, an assembly, a drawing, a bill of materials, and library elements are not independent files. In a shared folder it's easy to "lose" a link: someone renamed a file, moved a folder, saved a copy "just in case", and the assembly opens with errors or with substituted wrong parts.

Typical symptoms appear first:

• overwrites and duplicates (final, final2, final_new);
• unclear who and when changed the file: no transparent history;
• unclear where the "truth" is: several versions of the same drawing live in the project;
• the product composition "floats": it’s hard to quickly know what is in an assembly and which versions.

These are real risks. A typical scenario: an engineer updated holes in a part, but production planning or procurement picked an old specification from a neighboring folder and ordered the wrong components. Or a drawing that was only "almost ready" ended up in production next to the approved one. The result is rework, missed deadlines, quality questions and extra approvals at the worst moment.

Moving to Vault usually becomes necessary when workload grows: the team gets bigger, there are more projects, edits are continuous, and control requirements increase (audits, traceability, internal rules). If you often hear "I definitely have the latest version" or "I didn't touch that file, it changed itself", folders are no longer enough.

What changes when you switch to Autodesk Vault, in plain words

When CAD files live in a shared folder, everything looks straightforward: open, save, share. But a folder only stores files. It doesn't "know" that a part belongs to an assembly, that a drawing must match a specific model version, or that two people may edit the same file simultaneously.

Autodesk Vault works as a PDM: it becomes the single source of truth for files and their links. Vault stores not only documents, but also how they are related (model, assembly, drawing, BOM), who changed them and when, and which version is current.

The key shift is moving from "storage" to management. You get versions and change history (you can revert), statuses (e.g., "In Work", "Under Review", "Released"), control over concurrent work (files are "checked out" to avoid conflicts), attribute-based search instead of name-only search, and clear links so you can see which assemblies will be impacted by a part replacement.

Technically, Vault usually includes a client on designers' workstations, a Vault server, file storage (Vault Store), databases and mandatory backups. Agree on backups from the start: it's not "just in case" but part of normal operation.

A simple example: an engineer updated a part, but the drawing stayed old. In folders this is easy to miss. In Vault you immediately see that related documents have mismatched versions and need updating or review.

Be realistic about expectations. Vault quickly eliminates version chaos, lost links and the question "who saved last". But discipline doesn't appear by itself: statuses, naming rules, who approves changes and when something can be released to production all need to be agreed and configured for your department.

Minimum roles and permissions: without extra bureaucracy

People worry that Vault means creating hundreds of roles and approvals. At the start that's unnecessary. Better begin with a clear minimum and only add complexity once the team is stable.

For small and medium design offices, four roles are usually enough:

• Vault Administrator: server, users and groups, backups, folder permissions, basic settings.
• Lead Designer: manages statuses and releases, enforces rules, helps resolve disputes.
• Designer: creates and edits models and drawings, checks files out, checks in changes.
• Viewer: reads assemblies and drawings (manufacturing, procurement, production planning, manager) without risk of accidental overwrites.

Think of rights not as "what buttons someone can press" but as "what risk you allow". A basic working set is: read for everyone who needs to see current documents; check-out/check-in for designers and leads; edit/add/delete for designers within their work areas; status changes for leads (and sometimes a separate release role) so releases are controlled; admin access for one or two people only.

You can separate access by project without complexity: create groups like "Project A - Designers" and "Project A - Viewers" and assign permissions to the project folder. If someone works on two projects, they belong to both groups. At the start avoid splitting rights by each file type; otherwise maintenance becomes manual.

Assign an owner for the rules, or naming and property cards will drift. Usually the lead designer and the administrator share this: the lead defines meaning (how to name, which statuses and when), the admin implements (templates, attributes, required fields, checks). Example: a drawing without "Part Number" and "Project" doesn't move to "Under Review".

If you implement Vault with a systems integrator (for example, as part of supplying CAD workstations and servers), agree in advance who on your team accepts the rules and who supports them, so the system doesn't depend on one person.

Storage structure: how to design it before migration

If you currently have one "shared folder", the main question when moving to Vault is: by what principle will people more easily find and reuse data? A good structure doesn't have to be perfect. It must be clear on day one and still work in six months.

Choose one main principle (don't mix everything at once)

In practice four approaches work: by projects, by products, by lifecycle stage, or by customers. A common mistake is building a tree by all these criteria at once and then duplicating files "just in case".

By projects is convenient when work is organized in project folders and the team lives by project timelines. By products works if you develop product lines and constantly reuse subassemblies. By customers is logical when documentation requirements and composition depend heavily on the client. Stage-based separation is useful as part of rules (e.g., "In Work" and "Archive") but as the only principle it can cause confusion.

A compromise often suitable for design departments: top level by products (or product types), with projects as separate containers for specific orders where drawings, BOMs and source files for delivery are collected.

Naming rules: one format for everyone

Vault helps search and properties, but readable names still save time. Introduce a short standard and make it mandatory.

Example folder names: "01_Products", "02_Projects", "03_Libraries", "99_Archive". Example file format: "ProductCode_Subassembly_Name_Rev", e.g., "A120-01_Housing_Drawing_R01".

Define forbidden practices that most often break order: trailing spaces, "final_2_new_definitely", mixing Cyrillic and Latin without rules, different ways to write the same code.

Separate zones for libraries, templates and archives

Think about data that should be common to projects. It's better to put these in separate sections to avoid copying files and creating multiple versions.

Usually you separate libraries and standard parts (fasteners, profiles, typical nodes, validated models), templates (drawing templates, BOM templates, frames, settings), source files (CAD models and assemblies, drawings, calculations, related documents) and an archive (completed projects and obsolete revisions, read-only).

The library must be protected. If everyone can edit a standard element, trust in the data will disappear quickly.

Plan search before migration: categories and properties

The folder tree doesn't need to contain all logic. To find parts and documents faster, determine categories (for example: "Part", "Assembly", "Drawing", "Delivery Document") and required properties in advance.

A minimal set of required fields is: code/part number, name, project (if applicable), stage/status, owner, revision. Then a designer can find a "bracket" and filter by product, material and status "Released" instead of browsing folders.

If you design structure together with status and approval rules, CAD migration goes smoother: you don’t just "move files", you place them into a system where they are ready to use.

Preparing for migration: tidy data before transfer

Moving to Vault usually fails not because of server installation but because of the file state. The more honestly you sort data before the start, the fewer "lost" links and disputed versions afterward.

Start with an inventory. It’s important to understand not only where files are but who owns them. Often one network folder contains active projects, archives, library components and personal drafts. Make a simple picture: which formats exist (Inventor, AutoCAD, STEP, PDF), which projects were active in the last 3–6 months, and who owns each data set (responsible designer or project lead).

Next, clean up before transfer. Don’t try to "tidy ten years". The goal is to remove trash that breaks migration and annoys users:

• separate temporary and autosaved files;
• find obvious duplicates;
• split "current" and "obsolete branches" of projects so you don’t bring unnecessary data;
• at least standardize names of key assemblies and drawings;
• isolate libraries and standard parts into a separate area.

Pay special attention to assembly and drawing links. Usually what "breaks" is not the file itself but the path to it. Typical causes: manual moves, renames, copies in different folders or identical names in different projects.

A useful test: open several typical assemblies and their drawings in your current environment and note where link warnings already appear. Mark library components and reusable parts separately: for them it’s better to define a single location and rules beforehand.

Decide about old versions in advance. Often it makes sense to migrate only the last "released" version and the current working version to Vault, leaving the rest of the history in a separate archive with a clear structure and access. That keeps the main store lean and helps people find what they need faster.

Finally—plan downtime and communication. Set a "freeze" date when edits in shared folders stop, and decide who confirms data readiness (e.g., lead designer and IT). In public-sector or large-enterprise projects this avoids one department working in Vault while another continues saving files "the old way". If the integrator like GSE.kz accompanies the migration, agree in advance who cleans data and who verifies the result after transfer.

Implementation and migration stages: a step-by-step plan

It's better to move to Vault in short clear steps than in one big leap. This reduces the risk of broken assembly links, duplicates and halting department work.

1) Pilot and rule configuration

Start with a pilot: one real project and a small user group (for example, 3–5 designers and one data owner). The pilot checks whether Vault supports your real process, not an "ideal" one on paper.

Before mass migration, fix basic rules: folder structure and project separation (what will be "common" and what stays inside a project), unified naming rules for files and folders, categories and required properties (minimum: project, product/subassembly, stage, owner), search and view templates, basic permissions (who creates, who edits, who only views).

Don't try to set all possible statuses, approval routes and reports at once. At the start this usually slows people down.

2) Test transfer and migration in "waves"

Do a test migration on a copy of data before the main transfer. Check three things: assembly links, search by properties and real permission limits (for example, trainees should not change standard components).

Run the main migration in "waves": by projects or by departments depending on dependencies. Often it’s logical to start with active projects from the last 6–12 months and migrate archive later.

After the chosen date, enforce the rule: edits in old shared folders stop, work goes only through Vault. A practical approach is to set old folders to read-only and create new files only in Vault.

In the first week after go-live, do a short post-check: collect 10–15 typical issues (search, properties, access, user habits) and make quick fixes. If an integrator leads the rollout, agree on the support format for this period so questions don’t pile up.

Working rules: versions, statuses and change approvals

The goal when moving from shared folders is not to complicate life but to have everyone follow the same rules and not overwrite each other’s work. These rules are best written on one page.

Check-out and check-in: how not to get in each other's way

Agree that edits are made only via check-out, and finished work is always returned via check-in with a comment. Then it’s clear who is editing a file and what changed.

Initially simple agreements work: one person edits while others view; a comment on check-in is mandatory; if work is unfinished, the file can still be checked in at the end of the day as an intermediate version but not moved forward in status.

Starter statuses: the minimum that works

Statuses let anyone see at a glance whether a model can be edited, released to documentation, and who should review changes.

On first rollout a common chain is:

• Draft
• Under review
• Released
• Archive

Specify that only files suitable as a source of truth (for procurement, production or handoff) go to "Released". "Archive" holds files that shouldn’t be edited but may be needed for history.

A simple approval flow without extra steps

Keep it simple: one author prepares, one reviewer confirms. The designer moves from "Draft" to "Under review", and the lead designer or quality controller moves it to "Released" (or returns it to "Draft" with a short comment).

Example: a designer changed fastening hole diameters, checked in the assembly with comment "changed diameter, updated drawings" and sent it for review. The reviewer sees version history and status, checks key parameters and either approves or requests a specific fix.

Libraries and standards: don’t let them be broken

Standard components, templates, frames, materials and library models should be in a separate area and editable only by designated owners. For others, set read-only access so accidental edits don’t enter projects and create chaos.

Minimal discipline checks

To keep rules working, it’s enough to review a few simple metrics weekly and discuss them for 10 minutes: are there files stuck in check-out for a long time; check-ins without comments; how many objects are stuck in "Under review"; were libraries modified by unauthorized people; are there released files missing related documentation (if required).

These checks scale easily even in a small team and continue to work as the department grows or as manufacturing and other functions join.

Pilot and training: how to go live with minimal stress

How to run a pilot

A pilot verifies that Vault covers your typical tasks. Choose a small but active area: one project or one product line, 5–10 active users and only the file types they use daily.

Agree in advance what success looks like. Then discussions will be factual:

• assemblies open and update without broken links;
• finding and accessing the current version is faster than in the shared folder;
• permissions are clear and don't hinder work;
• no accidental overwrites of others' changes;
• it’s clear what is the source of truth and what is a working version.

Run a short set of scenarios that designers repeat: open a typical assembly and verify all components are found; replace a part in an assembly and confirm changes propagate correctly; update a drawing after a model change and save a new version; create a variant according to rules without manually copying folders; hand off work to a colleague via check-out/check-in and view history.

Training and feedback

Training should be short and role-based. For most users 30–60 minutes is enough if you show only daily actions: where to search, how to check out, how to check in, what to do if a file is "locked". After the session provide a one-page cheat sheet: 5–7 rules and 3 typical "what to do if..." items.

Collect feedback immediately after pilot scenarios while it's fresh. A simple three-question form works well: what hindered you, what was unclear, what rule needs clarification. Record specifics: folder names, templates, permissions, statuses, property names.

If the pilot is run with an integrator (for example, GSE.kz), appoint one responsible person from the department to accept rule changes. That prevents settings from "wandering" for weeks and helps the team see results faster.

Common mistakes when moving from shared folders to Vault

The most common mistake is treating Vault like a big network folder and simply dragging everything in. Vault gives version control and transparent changes, but only if data and rules are prepared.

Problems often start when teams try to migrate the entire archive at once. The store fills with duplicates, broken links, old revisions and files without owners, and the team loses trust in the system in the first week.

A second trap is an overly complex structure: dozens of folder levels, separate zones for every project, product and performer, plus complex permission matrices. People stop knowing where to find models and drawings and ask to "put it in a folder like before".

A third error is no naming rules and no required properties. Without unified part numbers, stages, owners and basic attributes (product, project, status), search becomes guesswork and "Housing_final_final" and "Assembly_new" reappear.

Another pain is parallel work in two places. If part of the team saves in Vault while others keep using the shared folder for speed, you get two truths. Meetings open the wrong drawing, production receives the wrong revision, and Vault gets blamed even though the problem is mixed working methods.

Finally, backups and recovery are often underestimated. Vault is not just files but a database with history, statuses and links. Without a clear backup and restore plan, any failure becomes a department downtime.

How to avoid these problems

A few simple rules help:

• Pilot one project or product group, not the entire archive.
• Design a flat and clear structure: fewer levels, more logic in properties and search.
• Introduce a minimal naming standard and required fields that must be filled before a file enters the working area.
• Set a cutover date: after it new versions appear only in Vault.
• Configure and test backups and restoration before launch.

An example that quickly clarifies the benefit: a designer changed hole diameters in a part, while a technologist opened the drawing from a shared folder — the shop will get the old size. One source of truth and clear statuses solve this faster than complex permissions.

Short pre-launch checklist and next steps

Before you fully leave shared folders for Vault, stop and check basic items. This takes an hour or two but saves weeks of troubleshooting why files "disappeared", links broke or duplicates appeared.

Readiness checklist

• Roles and process owners agreed: who administers, who releases/approves, who only views. Each role has a backup for vacations.
• Naming rules approved (at least for parts, assemblies and drawings) and a minimal set of required properties: e.g., part number, name, project, status.
• Storage structure prepared: projects separated, libraries and standard components moved out, templates in a clear place, archive zone exists.
• Test migration performed on a small sample: key assemblies moved, links, dependencies and drawings verified, and opening tested on users' workstations.
• Wave schedule and folder freeze moment defined: when editing in the old store stops and what to do with files that appear after the freeze.

If at least two items are not complete, postpone the go-live a few days to finish preparation. Launches with unresolved agreements usually end with the team bypassing Vault and returning to folders.

Next steps after confirming readiness

• Assess infrastructure for load: where will the Vault server be, are resources sufficient, how are backups and restores configured.
• Approve a one-page regulation: how to create a new project, where the library is, how releases are done, who and when changes statuses.
• Plan dedicated support for the first 2–4 weeks: quick answers to questions, resolving common mistakes, small rule adjustments.
• Fix success criteria: for example, 3–5 projects managed only in Vault, no out-of-system edits, assemblies open without manual file searches.

If you need help with CAD infrastructure and Vault, it's often better to solve it as a package: server, workstations and support. GSE.kz as a systems integrator and equipment supplier in Kazakhstan can cover this together with configuration and support so the system withstands real department loads.