Ashby has no automated Teamtailor connector. CSV import loses lifecycle data. API migration requires handling Ashby's HTTP 200 error trap and Teamtailor's 50-req/10s rate limit. Budget 2–4 weeks for DIY.
Ashby does not offer an automated migration connector for Teamtailor. Teamtailor is a career-site-first ATS with a JSON:API relational model, while Ashby is an analytics-first ATS with an RPC-style API where errors hide inside HTTP 200 responses. CSV import only transfers basic candidate profiles — losing all interview history, custom fields, notes, attachments, and application-to-job relationships. API-based migration is required for any meaningful historical data preservation. Every migration must handle Ashby's HTTP 200 error trap, Teamtailor's 50-request-per-10-second rate limit, and the fragmented write path where custom fields require separate API calls after record creation.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
This guide was written by ClonePartner, a migration service provider specializing in ATS,
This guide was written by ClonePartner, a migration service provider specializing in ATS, CRM, and help desk data migrations. Where ClonePartner's own service is mentioned, that relationship is disclosed.
Teamtailor activities (stage movements, emails sent, status changes) have no direct write
Teamtailor activities (stage movements, emails sent, status changes) have no direct write endpoint in Ashby's API. This data is either flattened into candidate notes or lost entirely. Plan for this gap before migration.
Ashby returns HTTP 200 for failed requests
Your migration script MUST parse the response body and check the success field on every single API call. Standard HTTP status code checks will miss errors entirely.
Ashby webhooks fire on API writes
Disable all active webhook subscriptions before loading migration data into a production workspace. Failure to do so can trigger HRIS syncs, Slack floods, and background check initiations on historical candidate records.
Ashby does not deduplicate on email
Re-running a migration script without crosswalk-based idempotency will create duplicate candidate records. Build deduplication into the script before the first run, not after discovering duplicates.
Do not attempt concurrent multi-threaded extraction from Teamtailor without strict token
Do not attempt concurrent multi-threaded extraction from Teamtailor without strict token bucket rate limiting. A naive concurrent script will trigger 429s and potentially result in a temporary IP ban.
Load order is strict
Departments → Locations → Jobs → Candidates → Applications → Custom Fields → Notes → Attachments. Each step depends on IDs generated by the previous step. You cannot attach an application to a job that does not exist.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Scope candidates, pipelines and the compliance obligations that come with them.
Objective Agreed scope across candidates, applications, jobs and interview history, with legal signed up on retention.
Keep these open
-
Inventory every object in Teamtailor
Count candidates, applications (a candidate can have many), jobs and requisitions, interviews, scorecards, offers, and resume files. Applications and scorecards usually outnumber candidates several times over, and resume files dominate storage.
Data Profiler Get real record counts instead of estimating from memory -
Settle retention and consent with legal
Candidate data is heavily regulated: GDPR right-to-erasure, EEOC/OFCCP record-keeping, and per-region retention windows that conflict with each other. Decide what may be migrated at all before you scope anything else — this frequently shrinks scope substantially.
Migrating candidate records whose consent has lapsed or whose retention window has expired creates a new compliance breach in the target system.
-
Map the hiring pipeline and agree the target stages
Document every job's pipeline, stage, and rejection reason, then agree the Ashby model with talent leadership. Stage definitions drive every funnel metric you report, so changing them silently rewrites your hiring analytics.
-
Catalogue integrations and the job-board estate
List job boards, careers-site integration, HRIS, background check, assessment platforms, calendar and email. The careers site and job boards are customer-facing, so their cutover needs its own plan and its own testing.
-
Build the business case and choose the window
Model licence delta, effort and recruiter productivity dip. Time the window against your hiring cycle: a migration during peak graduate recruitment or a hiring surge will fail on people, not technology.
Vendor Evaluator Score Ashby against alternatives on weighted criteria
Teamtailor → Ashby specifics
- Consolidated tooling
- Ashby replaces the ATS + scheduling tool + analytics dashboard stack with a single product. Teams running Teamtailor alongside separate interview scheduling and BI tools see immediate workflow simplification.
- Structured analytics
- Ashby's reporting engine is deeply integrated — pipeline velocity, pass-through rates, and interviewer calibration are native, not bolted on.
- Scalable interview operations
- Ashby's structured interview plans with feedback forms and scorecards enforce evaluation consistency in ways Teamtailor's more flexible interview kit approach does not.
- Interview plans and stage configurations
- Ashby's structured interview framework must be configured per-job. This is process design, not data migration.
- Back up everything before you start
- Export a full CSV from Teamtailor as a baseline reference, even if you're doing an API migration.
Don't move on until
- Counts confirmed for candidates, applications, jobs and offers
- Retention and consent obligations confirmed with legal
- Hiring-stage model agreed with talent leadership
02 Data Audit Audit candidate data with compliance sitting next to you.
Objective Profiled exports with duplicates, expired records and resume files all quantified and triaged.
Keep these open
-
Export and profile candidates, applications and jobs
Profile each object separately and reconcile against API counts. Watch the candidate-to-application ratio: a mismatch usually means applications have been silently truncated by pagination.
Data Profiler Profile the Teamtailor export for nulls, outliers and type drift -
Quantify duplicate candidates and agree survivorship
The same person applies repeatedly over years with different emails and name spellings. Measure the duplicate rate and agree survivorship rules — which record wins and what happens to the application history attached to the losers.
Merging candidates without agreed survivorship rules destroys application and interview history that you may be legally required to retain.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Identify records outside their retention window
Flag candidates whose consent has expired, who have exercised erasure, or who fall outside regional retention. Exclude them from scope and document the exclusion — you need to show the decision was deliberate.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Inventory resume files and attachments
Count files, total volume and MIME types, and check every attachment still resolves to a live URL. Expiring signed download URLs are the classic reason a resume migration completes with a large fraction of empty files.
Resume download URLs are often short-lived signed links. Fetch files close to load time or they will 404 mid-migration.
-
Verify relationship integrity
Confirm every application links to a live candidate and a live job, and every scorecard to a real interview. Orphaned applications produce a funnel report that does not tie to anything.
-
Clean, normalise and produce masked test data
Normalise emails, phone formats and locations, standardise timestamps to UTC, and generate a masked dataset for the sandbox. Real candidate data in a sandbox is a compliance breach in most jurisdictions.
PII Masker Generate a safe copy for sandbox and vendor testing -
Preserve source IDs
Store Teamtailor record IDs as a custom field or tag in Ashby. This makes post-migration debugging and audit dramatically easier.
Teamtailor → Ashby specifics
- Data cleanup
- Deduplicate candidates on email, normalize email formats, strip invalid phone numbers
- Log every API call and response
- When (not if) something fails, you need a complete audit trail to identify which records were affected.
Don't move on until
- Duplicate candidate rate quantified with a merge policy agreed
- Records outside retention identified and excluded
- Resume and attachment inventory complete with total volume
03 Field Mapping Map the candidate-application-job triangle before anything else.
Objective A signed mapping covering objects, stages, rejection reasons, scorecards and EEO fields.
Keep these open
-
Map the candidate, application and job model
ATS platforms differ on whether a person or an application is the primary record. Establish this first: getting it wrong means one candidate becomes five, or five applications collapse into one, and the entire field map has to be redone.
Candidate-centric and application-centric models are not interchangeable. Confirm which Ashby uses before mapping any field.
Schema Mapper Opens pre-loaded with the Teamtailor → Ashby field pair -
Map pipeline stages and rejection reasons exhaustively
Enumerate every stage and rejection reason across all jobs, including retired values on historical applications, and map each explicitly. Unmapped rejection reasons are both a reporting gap and, in regulated hiring, a compliance one.
-
Decide EEO and diversity data handling
These fields are separately regulated and often legally required to be stored apart from the candidate record. Confirm with legal whether they migrate at all, and how Ashby isolates them.
EEO data usually cannot be migrated into ordinary custom fields without breaching the segregation rules that govern it.
-
Map interviews, scorecards and feedback
Structured scorecards rarely have a native equivalent. Decide whether to reconstruct them, flatten them into notes, or keep them only in the archive — and be explicit that flattening loses the ability to report on them.
JSON to CSV Converter Flatten nested API responses into a reviewable sheet -
Plan resume and file migration
Confirm size limits, MIME support and whether Ashby re-parses resumes on upload. Re-parsing can overwrite carefully curated candidate fields with worse machine-extracted values, so test it deliberately.
-
Set load order and freeze the spec
Users, then jobs, then candidates, then applications, then interviews and scorecards, then files. Keep source IDs in custom fields, then version and sign off the spec.
Teamtailor → Ashby specifics
- Field mapping
- Teamtailor's first-name + last-name → Ashby's single name field
- Custom field translation
- Match Teamtailor custom field IDs to pre-created Ashby custom field IDs
- Relationship reconstruction
- Build a lookup table of Teamtailor job IDs → Ashby job IDs (after jobs are created)
- Attachment handling
- Download resume files from Teamtailor URLs and prepare for Ashby upload
- Source ID preservation
- Store Teamtailor record IDs in your crosswalk table for post-migration debugging
Don't move on until
- Candidate/application/job model mapped and reviewed
- Every stage and rejection reason explicitly mapped
- EEO and diversity field handling agreed with legal
04 Test Migration Pilot whole candidate journeys, not isolated records.
Objective A sandbox pilot where candidate journeys, funnel metrics and resume files all verify.
Keep these open
-
Configure the Ashby sandbox with the agreed pipelines
Create jobs, pipeline stages, scorecard templates, user roles and custom fields first. Loading applications before the stages exist puts every candidate in a default stage and invalidates the pilot.
-
Select complete candidate journeys as the pilot slice
Take 100-200 candidates with all their applications, interviews, scorecards and files — including repeat applicants, hires, rejections at every stage, and candidates on multiple jobs. Repeat applicants are where the model mapping actually gets tested.
-
Run the load in dependency order with logging
Jobs, candidates, applications, interviews, then files, logging each request against its source ID. Track file uploads separately: they fail for different reasons and at different rates than record writes.
-
Verify journeys and funnel metrics
Confirm each candidate sits at the right stage on the right job with their history intact, and that per-stage funnel counts match Teamtailor for the pilot jobs. Funnel mismatches point straight back to stage mapping.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Open every pilot resume and check re-parsing
Actually open the files rather than trusting the upload count, and check whether re-parsing has overwritten any candidate fields. A resume that uploaded as a zero-byte file still counts as a success in most logs.
-
Put recruiters in front of the pilot data
Have recruiters work their own pilot requisitions end to end. They immediately spot missing feedback, wrong stages and unreadable history that reconciliation cannot see.
-
Run a test migration first
Load 50–100 candidates into a test Ashby workspace. Validate every object type before running the full migration.
Don't move on until
- Candidate-application-job relationships intact for the pilot
- Funnel counts per stage match source for pilot jobs
- Resume files open correctly for every pilot candidate
05 Cutover Switch recruiting without dropping a live candidate.
Objective All in-scope recruiting data live in Ashby, careers site and boards repointed, recruiters working.
Keep these open
-
Pre-load historical candidates and closed jobs
Load closed requisitions, rejected candidates and archived applications while Teamtailor stays live. Only active pipeline and the final delta need to move in the window.
-
Publish the runbook including the careers-site switch
A timed sequence with owners and abort criteria, treating the careers site and job boards as first-class steps. They are candidate-facing, so a failure there is publicly visible in a way a data defect is not.
-
Freeze Teamtailor and take the final delta
Stop new applications and let recruiters finish in-flight actions, then export everything changed since the pre-load. Coordinate with anyone actively interviewing so feedback is not entered into the old system mid-freeze.
Interview feedback entered in the old ATS during the freeze is lost, and it is the data recruiters most immediately notice missing.
-
Load active pipeline and reconcile stages
Load active candidates and applications, then verify every active candidate is at the correct stage on the correct job before repointing anything. Active-stage accuracy is what recruiters check first on day one.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint careers site, job boards and integrations
Switch the careers-site integration, repost or migrate live job ads, and repoint HRIS, background check, assessment and calendar integrations. Then submit a real test application through the careers site and every major board.
Job ads left posted against the old ATS keep collecting applications that never reach the new system.
-
Go/no-go and switch recruiters over
Call the decision against the exit criteria, then move recruiters with support on hand for the first day. Keep Teamtailor read-only — candidate records have retention obligations that outlast the migration.
-
Freeze Teamtailor during cutover
Coordinate with your recruiting team to stop creating new candidates in Teamtailor 24 hours before the final migration run. Records created during migration will be missed.
-
Keep Teamtailor readable after cutover
Don't decommission Teamtailor immediately. Maintain read access until your team has fully validated the migration and signed off. Rollback means switching the system of engagement back, not reconstructing history from memory.
Don't move on until
- Historical load complete and reconciled before the freeze
- Careers site and job boards posting into Ashby and verified
- Active candidates confirmed at the correct stage
06 Validation Prove the funnel, the files and the compliance position.
Objective Reconciled recruiting data, funnel parity with baseline, and a defensible compliance record.
Keep these open
-
Reconcile every object including files
Compare counts for candidates, applications, jobs, interviews, scorecards and files, with field-level spot checks on a sample. Count files separately — they are the object most likely to be quietly short.
Migration Validation Tool Reconcile Teamtailor and Ashby record-for-record -
Tie funnel and time-to-hire reporting to baseline
Rebuild funnel conversion, time-to-hire, source effectiveness and offer-acceptance reporting and compare to pre-migration figures. Variances trace back to stage mapping and to how application timestamps were handled.
Time-to-hire depends on stage-transition timestamps. If those were approximated, the metric will differ even with identical records.
-
Verify file integrity at scale
Sample-open resumes across the whole load and compare file sizes against source. Zero-byte and truncated files are common and never surface in an upload success count.
-
Confirm retention, consent and EEO configuration
Verify retention rules, consent state and EEO segregation are correctly configured in Ashby, and that excluded records genuinely did not migrate. File this as your compliance evidence.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Test workflow, notifications and candidate-facing paths
Fire every stage automation, interview scheduling flow, rejection template and offer approval, and submit a live application through the careers site. Candidate-facing emails going out wrong is a brand problem, not just a bug.
-
Sign off and schedule decommission
Get written acceptance against the Discovery criteria, retain Teamtailor read-only for the period your retention policy requires, take a final archive export, and diarise cancellation.
-
Validate incrementally
Don't wait until the end to check counts. Validate after each object type is loaded.
Teamtailor → Ashby specifics
- Email templates and automation triggers
- Teamtailor's triggers (move-to-stage actions, automated emails) don't transfer. Rebuild in Ashby's workflow system.
- Career site
- If you used Teamtailor's career site builder, plan to rebuild on Ashby's hosted career page or use their API for a custom page.
- Integrations
- Reconnect scheduling tools, HRIS systems, assessment partners, and sourcing extensions.
- User permissions and roles
- Recreate team structures and access controls in Ashby's admin panel.
- Reporting views
- Configure Ashby's analytics dashboards for your team's KPIs.
Don't move on until
- Reconciliation complete across candidates, applications and files
- Funnel and time-to-hire reporting tie to baseline
- Retention and EEO configuration verified, acceptance signed
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
Object Equivalent
| Teamtailor field | Ashby field | Notes |
|---|---|---|
| Candidate | Candidate | Core profile fields map 1:1. Keep source_candidate_id for audit. |
| Job | Job | Title, team, location. Rebuild interview plans manually. |
| Job Application | Application | Link candidate to job. Stage mapping requires translation. |
| Stage | Interview Stage | Teamtailor stages are flexible per-job; Ashby stages are tied to interview plans. |
| Custom Field Value | Custom Field (via customFields.setValue) | Must pre-create matching fields in Ashby. Separate API call per field. |
| Note / Comment (candidate-level) | Candidate Note | Free-text migration. Preserve timestamps via createdAt. |
| Note / Comment (job-level) | Candidate Note or Application history | Ashby's historical import converts job-level feedback to notes. Decide your target model up front. |
| Activity | No direct equivalent | Flatten to notes or discard. Ashby auto-generates its own activity log. |
| Upload / Attachment | Candidate File | Download from Teamtailor, re-upload via Ashby's file.createFileUploadHandle endpoint. |
| Answer (to question) | Custom Field or Note | Map structured answers to custom fields; free-text to notes. |
| Scorecard / Interview Kit Feedback | Interview Feedback | Lossy — Teamtailor's skill/trait scoring doesn't map 1:1 to Ashby's feedback forms. |
| Department | Department | Recreate in Ashby admin before import. |
| Location | Location | Recreate in Ashby admin before import. |
| Tag | Candidate Tag | Create tags in Ashby first, then apply via API. |
| Connect / Talent Pool membership | Candidate (profile only) | No application context. Notes and tags must be migrated separately. |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Candidate Profiles | low | Core fields (name, email, phone, LinkedIn) map directly between platforms |
| Job Applications | high | Require separate API call to link candidate to job; orphaned records without it |
| Custom Field Values | high | Each field requires a dedicated customFields.setValue call after record creation |
| Interview Feedback/Scorecards | high | Teamtailor's skill/trait scoring doesn't map to Ashby's structured feedback forms |
| Activity Log | high | No write endpoint in Ashby; historical activities are lost or flattened to notes |
| Notes and Comments | medium | Candidate-level notes map directly; job-level comments are flattened to generic notes |
| Attachments/Resumes | medium | Teamtailor URLs may be temporary; files must be downloaded and re-uploaded to Ashby |
| Pipeline Stage History | medium | Ashby supports partial history reconstruction but not full stage-progression fidelity |
| Tags | low | Must be pre-created in Ashby then applied via API |
| Deactivated User Assignments | medium | Cannot assign deactivated users as interview owners; must map to a legacy user |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
HTTP 200 Error Trap
Ashby returns HTTP 200 with success:false for application errors; standard status code checks silently miss failures.
Fragmented Write Path
Custom field values require separate customFields.setValue calls after record creation, doubling API call count per candidate.
Rate Limit Orchestration
Teamtailor caps at 50 requests per 10 seconds while Ashby caps at 1,000 per minute — both constrain migration throughput.
Activity Data Loss
Teamtailor activities (stage movements, emails) have no write endpoint in Ashby and must be flattened to notes or lost.
Stage Mapping Ambiguity
Teamtailor's flexible per-job stages don't map 1:1 to Ashby's structured interview plans tied to specific feedback forms.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can I migrate from Teamtailor to Ashby using CSV files?
Yes, but with severe limitations. Ashby's self-serve CSV import only supports basic candidate profiles — name, email, phone, LinkedIn. You lose all interview history, custom field values, notes, attachments, pipeline stage data, and application-to-job relationships. It's suitable for small teams that don't need historical hiring data.
Does Ashby support a native migration from Teamtailor?
Ashby's automated API migration connectors support Greenhouse, Workday, and some Lever migrations — not Teamtailor. Ashby does list Teamtailor on its file-based historical import route, which can import candidates, applications, optional jobs, and feedback as notes, but it does not import job postings, interview plans, or openings.
What are the API rate limits for Ashby and Teamtailor?
Ashby enforces 1,000 requests per minute per API key (15/min for report endpoints). Teamtailor allows 50 requests per 10 seconds and recommends a 300ms delay between requests. Since migrating one candidate with applications, custom fields, and notes requires 8+ API calls, a 10,000-candidate migration takes roughly 80+ minutes at maximum throughput.
Why does Ashby return HTTP 200 for API errors?
Ashby's API uses an RPC-style architecture where application-level errors return HTTP 200 with a 'success: false' flag and an errorInfo object in the response body. Standard HTTP status code checks will miss these errors entirely. Migration scripts must parse the response body and check the success field on every call.
How long does a Teamtailor to Ashby migration take?
A CSV-only migration can be done in a day but loses most data. Ashby's file-based historical import takes days with Ashby's involvement. A custom API-based migration takes 2–4 weeks of engineering effort including scripting, testing, and validation. A managed migration service typically completes the full transfer in days, including validation.