Sie wechseln Ihr ATS ohne Kandidatenverluste, indem Sie in Phasen migrieren: Daten prüfen, exportieren, Felder mappen, beide Systeme parallel laufen lassen, dann zu einem festen Termin umschalten und verifizieren. In dieser Reihenfolge kommt selbst eine laufende Pipeline unversehrt an, sodass es keinen Grund gibt, an einem veralteten ATS festzuhalten, nur weil der Wechsel riskant wirkt.
Bei den meisten Teams ist es schlicht die Angst, die sie an einem alten ATS festhalten lässt. Eine laufende Pipeline samt Integrationen auf einen Schlag zu verschieben, fühlt sich riskant an, und ein einziger misslungener Export kann Menschen mitten im Prozess verlieren. Das Risiko ist real, aber Sie haben es im Griff: wechselbereite Plattformen, Sprad darunter, docken an den Stack an, den Sie ohnehin nutzen, sodass Sie auf einem System landen, das ab Tag eins mit Ihrer HR-Software und Ihren Jobbörsen spricht.
Ob ein Wechsel sauber gelingt oder eine Pipeline kostet, entscheiden wenige Weichenstellungen:
- Relationale Daten in eine Tabelle zu pressen, dupliziert Datensätze und verliert die Stage-Historie, also mappen Sie zuerst das Datenmodell.
- Anhänge sind der fragilste Teil, weil Download-Links binnen Stunden oder Tagen ablaufen und zu toten Links werden.
- Ein Parallelbetrieb von ein bis vier Wochen hält laufende Kandidaten aktiv, während das neue ATS frische Bewerbungen übernimmt.
- Integrationen und Teamgewohnheiten lassen Wechsel häufiger scheitern als die Daten selbst, also planen Sie beides vor dem Cutover.
Welche Schritte umfasst die Migration auf ein neues ATS?
Die Migration auf ein neues ATS läuft in sechs Phasen, und sie in der richtigen Reihenfolge zu halten, schützt Ihre Kandidaten. Die Dauer schwankt stark: Eine Self-Serve-Plattform kann in wenigen Stunden live sein, während ein großes Unternehmen mit vielen Integrationen zwei bis vier Monate braucht. Unternehmensgröße und Zahl der Integrationen treiben diese Spanne, sodass die Phasen unten mehr zählen als der Kalender.
- Prüfen und bereinigen: jedes Datenobjekt und jede Integration inventarisieren, Dubletten entfernen und offene DSGVO-Löschanfragen zuerst abarbeiten.
- Exportieren: eine strukturierte, maschinenlesbare Datei ziehen und prüfen, ob sie wirklich nutzbar ist, inklusive Historie und Datensatz-Beziehungen.
- Felder mappen: Kandidaten, Pipeline-Stages und benutzerdefinierte Felder auf das neue Datenmodell abbilden, bevor irgendetwas umzieht.
- Parallelbetrieb: das alte ATS für laufende Kandidaten aktiv halten, während neue Bewerbungen ins neue System fließen.
- Cutover: einen festen Abschalttermin setzen, Pipeline-Stages im Moment des Wechsels verifizieren und Datensatzzahlen abgleichen.
- Verifizieren: 20 bis 50 Datensätze stichprobenartig prüfen, 48 bis 72 Stunden beobachten, dann das alte System schreibgeschützt archivieren.
Wohin Sie wechseln, ist eine eigene Entscheidung, und es lohnt sich, den Markt vorher zu vergleichen. Unsere Übersicht der Anbieter-Kategorien zeigt, was jeder Tooltyp tatsächlich automatisiert. Steht das Ziel fest, machen die sechs Phasen aus dem Wechsel reine Projektarbeit, und der Parallelbetrieb ist die Phase, die Kandidaten am sichersten hält: Ausführliche Migrations-Leitfäden empfehlen, beide Systeme ein bis vier Wochen laufen zu lassen, bevor Sie an einem Wochenende umschalten.
Welche Kandidatendaten müssen mit, und was lassen Sie zurück?
Migrieren Sie alles, was einen Kandidaten im Rennen hält oder belegt, wie Sie mit ihm umgegangen sind, und lassen Sie zurück, was nur Ballast oder rechtliches Risiko ist. Eine saubere Migration ist vor allem Datenhygiene im Vorfeld, also klassifizieren Sie Ihre Datensätze, bevor Sie einen einzigen verschieben. Die meisten Unternehmen migrieren nur die letzten ein bis zwei Jahre und archivieren ältere Datensätze offline, was das neue System schnell und die Daten rechtssicher hält.
| Daten | Mitnehmen? | Warum es zählt |
|---|---|---|
| Kandidatenprofile und Bewerbungen mit Stage-Historie und Zeitstempeln | Ja | Hält laufende Kandidaten in der richtigen Pipeline-Stage |
| Original-Lebensläufe, Anschreiben und Angebotsschreiben (als Dateien) | Ja | Die Datei selbst ist der rechtlich erforderliche Nachweis |
| Interview-Scorecards und Feedback | Ja | Schützt Einstellungsentscheidungen und den Audit-Trail |
| Quellen-Zuordnung und Talentpool-Tags | Ja | Erhält Kanal-Reporting und erneute Ansprache |
| Einwilligungsnachweise und Kommunikationsverlauf | Ja | Sichert Ihre DSGVO-Rechtsgrundlage und den Kontext |
| Dubletten, leere Felder und veraltete Datensätze jenseits der Frist | Nein | Vor dem Export aussortieren |
| Kandidaten mit widerrufener Einwilligung oder Löschantrag | Nein | Zuerst im alten System löschen |
| Datensätze älter als ein bis zwei Jahre | Archivieren | Schreibgeschützt offline aufbewahren |
Die Originaldatei zählt mehr, als Teams erwarten. Nur die Datei selbst gilt als rechtlich erforderlicher Nachweis, deshalb muss ein originaler Lebenslauf oder ein Angebotsschreiben als echte Datei mitkommen, denn geparste Textfelder erfüllen die Aufbewahrungspflicht nicht. Die DSGVO stützt das von Kandidatenseite, da das Recht auf Datenübertragbarkeit bedeutet, dass personenbezogene Daten in einem strukturierten, maschinenlesbaren Format exportierbar sein müssen, mit einer Frist von einem Monat.
Vor dem Export DSGVO-seitig aufräumen: offene Löschanfragen im alten System abarbeiten, Kandidaten mit widerrufener Einwilligung ausschließen und Einwilligungs-Zeitstempel mitnehmen. In der DACH-Region werden Daten abgelehnter Bewerber in der Regel nach etwa sechs Monaten gelöscht, sodass es meist rechtskonform ist, nur die jüngeren Daten zu migrieren.
Das jetzt sauber zu dokumentieren, zahlt sich doppelt aus, denn dieselben Datensätze belegen Ihre DSGVO- und EU-AI-Act-Pflichten und ziehen sauber ins neue System um. Schludrige Einwilligungsdaten im alten ATS bleiben auch im neuen schludrig.
Wo verlieren Sie bei einer ATS-Migration tatsächlich Kandidaten?
Das größte Risiko ist, Kandidatendaten wie eine Tabelle zu behandeln. Eine ausführliche ATS-Migrations-Checkliste zeigt, warum: Kandidatendaten sind relational, und wer sie in eine CSV presst, dupliziert still Personen und verliert die Zeitstempel der Stage-Historie, die zeigen, wo jemand steht. Behandeln Sie den Umzug als Datenmodell-Übersetzung, bei der jeder Kandidat auch im neuen System mit seinen Bewerbungen verknüpft bleibt.
Anhänge sind der fragilste Teil des gesamten Umzugs. Die meisten ATS-APIs liefern temporäre Signed URLs für jeden Lebenslauf und jedes Schreiben zurück, weshalb ein unbedachter Export genau die Datei verlieren kann, die Sie rechtlich aufbewahren müssen.
Häufiger Fehler: Anhang-Links exportieren und die Dateien später herunterladen. Diese Links laufen oft binnen eines Tages ab, sodass der spätere Download tote Links liefert. Ziehen Sie jede Datei im selben Lauf wie den Export und prüfen Sie an einer Stichprobe, ob sie sich öffnen lässt.
Manche verlorenen Kandidaten hatten nie ein Datenproblem. Wenn der Wechsel Ihr Bewerbungsformular beschädigt oder Ihre Kandidaten-E-Mails unterbricht, springen Menschen von selbst ab, und die Zahlen sind kaum zu ignorieren. In überwiegend nordamerikanischen Daten brechen rund 60 % Bewerbungen ab, die lang oder kompliziert wirken, und ein Pflicht-Konto erhöht die Abbruchquote um etwa 40 %. Ein stockender Prozess befeuert außerdem Ghosting, für 59 % der Kandidaten die größte Frustration bei der Jobsuche, weshalb der Schutz der Candidate Experience beim Wechsel so wichtig ist wie der Schutz der Datenbank.
Export-Lock-in, kaputte Integrationen und Team-Akzeptanz: die Wechsel-Risiken jenseits der Daten
Die Daten herauszubekommen, ist manchmal der schwierigste Schritt, weil manche Anbieter den Ausstieg langsam und teuer machen. Ein Export kann ein Support-Ticket und fünf bis zehn Werktage Wartezeit bedeuten, wobei bestimmte Reports zusätzlich berechnet werden. Am besten testen Sie Ihren Ausstieg, bevor Sie irgendwo neu unterschreiben.
Testen Sie den Ausstieg vor der Unterschrift: Bitten Sie den neuen Anbieter, eine Stichprobe Ihrer Daten zu exportieren, und prüfen Sie, ob sie nutzbar ist, inklusive Historie und Objektbeziehungen. Lassen Sie sich schriftlich geben, was Sie exportieren dürfen und in welchem Format und Zeitrahmen. Ein Anbieter, den man leicht wieder verlassen kann, ist meist ein sicherer Anbieter für den Einstieg.
Integrationen brechen gern leise. Die üblichen Ursachen sind abgelaufene OAuth-Tokens und veraltete API-Versionen, und der Schaden bleibt unsichtbar, weil eine eingestellte Person wochenlang nicht ins Payroll-System synchronisiert wird, bevor es jemandem auffällt. Das Ausmaß ist gut belegt: 81 % der HR-Fachleute sagen, dass schwache Integration ihre Ziele ausbremst, während nur 39 % ihre Systeme als sinnvoll verbunden erleben. Testen Sie jede Verbindung direkt nach dem Cutover, bevor Sie sich darauf verlassen.
Selbst ein fehlerfreier Datenumzug scheitert, wenn das Team das neue Tool still verweigert. Recruiter rutschen zurück in Tabellen und E-Mails, sobald sich ein System wie Mehrarbeit anfühlt, weshalb Migrationen mehr an Menschen als an Technik gelingen oder scheitern. Ein benannter Executive Sponsor verschiebt die Chancen deutlich: Projekte ohne einen solchen scheitern etwa dreimal so oft. Kombinieren Sie diesen Sponsor mit rollenbasiertem Training und einem schriftlichen Projektplan, dann hört Akzeptanz auf, das zu sein, was einen sonst sauberen Wechsel zunichtemacht.
Wie ein ATS, das zu Ihrem Stack passt, die Wechselkosten senkt
Nur etwa 28 % der Unternehmen sind mit ihrem aktuellen ATS zufrieden, und jedes vierte plant den Wechsel innerhalb eines Jahres. Wenn Sie also raus wollen, sind Sie in guter Gesellschaft. Was die Kosten dieses Wechsels bestimmt, ist, wie gut das Ziel bereits zu den Tools drumherum passt. Wenn das neue ATS ab Tag eins mit Ihrem bestehenden Stack spricht, verschwindet das gefürchtete Neu-Verdrahten der Integrationen zum großen Teil.
Moderne OAuth-Marketplace-Integrationen haben dieses Neu-Verdrahten bereits von Monaten auf Minuten verkürzt, auch wenn benutzerdefinierte Felder und Stages weiterhin ein paar Stunden Mapping brauchen. Genau da setzt Sprad an. Es dockt an das HR-System an, das Sie ohnehin betreiben, ob Personio oder Workday, und postet weiter auf LinkedIn und Indeed, sodass Einstellungen ohne Neubau zurück ins Payroll-System fließen. Weil Sie es mit Ihrem Stack verbinden und die umliegenden Systeme behalten, bleibt der Wechsel vom ersten Tag an risikoarm.
Der Rest der Wechselkosten ist eine Frage von Zeit und Bindung, und beides bleibt hier gering. Sprad ist in unter zehn Minuten live, und der kostenlose Kern lässt Sie den vollen Recruiting-Workflow ausprobieren, von der Karriereseite bis zur Pipeline, bevor Sie einen einzigen Datensatz festlegen. Das Hosting liegt in der EU, mit eingebauter DSGVO- und EU-AI-Act-Konformität, was zählt, wenn Sie Kandidatendaten zwischen Systemen bewegen. Wenn Sie den Markt noch sondieren, lohnt ein Blick in die Kategorie Bewerbermanagement, um zu sehen, wo eine kostenlose, KI-native Option passt.
Aus Migrationsangst einen Projektplan machen
Die Teams, die Kandidaten verlieren, haben meist ordentliche Daten. Ihr eigentliches Problem ist, die Migration als stille IT-Aufgabe zu behandeln und zu vergessen, dass die Recruiter mitkommen müssen. Jeder schwierige Teil eines Wechsels hat eine bekannte Gegenmaßnahme, vom Sichern der Anhangdateien beim Export bis zum Benennen eines Executive Sponsors.
In der Praxis ist ein Wechsel schlicht Projektarbeit mit bekannter Reihenfolge. Wohin Sie wechseln, zählt so viel wie die Sorgfalt beim Umzug: Ein ATS, das schon zu Ihrem Stack passt, nimmt den Großteil des Risikos vorweg, und ein wirklich kostenloser Kern lässt Sie den ganzen Workflow zuerst mit Ihren eigenen Daten belegen, sodass Sie beim echten Umzug bereits genau wissen, was passiert.
FAQ: ATS wechseln, ohne Kandidaten zu verlieren
Wie lange dauert eine ATS-Migration?
Von wenigen Stunden bis zu einigen Monaten. Auf einer Self-Serve-Plattform ist eine HR-Fachkraft in Stunden live, während ein großes Unternehmen mit vielen Integrationen meist zwei bis vier Monate braucht, und die meisten mittelgroßen Teams landen mit ein paar Wochen dazwischen. Datenmenge und Zahl der Integrationen entscheiden, wo Sie liegen.
Verliere ich beim ATS-Wechsel Kandidatendaten?
Sollten Sie nicht, solange Sie Kandidatendaten als relational behandeln und die Originaldateien mitnehmen. Datenverlust entsteht meist beim Pressen in eine CSV, das Stage-Historie und Scorecard-Bewertungen abschneidet, oder durch Anhang-Links, die vor dem Download ablaufen. Gleichen Sie beim Cutover die Datensatzzahlen mit dem alten System ab, dann sinkt das Risiko gegen null.
Kann ich zwei ATS parallel betreiben?
Ja, und es ist der sicherste Weg zu wechseln. Halten Sie das alte System für laufende Kandidaten aktiv, während neue Bewerbungen ins neue ATS fließen, betreiben Sie beide etwa ein bis vier Wochen, gleichen Sie dann ab und schalten Sie zu einem festen Abschalttermin um. Der Abschalttermin verhindert, dass ein offener Parallelbetrieb dauerhaft auseinanderdriftet.
Wie exportiere ich Daten aus meinem alten ATS?
Fordern Sie einen strukturierten, maschinenlesbaren Export an, etwa CSV oder JSON, der Ihre Kandidaten- und Bewerbungsdaten samt Stage-Historie und Original-Anhängen umfasst. Prüfen Sie, ob die Datei wirklich nutzbar ist, bevor Sie bei einem neuen Anbieter unterschreiben, denn manche berechnen pro Anfrage und brauchen fünf bis zehn Werktage. Die DSGVO gibt Ihnen zudem ein Übertragbarkeitsrecht mit einer Frist von einem Monat.
Welche Integrationen brechen bei einer Migration?
Am häufigsten die Verbindungen zu Ihrem HR-System und Ihren Jobbörsen, meist durch abgelaufene OAuth-Tokens oder eine veraltete API-Version. Die Ausfälle sind leise: Eine eingestellte Person wird womöglich wochenlang nicht ins Payroll-System synchronisiert, bevor es auffällt. Testen Sie jede Integration direkt nach dem Cutover, bevor Sie sich darauf verlassen.


