Van Windows-mappen naar Vault: de overstap zonder drama

Een migratie naar Vault mislukt zelden op techniek. De server installeren, een project koppelen, bestanden inchecken: dat is een overzichtelijke klus die keurig gedocumenteerd is. Waar het wel misgaat: in de weken ervoor, als niemand de netwerkschijf durft op te schonen, en in de weken erna, als het halve team stiekem toch weer op de oude mappen werkt omdat dat vertrouwd voelt.

Wie een migratie naar Vault voor de boeg heeft, doet er dus goed aan het grootste deel van de aandacht op voorbereiding en gedrag te richten, niet op de software. In dit artikel vind je een gefaseerd plan dat in de praktijk werkt voor engineeringafdelingen van twee tot twintig man: eerst opschonen en afspraken vastleggen, dan project voor project over, en de oude schijf zo snel mogelijk op alleen-lezen. Met tussendoor een paar plekken waar een toolbox als Thundercad het voorbereidende handwerk verkleint.

Waarom de overstap misgaat

Drie patronen komen bij vrijwel elke moeizame migratie terug. Het eerste: vervuilde data mee verhuizen. Jaren aan kopieertjes, "oud"-mappen, halve projecten en dubbele bestandsnamen gaan één op één de kluis in, en vanaf dat moment is de rommel officieel onderdeel van het systeem. Zoeken in Vault levert dan drie treffers op voor hetzelfde onderdeel, en het vertrouwen in het nieuwe systeem is weg voordat het is opgebouwd.

Het tweede patroon: geen afspraken over de nieuwe structuur. De mappenboom van de oude schijf wordt klakkeloos overgenomen, inclusief de eigenaardigheden die alleen de langstzittende collega nog kan uitleggen. Het derde: er is geen moment waarop de oude schijf echt dichtgaat. Zolang beide routes openstaan, kiest een team onder druk altijd de oude, en na een paar maanden leven er twee waarheden naast elkaar.

Alle drie de patronen zijn te voorkomen, en geen ervan vraagt om technische hoogstandjes. Ze vragen om volgorde.

Fase 1: opschonen voordat er iets verhuist

Begin op de oude schijf, niet in Vault. Scheid eerst levend werk van archief: lopende projecten en de standaardbibliotheek zijn levend, alles wat is opgeleverd is archief. Voor dat archief geldt straks een lichter regime; het hoeft niet allemaal mee. Hoe je een opgeleverd project netjes afsluit en vindbaar archiveert, beschreven we eerder in Project klaar? Zo sluit je het netjes af (en vind je het over vijf jaar terug); wie dat al gewend is, heeft nu een streepje voor.

Daarna ga je door wat wel meegaat. Verwijder aantoonbaar dode bestanden: kopieën met "oud", "backup" of iemands initialen in de naam, mislukte varianten, exports die opnieuw te maken zijn. Los kapotte verwijzingen op, want elke verwijzing die nu al zoek is, wordt in Vault een incheckprobleem. En ruim de modellen zelf op: achtergebleven schetsen, ongebruikte geometrie en andere rommel maken bestanden onnodig zwaar. Met Model Cleaner van Thundercad haal je die restanten er per model in een paar klikken uit, en met iProperty Panel vul je via een datakaart per documenttype de metadata aan die je straks nodig hebt om in Vault iets terug te vinden.

Reken voor deze fase in weken, niet in dagen, en doe het met het hele team: een uur per week per persoon werkt beter dan één heldhaftige opruimzaterdag. Wat je nu niet opruimt, sleep je jaren mee.

Fase 2: afspraken vastleggen voordat de server aangaat

Terwijl het opschonen loopt, leg je de afspraken voor de nieuwe omgeving vast. Denk aan: hoe heten projecten, hoe heten bestanden, wat is de mappenstructuur in de kluis, wie geeft vrij en wat betekent een vrijgave. Dit hoeft geen rapport te zijn; twee A4'tjes waar het hele team achter staat zijn meer waard dan een handboek dat niemand leest. De inhoudelijke keuzes rond structuur en naamgeving zijn een onderwerp op zich, en die werken we uit in Vault inrichten: mappenstructuur en naamgeving die meegroeien.

