ATS data migration guide: import jobs, candidates, and notes safely

Switching ATS platforms means moving the recruiting system your team relies on to remember who applied, who interviewed, what was decided and why. A CSV upload may be part of that work, but it is rarely the whole migration.

Recruiting data is connected. Candidates attach to jobs, applications, pipeline stages, notes, resumes, sources, users, scorecards, offers, rejection reasons and compliance records. If one layer is mapped badly, the new ATS may look full while the hiring history is hard to trust.

This ATS data migration guide focuses on safe execution: what to move, what to archive, how to map jobs and stages, and how to test before cutover. Breezy HR, Workable and Greenhouse are useful examples because their import models behave differently.

What ATS data should you migrate?

Start with a data inventory, not the import template. The template only tells you what the new system accepts; it does not tell you which data is worth carrying forward.

Inventory jobs or requisitions, candidates, applications, stages, statuses, notes, comments, interview feedback, scorecards, resumes, attachments, offers, sources, users, custom fields, consent records and retention data. Include old ATS IDs where possible, because they help with matching and audit checks later.

The upside of a broad inventory is control. The downside is that it exposes messy data: duplicate candidates, abandoned jobs, stale talent pools and custom fields nobody owns. That is useful pain, because migration is the best moment to clean the record.

For each data object, write down the business reason to migrate it. Active candidates need to move because hiring is live; rejected candidate records may need to stay available for compliance; ten-year-old resumes may be better kept in a secure archive or deleted under policy.

What should you migrate versus archive?

Migrate data your team will use in the new ATS. Archive data you may need to reference but do not want polluting active hiring workflows.

A sensible default scope includes active pipelines, candidates likely to be re-engaged, recently closed requisitions, hired and rejected records needed for compliance, and audit history required by policy. This keeps the new ATS useful without turning it into a dumping ground.

Archive stale talent pools, obsolete jobs, duplicate resumes, unsupported files, abandoned custom fields and records outside retention windows. The catch is that the archive still needs ownership, access controls and a retention period.

Do not import everything because export was available. Old data can make search noisier, create duplicate profiles and make reporting harder to read. Greenhouse explicitly warns that historical data can be useful for reference, but limitations may prevent effective reporting.

Why should you map jobs before candidates?

Map jobs first because most candidate imports need a destination. That destination may be a live job, position pipeline, archived job, historical job or container record.

In Breezy HR, Hiring Managers and Admins can bulk import candidates into a specific position pipeline using CSV or batch resume upload. That is straightforward for small teams, but Breezy’s self-serve CSV candidate import is limited to four fields: Name, Email, Phone and Summary.

Breezy HR says teams migrating from another ATS should contact sales for a more comprehensive import, with customised migration solutions available for Pro-plan customers. That is helpful if your migration is bigger than a candidate list, but it also means you should confirm scope before signing.

Workable behaves differently. In its spreadsheet import path, unique job titles associated with candidates are imported as newly created archived jobs, with no job data except the title. It also cannot import into Published jobs or Talent Pool through that path.

If the Job field is blank in Workable, candidates go into an archived “Import Job.” This is tidy for old data, but risky if you expected imported candidates to land in live requisitions.

Greenhouse is stricter. Every job listed in the spreadsheet must be mapped to an Open job in Greenhouse Recruiting, and candidates linked to unmapped jobs are not imported. Closed and Draft jobs do not appear for mapping.

Create a job crosswalk before import. Include old job ID, old title, new job ID, new title, status, department, location, hiring manager and whether the destination should be live, archived or historical-only.

How do you map stages, statuses and historical outcomes?

Treat stages as a translation project. Stage names are rarely portable between ATS platforms, even when two systems both use familiar labels such as Applied, Screen and Offer.

Workable requires imported stage names to exactly match stages in the first enabled recruiting pipeline. If the stage is blank or does not match exactly, candidates are placed in the Qualified tab of the Applied stage.

That fallback is safe because candidates are still imported. The downside is operational: recruiters may have to sort misplaced candidates manually before they can trust the pipeline.

Greenhouse bulk import uses a Milestone field limited to Application, Assessment, Face to Face and Offer. If no milestone is added, the candidate is added to the first stage of the selected job.

