Overstappen naar een nieuw ATS: zo verhuis je je kandidatendatabase zonder rommel mee te nemen in 2026

Een ATS-migratie wordt vaak ingekocht als een IT-project en loopt vast als een datavraagstuk. Het systeem staat er meestal binnen een paar weken, maar wat je erin zet bepaalt of je bureau er de komende jaren mee vooruit kan. Deze gids laat zien wat je opschoont voordat je verhuist, hoe je velden koppelt, wat de AVG van je vraagt en waar migraties in de praktijk stukgaan.

Wat houdt een ATS-migratie precies in?

Een ATS-migratie is het overzetten van je kandidaten, klanten, vacatures, documenten en historie van het ene applicant tracking system naar het andere. Dat klinkt als een technische handeling, maar in de praktijk verplaats je drie dingen tegelijk en maar een daarvan is echt software.

Het eerste is de data. Alles wat in je oude systeem staat, moet ergens in het nieuwe landen: profielen, cv's, notities, e-mailwisselingen, plaatsingen, urenstaten en de koppeling tussen kandidaat en opdracht. Bij een bureau dat tien jaar bestaat gaat het al snel om tienduizenden records, waarvan een deel is aangemaakt door mensen die er niet meer werken en volgens afspraken die niemand meer kent.

Het tweede is het proces. Twee systemen delen zelden dezelfde begrippen. Wat in het ene systeem een status is, is in het andere een fase, een label of een aparte lijst. Je kunt je oude proces niet een op een nabouwen, en dat hoef je meestal ook niet te willen. Maar iemand moet die vertaling maken en opschrijven voordat de eerste rij data beweegt.

Het derde zijn de mensen. Een recruiter die zes jaar in hetzelfde scherm heeft gewerkt, werkt op automatismen. Die automatismen kloppen op dag een niet meer. Dat is geen weerstand maar een leercurve, en de organisaties die dat onderschatten zien in de eerste maanden dat er weer buiten het systeem om wordt gewerkt: een lijstje in Excel, een mapje op de eigen schijf.

Deze gids gaat over het eerste spoor, omdat dat het enige spoor is dat je vooraf volledig in eigen hand hebt. Je leverancier kan je proces adviseren en je team trainen, maar de kwaliteit van wat je verhuist bepaal je zelf. Dat is ook de reden dat Spadework bij een implementatie altijd eerst naar het bestand kijkt en pas daarna naar de koppeling met je ATS.

Waarom je data en niet je software de uitkomst bepaalt

De vraag die bij een overstap centraal komt te staan is bijna altijd welk systeem het wordt. Dat is een begrijpelijke vraag en een minder belangrijke dan hij lijkt. De Nederlandse systemen die serieus meedoen in de staffingmarkt zijn onderling volwassen; de verschillen zitten in accenten, niet in of het werkt. Wat wel per bureau enorm verschilt, is de staat van het bestand dat erin gaat.

Dat komt doordat een migratie niets repareert. Een verhuizing verplaatst wat er staat en maakt de gebreken zichtbaar op een moment dat je er het minst op zit te wachten. Dubbele profielen worden dubbele profielen in het nieuwe systeem. Lege velden blijven leeg. Verkeerd geplaatste gegevens landen ergens waar niemand ze zoekt. Wie je opschoning uitstelt tot na de go-live, schoont in de praktijk niet op, want dan is iedereen al bezig met werken.

Er is nog een reden om vooraf te kijken. Het formaat waarin je oude systeem exporteert, dwingt keuzes af. Datumnotaties, veldlengtes, het onderscheid tussen een leeg veld en een veld met de tekst onbekend: allemaal dingen die bij het inlezen ofwel netjes worden overgenomen ofwel stilletjes worden afgekapt. Fouten die daar ontstaan, merk je pas maanden later wanneer een zoekopdracht minder oplevert dan zou moeten.

Voor een bureau is dat geen administratief ongemak. Je bestand is je voorraad, en elk profiel dat na de migratie niet vindbaar is, is voorraad die je niet kunt verkopen. Die redenering staat uitgewerkt in van database naar omzet, en de reden dat het bij bureaus zwaarder telt dan bij corporates lees je in waarom je beste kandidaat vaak al in je eigen database zit. Kies dus een systeem, maar besteed de meeste voorbereidingstijd aan wat je erin stopt.