Belangrijk is vooral dat de afspraken er zíjn voordat het eerste project de kluis in gaat. Elke conventie die je achteraf invoert, betekent herstelwerk in een systeem dat juist bedoeld is om historie vast te houden.

Fase 3: project voor project over, niet alles in één weekend

De verleiding is groot om de hele schijf in één migratieweekend naar binnen te trekken. Doe het niet: één bulkimport betekent dat elke fout in bulk mee naar binnen gaat, en dat het team van vrijdag op maandag zijn hele werkwijze moet omgooien. Gefaseerd werkt beter:

1. Kies één pilotproject en zet dat volledig in Vault: modellen, tekeningen, alles volgens de nieuwe afspraken.
2. Laat twee of drie mensen er een paar weken echt in werken, en pas de afspraken aan op wat schuurt.
3. Start vanaf dat moment elk nieuw project in Vault; op de oude schijf begint niets meer.
4. Verhuis lopende projecten op een natuurlijk moment, bijvoorbeeld bij een revisie of een nieuwe opdrachtfase.
5. Behandel het archief als laatste, en alleen wat het waard is: veelgebruikte standaarden wel, dode projecten niet.

Deze aanpak betekent dat er tijdelijk twee omgevingen naast elkaar bestaan. Dat is geen zwakte maar een keuze, zolang er per project maar precies één waarheid is: een project zit óf in Vault, óf op de schijf, nooit half in allebei.

Fase 4: de oude schijf op alleen-lezen

Dit is de stap die het verschil maakt tussen een migratie en een gedoogsituatie. Zodra de lopende projecten over zijn, gaat de oude schijf op alleen-lezen. Niet verwijderen: alles blijft raadpleegbaar, er kan alleen niets meer bij. Kondig het moment ruim van tevoren aan, herinner er in de laatste week dagelijks aan, en zet de datum niet opnieuw op de agenda als er gemor komt. Er komt gemor; dat hoort erbij en het zakt na een paar weken.

Alleen-lezen is eerlijker dan goede voornemens. Zolang schrijven kan, belandt onder tijdsdruk gegarandeerd weer een bestand op de oude plek, en elk bestand daar ondergraaft het nieuwe systeem. De praktijk: wie iets wil opslaan en tegen een alleen-lezen melding aanloopt, doet het meteen goed, en na een maand is de reflex verdwenen.

De eerste weken na de overstap

Na de omschakeling begint het echte werk: van de nieuwe route de makkelijkste route maken. Neem kleine ergernissen serieus, want daarop haken mensen af. Wijs één aanspreekpunt aan dat Vault-vragen dezelfde dag oppakt, en loop wekelijks kort langs wat er knelt. Vaak zijn het uitgeefroutines die aandacht vragen: het tekenpakket dat vroeger met slepen en kopiëren naar de werkplaats ging, komt nu uit de kluis. Met Batch Publish, dat samenwerkt met Vault, publiceer je tekeningen in bulk naar PDF, DWG, DXF of STEP, zodat de uitgifte na de overstap eerder sneller dan trager wordt.

Meet het succes niet aan de migratie zelf, maar aan de vragen erna. Als "waar staat de laatste versie?" van de afdeling verdwijnt, heeft de overstap gedaan wat hij moest doen.

Veelgestelde vragen

Hoe lang duurt een migratie naar Vault?

Reken voor het hele traject in maanden, waarvan het opschonen en de afspraken het grootste deel opslokken; de technische inrichting is doorgaans in dagen gedaan. De doorlooptijd hangt vooral af van hoeveel jaar aan data er op de schijf staat en hoeveel uur per week het team vrijmaakt.

Moet al het oude werk mee naar Vault?

Nee. Veelgebruikte standaarden en onderdelen die in lopende machines terugkomen wel; afgesloten projecten kunnen prima op een alleen-lezen archieflocatie blijven staan. Migreer archief alleen als iemand het aantoonbaar nodig heeft, anders importeer je vooral ruis.

Wat doe ik als het team terugvalt op de oude schijf?

Zet de schijf echt op alleen-lezen en maak de nieuwe route aantrekkelijker in plaats van alleen verplicht. Kijk waar de dagelijkse wrijving zit, bijvoorbeeld bij het uitgeven van tekenpakketten, en haal die weg; je kunt de toolbox met onder meer Batch Publish daarvoor 30 dagen gratis proberen.