Introduction
You are switching ATS. Your team is nervous because the last migration at their old company lost three months of candidate history and two active roles in the cutover. You want to know exactly what to avoid, what to test, and what a safe 2026 migration actually looks like — especially in DACH, where GDPR, works councils, and the August 2026 EU AI Act deadline all collide with your technical plan.
This guide is for HR-Ops leads, Heads of Talent, and CTOs running mid-market (200–2.000 FTE) ATS migrations in Germany, Austria, or Switzerland. It maps the migration lifecycle, names the five failure modes that make ATS migrations fail most often, and gives you a concrete pre-migration audit you can run this week.
TL;DR
- About one in three ATS migrations result in measurable data loss, corrupted candidate records, or broken downstream integrations (ATLAS, Sep 2025).
- The five failure modes are: no migration strategy, dirty source data, poor field mapping, zero QA, and hard-cutover without parallel run.
- You need a rollback plan before you start. Losing your old ATS on Day 1 is the single most expensive mistake we see.
- In DACH, GDPR Article 17 (right to erasure) and the EU AI Act (full enforcement from August 2, 2026) change what you can migrate and how you document it.
- Keep your source-of-record ATS, and put a connectivity layer in front. Migration risk drops by an order of magnitude when you stop forcing every integration to be rebuilt.
- A well-run migration for a 500-FTE company takes 8–12 weeks, not two weekends.
What "ATS migration" actually means in 2026
An ATS migration is the structured move of candidate data, job history, workflows, users, and integrations from one applicant tracking system to another. In mid-market DACH, this almost always involves connecting or syncing with Personio, SAP SuccessFactors, Workday, or a local HR suite — and rebuilding every job-board, sourcing-platform, and assessment-tool connection on the new system.
Modern migrations are not "export CSV, import CSV." They are multi-phase projects with data cleansing, field mapping, parallel running, and compliance documentation. A 500-FTE company with two years of history and 35 open roles typically moves 40.000–80.000 candidate records and 500–1.200 active integration touchpoints. Getting any one of those wrong shows up as a missing candidate, a broken feedback loop, or an unhired hire.
Three things have changed since 2023:
- Regulatory weight. The EU AI Act classifies every recruiting AI feature (CV screening, candidate matching, targeted job advertising) as high-risk, with full obligations enforced from August 2, 2026.
- Integration sprawl. The median mid-market DACH recruiting stack uses 9–14 tools (Radancy Roundtable, Jan 2025). A migration touches every one of them.
- AI-surfaced risk. Candidate sourcing today includes LLM-based chatbots and scoring, often deployed without documentation. A migration is the moment that debt becomes visible.
Why one in three migrations fail
Most failed migrations are not technical surprises. They are planning failures that compound. Roughly one in three ATS migrations ends with measurable data loss, corrupted records, or broken integrations — and in every post-mortem we have read, the same five mistakes appear.
"The most frequent issue is a lack of planning. Without a clear migration strategy, poor data quality, missing fields, and mapping errors become much more likely."
ATLAS, ATS Migration Risks, 2025
Five failure modes keep appearing in post-mortems:
| Failure mode | What it looks like in practice | How to prevent it |
|---|---|---|
| No migration strategy | You start exporting before scope, timeline, or ownership is signed off | 6-week planning phase with a signed-off scope document |
| Dirty source data | Duplicate candidates, orphan records, and stale pipeline stages migrate forward | Pre-migration audit, data cleansing sprint, GDPR deletion of expired records |
| Poor field mapping | Notes land as unreadable attachments; phone numbers end up in one unlabeled field | Field-by-field mapping doc reviewed by both vendors |
| No QA | Row counts match so the migration is "done" — until a recruiter cannot find last week's candidate | Sample audit: 5% of records hand-verified; 100% of active pipelines compared side-by-side |
| Hard cutover | Old ATS turned off Monday morning, new one is the ground truth, no rollback possible | Parallel run for 2–4 weeks, old ATS read-only for 90+ days |
Monte Carlo's 2025 migration study covers the same pattern across industries: "Your migration completes 'successfully,' row counts match, but the data itself is silently broken" (Monte Carlo, July 2025). Silent corruption is the hardest failure mode because it shows up weeks later — in a hiring manager's missing comment, a candidate's wrong status, a GDPR deletion that never propagated.
The pre-migration audit (run this week)
Before you sign the new ATS contract, run this six-step audit. It takes roughly 12 working hours over a week and saves an estimated 60–120 hours of painful rework later. Skip none of the steps. The order matters — each one feeds the next.
- Inventory every downstream integration. List every tool that reads from or writes to your current ATS. Job boards (StepStone, Indeed, LinkedIn, XING, HeyJobs, DACH-local boards), assessment platforms, video interview tools, background checks, onboarding handoff to Personio/Workday, Slack/Teams notifications, candidate CRMs. Mid-market DACH average: 9–14 integrations. Expect to find 2–3 you did not know existed.
- Identify data-retention triggers. Article 17 GDPR and its German transposition in §35 BDSG mean expired candidate data must not be migrated. Run a deletion report first. Expect to delete 15–35% of your database. That is a feature, not a problem.
- Catalog custom fields and required fields. Fields that are custom in your source ATS often do not exist in your target. Decide early: map into a custom field in the target, concatenate into a notes field, or drop.
- Map your workflows, not just your data. The migration of data is visible. The loss of workflow logic (approval chains, auto-rejection rules, feedback routing) is invisible until the second week after cutover. Document every rule as an operator-readable script. If you cannot explain it in one paragraph, your workflow is too complex.
- Define your "done" criteria. Row counts. Active-role counts. Random-sample audit score (target: 100% of 50 randomly sampled candidate profiles matching). Integration-smoke-test passing (post a test job, receive a test application, complete a test hire).
- Pick your rollback window. Minimum: 90 days of read-only access to the old ATS. Maximum: one full hiring quarter. Budget for it. The vendor will try to cut you off at 30 days. Do not let them.
"Keeping access to your old system during and shortly after migration gives your team a fallback if anything goes wrong. It also allows for side-by-side validation, which helps build trust in the new platform."
ATLAS, ATS Migration Mistakes, Aug 2025
Data mapping without tears
Data mapping is the step that kills migrations silently. Get it wrong and the symptoms appear three weeks after cutover, when a hiring manager asks where her candidate's interview notes went.
Own the mapping document yourself. Do not let either vendor (old or new ATS) own it unilaterally. The mapping document is a spreadsheet where each row is a source field and each column records target field, transformation logic, owner, and QA status. Expect 200–600 rows for a mid-market ATS.
Seven rules for mapping that hold up under pressure:
- One source field, one target field. If you need to split or concatenate, document the transformation with a code snippet or a pseudocode line — never a human paragraph.
- Preserve timestamps in ISO 8601 UTC. Time-zone conversion errors routinely mis-date interview notes.
- Never migrate to a field you do not fully understand in the target system. Ask the target vendor for their field dictionary.
- Candidate notes must land in a searchable field, not as attachments. If the target's notes are length-capped, split with a paginated marker.
- Phone numbers: E.164 format, country-coded. One field per number, with a type flag (mobile/landline/work).
- Test with 50 records before migrating 50.000. Hand-verify. Find the broken pattern. Fix. Repeat.
- Keep the mapping spreadsheet versioned. Every change gets a row in a change-log tab.
with your stack?
QA, parallel-run, and the cutover playbook
The cutover is not a weekend. It is a staged handover that takes four weeks for a 500-FTE company. The cost of running two systems in parallel for a month is a fraction of the cost of one silent-corruption incident in week six.
Week 1–2 of parallel run:
- Old ATS: read-write for all users.
- New ATS: read-write for a pilot squad (usually 2–3 recruiters + 1 hiring manager on the least-critical role).
- Integrations: mirrored — job posts go to both systems.
- Measurement: log every delta between systems.
Week 3 of parallel run:
- All users shift to new ATS as primary.
- Old ATS becomes read-only for recruiters; write-enabled only for a designated migration lead.
- Any defect triggers rollback to mirrored mode.
Week 4 — Cutover:
- Old ATS read-only for all.
- New ATS is system of record.
- All integrations point to new ATS only.
- Old ATS stays read-only for 90+ days.
Three go/no-go checks before cutover:
| Check | Pass condition |
|---|---|
| Active roles migrated | 100% of roles with a stage later than "screen" have parity in the new ATS |
| Integration smoke test | Post-to-StepStone, post-to-Indeed, receive application, move candidate, send rejection — all end-to-end |
| Pipeline sample audit | 50 candidates randomly drawn, 50 match the source record across 10 key fields |
If any check fails, reset the parallel-run clock by one week. Do not negotiate this. The cost of a delayed cutover is small. The cost of a corrupted cutover is large and slow to surface.
GDPR and the EU AI Act — what migrators must document
Two regulatory layers matter in DACH, and both are enforced in 2026. Get the documentation right during migration — it is far harder to backfill once data is moved.
GDPR (Art. 17 + Art. 30): Expired candidate data must be deleted before migration, not after. Maintain a Record of Processing Activities (ROPA) that logs every migration step, data controller, processor, and purpose. If the migration involves a non-EU processor (for example a US-based vendor), Schrems-II requires you to document your Transfer Impact Assessment and additional safeguards.
EU AI Act (effective Aug 2, 2026 for Annex III systems): Any AI feature in your new ATS (or migrated from the old one) that touches CV screening, candidate ranking, or targeted job advertising is classified high-risk. Deployers (you) must maintain risk assessments, bias-testing results, human-oversight procedures, and transparency disclosures to candidates and workers' representatives (Omniteam, Feb 2026).
"If you use AI for anything touching people's decisions, from hiring to performance evaluation, you are directly affected. Ask vendors for AI Act compliance documentation (technical files, bias tests, human-oversight procedures)."
Boundless HQ, March 2026
Concrete migration documentation checklist:
- ROPA entry for the migration event (controller, processor, categories of data, retention, legal basis)
- Data minimization statement: what you chose not to migrate and why
- Transfer Impact Assessment if any data crosses the EEA border
- Vendor-supplied EU-AI-Act documentation for every high-risk AI feature in the new ATS
- Works council notification where applicable (in Germany: §87 Abs. 1 Nr. 6 BetrVG co-determination triggers for AI tooling)
- Candidate-facing transparency notice updated to reflect new tools
When to migrate vs. when to add connectivity instead
Half the ATS migrations we see should not happen. They are triggered by a missing integration, not a bad ATS. If your Personio + StepStone flow is broken, ripping out Personio does not fix it — adding a connectivity layer does. The decision is rarely binary; the matrix below clarifies which signal you are actually responding to.
| Signal | Migrate the ATS | Add connectivity instead |
|---|---|---|
| Hiring volume / scale | UI freezes, data caps, reporting gaps no report builder fixes | ATS handles your volume; only integrations break |
| Compliance gaps | Core compliance features absent (audit logs, candidate-level deletion, EU residency) | ATS is compliant; you only need GDPR-grade integration logs |
| Engineering bandwidth | Not the bottleneck — you have the team to run a migration | Engineering is the constraint, not the ATS |
| Strategic data model | You moved from single-country to multi-country and need different role/location modeling | Same data model still fits, but external connections are unreliable |
| Timing | You can absorb 8–12 weeks of project work | You need the problem fixed in weeks, not months, and you are pre-IPO |
A connectivity layer like Kini keeps your ATS as system of record and handles the job-board and sourcing sync without your engineering team building or maintaining anything. This is the category we call Managed Recruiting Connectivity — not iPaaS, not Unified API for developers, but an operated layer for recruiting teams.
Next steps
Three things to do this week, regardless of whether you end up migrating or adding connectivity:
- Run the pre-migration audit (Section 3). Inventory integrations. Identify retention triggers. Document your custom fields.
- Pick your go/no-go criteria. Write them down. Share them with your team before the vendor conversations start.
- Decide: migrate or connect? If your ATS is fine and only integrations are broken, a Managed Recruiting Connectivity layer is faster, cheaper, and reversible.
If you are evaluating Kini as your connectivity layer or want a second opinion on your migration plan, book a 20-minute call with a founder. No slides, no pitch — just a conversation about whether we can help.
