Recruiting teams migrating between ATS platforms face three distinct technical paths (flat CSV export, API-based object mapping, and middleware migration tools), and each one trades speed against data integrity in ways that shape reporting accuracy, compliance posture, and candidate experience for years after cutover.
TL;DR: Flat CSV exports are fast and cheap but sever the relational links between candidates, applications, and jobs, creating lasting ATS data integrity problems. API-based migrations preserve those links at 3-5x the engineering cost. Middleware tools land in between. Your choice depends on database size, compliance requirements, and how much historical reporting you need intact.
The real cost of ATS migration technical debt surfaces months after go-live, when a recruiter searches for a candidate’s interview history and finds orphaned records, or when an OFCCP audit request exposes 2 years of missing disposition data. According to ATLAS’s published migration guidance, “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.”
Field mapping failures account for the bulk of post-migration problems. A typical ATS stores data across 6-12 interconnected object types: person records, applications, job requisitions, pipeline stages, scorecards, interview schedules, offer letters, and binary attachments like resumes and signed documents. When you move records between systems, every parent-child relationship between those objects needs an explicit mapping rule. Skip one, and you’ve got a candidate record that exists but shows zero application history.
Flat CSV Exports Seem Cheap Until You Count the Cleanup
Why does the simplest migration path create the most damage? Because a CSV file is a flat table. It has rows and columns with no concept of relationships between objects.
A standard ATS candidate record in a relational database, built on systems like SQL Server, PostgreSQL, or MySQL as Integrate’s data integrity overview explains, uses primary keys and foreign keys to connect a single person to multiple applications, each application to a specific job requisition, and each requisition to a sequence of pipeline stages. Export that structure to CSV, and you get one row per record with no linking keys. The parent-child relationships vanish.
Teams that migrate via flat CSV typically encounter 3 categories of failure:
- Duplicate person records. Without a unique immutable source key tying records together, the same candidate imported from 2 different CSV files (one from the candidate table, one from the application table) creates 2 separate profiles. Multiply that across a database of 50,000 candidates with an average of 2.3 applications each, and deduplication alone becomes a multi-week project.
- Orphaned attachments. Resumes, scorecards, and interview notes stored as binary files don’t travel inside a CSV. They require a separate download-and-reattach workflow. ClonePartner’s migration checklist is blunt: “A flat CSV export will break your recruiting data and create compliance exposure.”
- Broken pipeline analytics. Without stage-history timestamps preserved in the right relational format, your new ATS can’t calculate time-in-stage, conversion rates by source, or interviewer throughput. That reporting gap often stretches back 1-3 years of historical data.
The upside is speed. A CSV export-import cycle can be executed in 2-5 days rather than weeks, and it requires zero API engineering. For teams with fewer than 5,000 total records and no compliance obligations beyond basic record-keeping, this tradeoff sometimes makes sense.
API-Based Object Mapping Preserves Your Data Graph
API-level migration treats each ATS object type as a discrete entity with its own mapping rules. Person records migrate first. Applications follow, linked back to their parent person records via immutable source keys. Job requisitions, pipeline stages, scorecards, and attachments each get their own extraction-and-load sequence.
This approach directly addresses every failure mode from the CSV path. ATLAS’s guidance emphasizes that preserving the links between candidates, applications, jobs, and stage histories “requires object-by-object field mapping, separate binary attachment handling, and compliance retention audits completed before a single record moves.”
The tradeoffs are steep, though:
- Engineering cost. Building custom API connectors between 2 ATS platforms requires familiarity with both systems’ data models. Greenhouse exposes 15+ API endpoints for different object types. Lever has its own structure entirely. The stage-mapping matrix alone (translating every source pipeline stage, including deprecated ones, to a target equivalent) can take 40-80 hours of configuration work for a mid-size recruiting operation running 8-12 distinct pipelines.
- API rate limits. Every ATS vendor throttles API calls. Greenhouse’s rate limit sits at 10 requests per second. A database of 100,000 candidate records with associated applications, notes, and attachments can generate 400,000+ individual API calls. At throttled rates, extraction alone takes 11+ hours of continuous runtime, before you factor in retries for failed calls.
- Timeline. Plan for 4-8 weeks of active migration work for a database with 50,000-200,000 records. Larger databases with complex custom fields push that to 10-12 weeks.
When you’re comparing ATS platforms, understanding how their data models differ matters enormously. Our comparison of Greenhouse and Lever for mid-size teams covers workflow and feature differences, but the data architecture gap between them is what makes migration painful. And if you’ve approached your ATS implementation as a process design challenge, the pipeline architecture work you did during initial setup directly informs the stage-mapping matrix your migration requires.
Middleware Tools Split the Difference
Migration middleware platforms (ClonePartner, Truto, and a handful of others) sit between your source and target ATS and handle relational mapping through pre-built connectors. They maintain a translation layer that maps object types, field names, and pipeline stages without requiring your team to write custom API integration code.
The advantages over raw API migration show up in the execution timeline:
- Pre-built stage mapping. Middleware tools maintain libraries of field-mapping templates for common ATS-to-ATS combinations (Greenhouse to Lever, iCIMS to Workday, Bullhorn to modern cloud systems). The initial mapping configuration drops from 40-80 hours to roughly 10-20 hours.
- Binary attachment handling. Good middleware downloads resumes, scorecards, and documents from the source system and re-associates them to the correct candidate and application records in the target. ClonePartner’s guidance is specific here: “Serialize scorecards as structured notes attached to the application, preserving interviewer, date, attribute, and rating in a parseable format.”
- Compliance checkpoints. Built-in audit steps flag records that fall outside EEOC’s 1-year or OFCCP’s 2-year retention requirements before they transfer, reducing the risk of importing data you’re legally required to have already purged, or failing to import data you’re legally required to retain.
The downsides center on cost and control. Middleware vendors typically price by record volume, with rates ranging from $0.02-$0.10 per candidate record for databases above 25,000 records. A 150,000-record migration at $0.05 per record runs $7,500 in tooling fees alone. And you’re trusting the vendor’s mapping logic: custom fields, non-standard pipeline stages, and any proprietary data structures in your source ATS require manual configuration that the middleware won’t handle automatically.
Warning: Regardless of which path you choose, ATLAS emphasizes that “one of the most avoidable causes of migration failure is a lack of testing.” Run a parallel period where both old and new ATS operate simultaneously before decommissioning the source system.
How to Choose Between These Three
| Criteria | Flat CSV Export | API-Based Object Mapping | Middleware Migration Tool |
|---|---|---|---|
| Setup time | 2-5 days | 4-12 weeks | 2-4 weeks |
| Engineering skill required | Low (spreadsheet-level) | High (API development) | Medium (configuration) |
| Relational data preserved | No | Yes | Yes (with configuration) |
| Binary attachments handled | Manual reattach | Custom workflow needed | Usually included |
| Compliance audit trail | None built-in | Configurable | Pre-built checkpoints |
| Cost for 100K records | Staff time only | $15K-$40K+ in engineering hours | $5K-$10K tooling + staff time |
| Best for | < 5K records, no compliance needs | Large regulated employers | Mid-size teams, 25K-200K records |
Database size and regulatory exposure should make this decision for you.
If you’re a small team with under 5,000 candidate records, no federal contractor obligations, and limited need for historical reporting, a CSV migration with manual cleanup after the fact costs less than the alternatives and gets you running faster.
If you’re a federal contractor subject to OFCCP’s 2-year retention requirements, or you run more than 8 distinct hiring pipelines, or your database exceeds 50,000 records, the API or middleware path is the only way to maintain ATS data integrity through the transition. The field mapping failures from a flat export will create compliance exposure that costs far more to remediate than the migration itself.
The migration method you choose determines whether your recruiting data remains a connected graph of relationships or degrades into a pile of disconnected spreadsheet rows.
And if you’re somewhere in between, middleware gives you 80-90% of the relational data preservation of a full API migration at roughly 30-40% of the engineering cost. The tradeoff is that custom fields and unusual data structures will still require manual attention.
One piece of the migration that teams consistently underestimate: interview scheduling data. If your automated interview scheduling tool is integrated with your current ATS, those connections (calendar links, interviewer assignments, feedback forms) need their own mapping rules. They’re rarely included in standard migration templates and almost always require manual configuration regardless of which migration path you pick.
Whatever path you choose, the parallel-run period is non-negotiable. Run both systems simultaneously for at least 2 weeks. Have recruiters verify that candidate histories, pipeline stages, and attached documents are intact in the target system before you shut down the source. The teams that skip this step are the ones filing support tickets 3 months later when an audit surfaces gaps in their relational data in recruitment records that they could have caught during week one.