Wat je opschoont voordat je iets verhuist

Opschonen doe je in het oude systeem, in de maanden voor de overstap. Dat voelt onlogisch, want je gaat er weg. Toch is het de enige plek waar de context nog compleet is: de collega die weet waarom dat ene profiel drie keer bestaat, werkt nog met dat scherm. Hoe je overziet hoe groot je probleem is, staat in hoe je een vervuilde recruitmentdatabase herkent.

De volgorde is belangrijker dan de volledigheid. Je hoeft niet alles perfect te krijgen, je moet voorkomen dat je fouten vermenigvuldigt door ze mee te nemen.

Stap een en stap drie versterken elkaar. Ontdubbelen werkt beter naarmate profielen meer gevulde velden hebben om op te vergelijken, en velden vullen heeft meer zin wanneer je niet drie versies van dezelfde persoon aan het verrijken bent. Begin daarom met een ronde ontdubbelen op harde kenmerken, vul dan de velden, en doe daarna een tweede ronde. De methode staat in dubbele kandidaatprofielen ontdubbelen.

Veldmapping: wat past, wat niet past en wat je loslaat

Veldmapping is de afspraak welk veld uit het oude systeem in welk veld van het nieuwe terechtkomt. Het is het saaiste onderdeel van een migratie en het onderdeel waar de meeste stille schade ontstaat, omdat het gebeurt in een spreadsheet die niemand buiten het projectteam ziet.

Drie categorieen komen er altijd uit. De eerste zijn de velden die een-op-een passen: naam, e-mail, telefoon, woonplaats. Controleer daar alleen wat er met formaten gebeurt. Een telefoonnummer met een spatie of een landcode kan bij het inlezen worden afgekeurd, en dan mis je precies het veld waarmee je belt.

De tweede categorie zijn de velden die anders heten of anders zijn opgebouwd. Statussen zijn de klassieker. Een bureau dat elf kandidaatstatussen gebruikte en overstapt naar een systeem met zes, moet kiezen welke samenvallen. Dat is een inhoudelijke beslissing en geen technische, en de reden om er een recruiter bij te zetten en niet alleen een beheerder.

De derde categorie is de lastigste: velden zonder bestemming. Vrije tekstvelden, zelfgemaakte kenmerken, notitieregels waarin jarenlang informatie is gepropt die ergens anders hoort. Er zijn dan drie opties. Je vertaalt het naar een gestructureerd veld, je parkeert het in een notitieveld waar je nooit meer op doorzoekt, of je laat het vallen. Alle drie zijn verdedigbaar. Wat niet werkt, is geen keuze maken, want dan kiest de import voor je.

Een migratie is ook het moment om de zoekvelden opnieuw te laten vullen vanuit de brondocumenten. Hoe nauwkeurig dat gaat, staat in cv-parsing voor recruitmentbureaus. Wie dat overslaat, verhuist duizenden bijlagen zonder velden.

Wat de AVG van je vraagt bij een migratie

Een migratie is een verwerking van persoonsgegevens, en er komt bijna altijd een extra partij bij kijken: de nieuwe leverancier, soms een implementatiepartner. Met elke partij die namens jou gegevens verwerkt, sluit je een verwerkersovereenkomst. Dat geldt ook voor een tijdelijke partij die alleen de conversie doet, en het is een van de eerste dingen waar een toezichthouder naar vraagt.

Het tweede punt is de bewaartermijn. De richtlijn van de Autoriteit Persoonsgegevens is dat je sollicitatiegegevens uiterlijk vier weken na afronding van de procedure verwijdert, en dat je ze tot maximaal een jaar mag bewaren wanneer de kandidaat daar toestemming voor geeft. Veel bureaus hebben die termijn in het oude systeem nooit strak toegepast. Een migratie is het moment waarop dat zichtbaar wordt, want je gaat records per stuk langs.

Let daarbij op een valkuil in de nieuwe omgeving. Sommige systemen verwijderen na de bewaartermijn niet echt, maar verplaatsen het profiel naar een talentpool of een archief. Dat is een andere verwerking met een andere grondslag, en je moet kunnen uitleggen op welke van de twee je je beroept. De uitwerking van termijnen en grondslagen staat in bewaartermijnen voor kandidaatdata onder de AVG.