Greenhouse also has a separate historical candidate import path for first-time migrations. It can set application status, map to interview stage, add rejection reason, and include application, rejection and hired dates. Dates must use YYYY-MM-DD format.

The safer pattern is to map old stages into a smaller set of destination stages. Preserve granular old-stage detail in a custom field or note if it matters for reference, but avoid treating every historical stage as current pipeline truth.

How should you preserve notes and interview context?

Notes matter because they explain the decision, not just the status. They hold recruiter judgement, hiring-manager context, interview feedback, source history and re-engagement clues.

Workable gives a clear example. Its import template includes a Comment column; comments appear on the candidate timeline, are visible to the hiring team, are invisible to candidates, and are attributed to the first listed Admin user.

That is useful for preserving context. The limitation is attribution: if historic comments all appear under one Admin, you may lose the original author trail unless you include author and date inside the comment text.

Some migrations collapse multiple notes into one comment, convert structured scorecards into plain text, or lose activity history. Do not assume notes, scorecards, offer notes and compliance fields will import cleanly through the same route.

Split notes before import. Use separate categories for recruiter screen notes, interview feedback, scorecards, offer notes, compliance-sensitive notes and general activity logs.

This is also the moment to remove bad notes. Inappropriate, irrelevant or retention-expired comments should be excluded before migration, not copied into a cleaner new system.

What can go wrong with resumes and attachments?

Resumes often fail separately from candidate rows. File type, file size, parseability and email matching rules vary by ATS, so a successful candidate import does not prove the CVs attached correctly.

Breezy HR bulk resume upload supports up to 50 MB at a time, with text-based formats including DOCX, TXT, RTF, ODT and PDF. Breezy says scanned image resumes are not suitable for parsing.

Breezy HR CSV imports support files up to 10 MB at a time and up to 90,000 candidates for a single position. The scale is useful, but the CSV fields are narrow, so it should not be treated as a full historical migration.

Workable supports resume files in .doc, .docx, .pdf, .rtf, .html and .odt formats through its spreadsheet import flow. For bulk resume upload, Workable recommends up to 100 resumes at a time; teams with thousands should arrange a data import.

Workable says a candidate data import may take up to 5 business days after it receives the file or accessible link. That is predictable, but it needs to be built into the cutover plan.

Greenhouse supports a single resume ZIP up to 5 GB, including subfolders, during bulk import. Attachment can still fail if the resume cannot be parsed, lacks an email address, or the email does not match a candidate in the import.

Run a resume preflight before cutover. Remove corrupt files, convert scanned documents where possible, check filenames or links against import rows, and sample-test parsing with real candidates.

How do you handle duplicates and existing candidates?

Define duplicate rules before import. Old ATS IDs may not exist in the new system, so the matching logic can change at the point where mistakes are hardest to unwind.

Use a hierarchy. Start with exact email match, then phone match, LinkedIn URL match, old ATS candidate ID, and a manual review queue for uncertain cases.

Greenhouse auto-merge compares imported candidates against existing candidate data using configured criteria, such as same email or phone plus LinkedIn URL. Referral or agency-sourced candidates are not auto-merged.

Auto-merge can reduce duplicate cleanup. The catch is that it depends on the data you already hold and the rules you configure, so test it on real samples before a production import.

Breezy HR’s API can create a candidate on a specific position and returns a 409 response if the candidate already exists on that position. That can help developers catch duplicates in scripted imports, but it does not replace a business-level dedupe policy.

What compliance and retention checks matter during migration?

ATS migration is a compliance event because personal data is copied into a new processor and system of record. Treat it as operational risk management, and involve legal or compliance owners where required.

Review GDPR and CCPA workflows, candidate consent, EEOC or OFCCP fields where applicable, deletion requests, retention windows and access permissions. The upside is that migration can fix old process gaps; the downside is that it can also copy them forward at scale.

Check whether retention and deletion automation should be paused during import, then re-enabled after validation. If automation runs during a messy import, records may be deleted or anonymised before the team has checked them.

Confirm user access before moving sensitive notes or compliance fields. A new ATS often changes permission groups, and migrated history should not become visible to people who could not see it before.

