A migration to Vault rarely fails on technology. Installing the server, connecting a project, checking files in: that is a manageable job and it is well documented. Where it does go wrong: in the weeks before, when nobody dares to clean up the network drive, and in the weeks after, when half the team quietly keeps working on the old folders because that is what feels familiar.
So if you are about to migrate to Vault, aim most of your attention at preparation and behaviour, not at the software. In this article you will find a phased plan that works in practice for engineering teams of two to twenty people: clean up and agree on conventions first, then move over project by project, and put the old drive on read-only as soon as you can. Along the way there are a few spots where a toolbox like Thundercad shrinks the preparatory legwork.
Why the move goes wrong
Three patterns show up in almost every painful migration. The first: moving polluted data along. Years of stray copies, "old" folders, half-finished projects and duplicate file names go into the vault one to one, and from that moment the mess is officially part of the system. A search in Vault then returns three hits for the same part, and trust in the new system is gone before it was ever built up.
The second pattern: no agreements about the new structure. The folder tree of the old drive is copied over wholesale, including the quirks only the longest-serving colleague can still explain. The third: there is never a moment when the old drive actually closes. As long as both routes stay open, a team under pressure will always pick the old one, and after a few months two versions of the truth live side by side.
All three patterns are avoidable, and none of them calls for technical heroics. They call for doing things in the right order.
Phase 1: clean up before anything moves
Start on the old drive, not in Vault. First separate live work from archive: running projects and the standards library are live, everything that has been delivered is archive. The archive will get a lighter regime later; not all of it needs to come along. How to close out a delivered project properly and archive it findably is something we covered earlier in Project done? Closing it properly (so you can find it in five years); teams already in that habit have a head start now.
Then work through what does come along. Delete files that are demonstrably dead: copies with "old", "backup" or someone's initials in the name, failed variants, exports that can be regenerated. Fix broken references, because every reference that is already lost today becomes a check-in problem in Vault. And clean up the models themselves: leftover sketches, unused geometry and other clutter make files needlessly heavy. With Model Cleaner from Thundercad you strip those leftovers out of a model in a few clicks, and with iProperty Panel you use a configurable data card per document type to fill in the metadata you will soon need to find anything back in Vault.
Budget this phase in weeks, not days, and do it with the whole team: an hour per person per week beats one heroic clean-up Saturday. Whatever you do not clean up now, you will drag along for years.
Phase 2: put the agreements in writing before the server goes live
While the clean-up is running, write down the agreements for the new environment. Think of: how projects are named, how files are named, what the folder structure inside the vault looks like, who releases and what a release means. This does not have to be a report; two pages the whole team stands behind are worth more than a manual nobody reads. The actual choices around structure and naming are a topic of their own, and we work them out in Setting up Vault: a folder structure and naming that grow with you.
What matters most is that the agreements exist before the first project enters the vault. Every convention you introduce afterwards means repair work in a system that is designed to hold on to history.
The toughest part of phase 1 is walking through hundreds of models and their properties. Most of that legwork can be handed off, and you can quietly try it alongside your current way of working.
Try 30 days freePhase 3: project by project, not everything in one weekend
The temptation is to pull the whole drive in during one migration weekend. Do not: one bulk import means every mistake goes in wholesale too, and the team has to flip its entire way of working between Friday and Monday. Phased works better:
- Pick one pilot project and put it fully into Vault: models, drawings, everything according to the new agreements.
- Have two or three people genuinely work in it for a few weeks, and adjust the agreements where they chafe.
- From that moment, start every new project in Vault; nothing new begins on the old drive.
- Move running projects at a natural moment, for example at a revision or a new project phase.
- Handle the archive last, and only what deserves it: frequently used standards yes, dead projects no.
This approach means two environments exist side by side for a while. That is not a weakness but a choice, as long as there is precisely one truth per project: a project lives either in Vault or on the drive, never halfway in both.
Phase 4: the old drive goes read-only
This is the step that separates a migration from a tolerated in-between state. As soon as the running projects are over, the old drive goes read-only. Do not delete it: everything stays available for reference, nothing new can be added. Announce the moment well in advance, remind people daily in the final week, and do not reschedule when the grumbling starts. There will be grumbling; it is part of the deal and it fades after a few weeks.
Read-only is more honest than good intentions. As long as writing is possible, a file will land on the old drive again under time pressure, guaranteed, and every file there undermines the new system. In practice: whoever tries to save something and hits a read-only message does it right the first time, and after a month the reflex is gone.
The first weeks after the move
After the switch the real work begins: making the new route the easiest route. Take small irritations seriously, because that is where people drop off. Appoint one go-to person who picks up Vault questions the same day, and do a short weekly round of what is chafing. Often it is the publishing routines that need attention: the drawing package that used to reach the shop floor by dragging and copying now comes out of the vault. With Batch Publish, which works together with Vault, you publish drawings in bulk to PDF, DWG, DXF or STEP, so issuing work after the move gets faster rather than slower.
Do not measure success by the migration itself, but by the questions afterwards. When "where is the latest version?" vanishes from the department, the move has done what it was supposed to do.
Frequently asked questions
How long does a migration to Vault take?
Budget months for the whole journey, with the clean-up and the agreements eating most of it; the technical setup is typically done in days. The lead time mostly depends on how many years of data sit on the drive and how many hours per week the team frees up.
Does all the old work have to move into Vault?
No. Frequently used standards and parts that return in running machines should; completed projects can happily stay in a read-only archive location. Only migrate archive material when someone demonstrably needs it, otherwise you are mostly importing noise.
What if the team keeps falling back on the old drive?
Make the drive genuinely read-only and make the new route more attractive instead of merely mandatory. Find the daily friction, for example around issuing drawing packages, and remove it; you can try the toolbox, including Batch Publish, free for 30 days.