Het derde punt wordt het vaakst vergeten: kopieen buiten het systeem. Cv's in mailboxen, exports op gedeelde schijven, lijstjes in Excel, documenten in chatgesprekken. Voor de wet vallen die onder dezelfde termijn als het record in je ATS. Een migratie waarbij je netjes opruimt in het systeem terwijl er een map met vierduizend cv's op een netwerkschijf blijft staan, is geen opgeruimde migratie. Spreek daarom af dat de opruimronde beide kanten omvat, en zet dat in het projectplan naast de technische stappen.

Waar een migratie in de praktijk vastloopt

Over mislukte ATS-implementaties is opvallend weinig onafhankelijk materiaal beschikbaar. Vrijwel alles wat er in het Nederlands over is gepubliceerd, komt van leveranciers en implementatiepartners die zelf een systeem verkopen. Dat maakt hun lijstjes niet onwaar, maar wel gekleurd: de fouten die zij noemen zijn de fouten die met hun aanpak op te lossen zijn. Lees ze als checklist, niet als onderzoek.

Met dat voorbehoud komen vijf patronen zo consequent terug dat ze het noemen waard zijn. Het eerste is beginnen bij de software in plaats van bij het eigen proces. Wie niet kan opschrijven hoe zijn werkstroom loopt, koopt de inrichting van iemand anders en merkt na drie maanden dat die niet past.

Het tweede is de voorbereiding van de datamigratie onderschatten. Een enkele fout in de mapping levert dubbele records, ontbrekende gegevens of halve profielen op, en die worden pas zichtbaar wanneer iemand iets niet kan vinden. Het derde is te weinig aandacht voor training en adoptie: het systeem staat, de mensen werken eromheen.

Het vierde patroon is functionaliteit die ongebruikt blijft. Bureaus betalen voor modules die nooit worden ingericht omdat er na de go-live geen tijd meer voor is. Het vijfde is een systeem kiezen dat past bij het bureau van vandaag en niet bij dat van over drie jaar, waardoor je de hele oefening te vroeg opnieuw doet.

Wat in al deze patronen terugkomt, is niet techniek maar aandacht. De bureaus die een migratie goed doorkomen, hebben iemand vrijgemaakt die er echt tijd voor heeft en die zowel het proces als het bestand kent. Dat is zelden de leverancier en zelden de IT-afdeling. In de trajecten die Spadework begeleidt is dat vrijwel altijd een senior recruiter met mandaat, niet een projectmanager van buiten.

De eerste negentig dagen na de overstap

De go-live is niet het einde van het project maar het begin van de meting. In de eerste weken bepaal je of de migratie is geslaagd, en dat doe je niet door te tellen hoeveel records er zijn overgekomen. Dat aantal klopt bijna altijd. Wat je wilt weten is of de records bruikbaar zijn.

Doe daarom in week een een steekproef van vijftig profielen, verdeeld over oud en nieuw, met en zonder bijlage. Kijk per profiel of de zoekvelden gevuld zijn, of de bijlage opent en of de historie klopt. Vijftig profielen kosten een ochtend en vertellen je meer dan elk rapport uit de importlog.

Meet daarnaast iets wat je voor de overstap ook hebt gemeten. Draai drie zoekopdrachten die je in het oude systeem kende en vergelijk het aantal treffers. Wijkt dat sterk af, dan zit er iets mis in de mapping van juist die velden, en dat is in de eerste maand nog te herstellen. Na een halfjaar is het verweven met nieuw ingevoerde data en veel duurder.

Gebruik het momentum vervolgens voor de stap die bijna nooit wordt gezet: bepalen of je bestand nu goed genoeg is om er iets slims bovenop te zetten. Een schoon, gevuld bestand is de voorwaarde voor signalering, voor gerichte boolean search, voor verrijking en voor het opmerken van beweging bij mensen die je al kent, zoals beschreven in de drie signaalsoorten. Waar de lat ligt, staat in wanneer is je database AI-ready. Voor het opnieuw uitlezen van brondocumenten en het omzetten naar vacaturespecifieke profielen gebruiken bureaus de CV-Transformer van Spadework.

Je hebt net een verhuizing achter de rug waarin je je hele bestand hebt aangeraakt. Dat gebeurt eens in de zoveel jaar. Jij kent deze mensen. Jij ziet ze op tijd. Jij bepaalt wat je ermee doet.

Veelgestelde vragen

Lees ook