How should you run the test import and cutover?

Run a representative test import, not a clean toy sample. The test should include the awkward records that will break the real migration.

Include an active candidate, rejected candidate, hired candidate, duplicate candidate, candidate with notes, candidate with resume, candidate with missing email, candidate with custom fields, candidate with source data and candidate with historical application dates.

After import, validate counts for candidates, jobs, applications, notes, comments, resumes, attachments, stages, sources, users and custom fields. Then spot-check search and reporting, because rows appearing in the system is only the first test.

Plan a freeze date for final cleanup and export. Pull a full export from the old ATS, including attachments where supported, then run the final import during an agreed blackout window if one is needed.

Reconnect integrations after the import, not before. Job boards, calendars, email sync, HRIS feeds and background-check tools can create new records while you are still trying to validate migrated ones.

What changes for job boards and source tracking?

Migration often coincides with rebuilding job distribution, paid campaigns, source tracking and billing ownership. These pieces rarely move as neatly as candidate records.

Breezy HR supports promotion through a career portal, free job boards and premium job boards, with premium promotions purchased from the Advertise tab. That is useful for small teams, but campaign setup still needs to be recreated with the right owners and budgets.

Workable integrates with 200+ free and paid job boards. Paid board prices are negotiated monthly and subject to change without prior notice, so do not assume old campaign costs will match the new setup.

Greenhouse Job Ad Market lets organisations buy individual job ads from thousands of third-party boards inside Greenhouse Recruiting. The limitation is strict: purchased ads cannot be edited or refunded, may take up to 10 business days to publish, and ad cost data cannot be pulled into reports.

Document live campaigns, budget caps, billing entities, source tags, UTM conventions and campaign owners before cutover. Also document which source and cost data will not migrate cleanly.

Which ATS migration model fits Breezy HR, Workable and Greenhouse?

Among these featured tools, ATSLab ranks Breezy HR highest, then Workable, then Greenhouse. That ranking does not mean their migration models are interchangeable.

Breezy HR is the better fit if you are a startup or small business that wants a capable ATS without per-seat fees, and your migration is mainly candidates and resumes into position pipelines. Its recorded price is $157, but broader migration support should be confirmed with sales for Pro-plan use cases.

Workable is a strong fit if you want documented spreadsheet imports, clear comment handling and predictable archived-job behaviour. Its recorded price is $299, but its spreadsheet path has sharp limits around Published jobs, Talent Pool and exact stage matching.

Greenhouse is the strongest example here for structured enterprise migration. It handles Open-job mapping, historical candidate imports, date formats, duplicate rules and reporting cautions in more detail, but ATSLab records it from about $6k and Greenhouse uses custom quotes on Core, Plus and Pro plans.

Choose partly by migration shape. Breezy HR suits simpler small-team moves, Workable suits spreadsheet-led imports with clear archived history, and Greenhouse suits structured migrations where governance matters more than speed.

ATS migration checklist

Set a freeze date for cleanup, export and change control. Tell recruiters what should stop in the old ATS, and when.

Export the old ATS fully, including jobs, candidates, applications, notes, files, resumes, sources, users, stages, custom fields and compliance data where available. Store the raw export securely before editing working copies.

Create crosswalks for jobs, stages, users, sources, rejection reasons, custom fields and historical statuses. This is the part that protects the migration from becoming a loose spreadsheet upload.

Clean the data before import. Deduplicate records, remove stale profiles, normalise emails and phone numbers, remove unsupported files, and exclude records outside retention policy.

Prepare vendor templates carefully. Validate required fields, split large imports according to vendor limits, and check date formats before sending files or running the upload.

Test with edge cases, compare counts, then inspect real candidate profiles. Validate notes, resumes, stage placement, job mapping, duplicate behaviour, search and reports.

Cut over only after the test is signed off. Pause old workflows, run the final export and import, reconnect integrations, rebuild job-board distribution, and keep the old export as a secure archive under agreed retention rules.

Safe ATS migration depends more on mapping and validation than on the import button. Pick the ATS that fits your hiring workflow, but also check that its import model fits the history you need to carry forward.