Workable to Teamtailor migration requires API-based extraction (10 req/10s), multi-request loading per candidate due to Teamtailor's relational model (50 req/10s), and temporary public hosting for resumes. CSV exports lose most data.
There is no native migration path from Workable to Teamtailor. Workable treats candidates as flat records attached to job pipelines with one profile per job. Teamtailor uses a relational JSON:API model where Candidates, Job Applications, Custom Field Values, and Answers are all separate entities requiring multiple sequential API requests. The fundamental gap is architectural complexity: importing a single candidate with custom fields into Teamtailor requires 6+ API calls (candidate + custom-field-values + answers + job-application), and resumes must be temporarily hosted at a public URL for Teamtailor to fetch within 30 seconds. Every migration must navigate Workable's 10 req/10s extraction limit, Teamtailor's 50 req/10s load limit, the mandatory X-Api-Version header, and the resume temporary hosting requirement that adds infrastructure complexity.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Do not plan this as row-to-row mapping
A row in Workable is often an application-context record, while a record in Teamtailor is a person record plus one or more application-context relations. The real translation is Workable job-candidate profile → Teamtailor candidate + job application + notes/custom-field-values/answers. Resumes widen the gap further: Workable's candidate details CSV excludes them, while Teamtailor's API expects relational follow-up requests for everything beyond the base candidate record.
CRM-style objects don't have first-class equivalents here
If your Workable account stores agency accounts, client references, or company data, these are usually custom fields or adjacent system data — not native recruiting objects. In Teamtailor, keep them as candidate/job custom fields, agency references, tags, or external-system IDs rather than forcing them into objects that don't exist. (support.teamtailor.com)
Teamtailor requires first-name and last-name as separate attributes
Workable stores a single name field. Your transform layer must split this reliably — watch for edge cases like compound last names ("María del Carmen García"), hyphenated names ("Jean-Pierre"), single-name candidates, and empty name fields.
Non-resume attachments (extra files, offer letters, work samples) are not centered in
Non-resume attachments (extra files, offer letters, work samples) are not centered in Teamtailor's import flow. Plan a fallback — linked external storage, notes with URLs, or curated historical summaries — for any files that aren't standard resumes.
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 Workable
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 Teamtailor 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 Teamtailor against alternatives on weighted criteria -
Record count comparison
Total candidates, jobs, and job applications in Workable vs. Teamtailor. If counts don't match, investigate before proceeding.
Workable → Teamtailor specifics
- Employer branding
- Teamtailor's career site builder is significantly stronger than Workable's, which matters for companies that treat their careers page as a marketing channel.
- Pricing structure
- Teamtailor's per-seat pricing can be more favorable for companies with large hiring teams but moderate job volumes. Teamtailor uses quote-based pricing, so a cost comparison needs a real model rather than guesswork.
- Agency/RPO use cases
- Staffing firms and RPOs that need white-label career pages often prefer Teamtailor's multi-brand architecture.
- Simplicity
- Teams that found Workable's feature set overbuilt for their hiring workflow migrate to Teamtailor's more streamlined interface.
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 Workable 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
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 Teamtailor uses before mapping any field.
Schema Mapper Opens pre-loaded with the Workable → Teamtailor 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 Teamtailor 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 Teamtailor 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.
-
Create the Custom Field definitions
in Teamtailor (via UI or API at /v1/custom-fields)
-
Create Custom Field Options
for any select/dropdown fields (/v1/custom-field-options)
Workable → Teamtailor specifics
- POST Custom Field Values
- per candidate (/v1/custom-field-values), linking to both the candidate ID and the custom field ID
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 Teamtailor 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 Workable 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.
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 Teamtailor, 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 Workable 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 Workable 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 Workable read-only — candidate records have retention obligations that outlast the migration.
Workable → Teamtailor specifics
- Field-level spot check
- Pull 50+ random candidate records and verify every mapped field value. Pay special attention to custom fields and phone number formatting.
- Relationship integrity
- Verify that job applications correctly link candidates to jobs. Check 20+ records across different jobs. Confirm that one person with multiple applications behaves correctly.
- Duplicate check
- Search for duplicate candidate entries using email address as the primary key.
Don't move on until
- Historical load complete and reconciled before the freeze
- Careers site and job boards posting into Teamtailor 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 Workable and Teamtailor 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 Teamtailor, 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 Workable read-only for the period your retention policy requires, take a final archive export, and diarise cancellation.
-
Rebuild pipelines
Teamtailor's stage configuration likely differs from Workable's. Reconfigure your hiring workflow stages.
-
Rebuild automations
Any Workable auto-actions (auto-reject, auto-advance, email templates) need to be recreated in Teamtailor's trigger system.
-
Monitor for 2 weeks
Watch for data inconsistencies, missing records, and broken candidate-job links that surface during daily use.
Workable → Teamtailor specifics
- Resume verification
- Confirm resume files are accessible on candidate profiles — not just linked, but actually downloadable.
- Reconnect integrations
- HRIS connections, background check providers, assessment tools, and job board integrations must be reconfigured.
- User training
- Teamtailor's UX is fundamentally different from Workable's. In Teamtailor, some data is candidate-wide and some is job-specific. Budget 1–2 sessions per hiring team.
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 Object
| Workable field | Teamtailor field | Notes |
|---|---|---|
| Candidate | Candidate | Core profile: name, email, phone, LinkedIn, resume. |
| Job | Job | Title, description, department, location. Imported as Archived by default with an import tag. |
| Candidate-in-Job (pipeline position) | Job Application | The join record linking Candidate to Job with stage info. |
| Pipeline Stage | Stage | Teamtailor has stage types (Inbox, InProcess, Hired, Rejected). Custom stage names map to these types. |
| Evaluations / Scorecards | Notes (Comments) | Teamtailor has no native scorecard equivalent. Evaluations must be serialized into note text. |
| Custom Fields | Custom Field Values | Each value is a separate relational object. Requires pre-creating the Custom Field definition. |
| Application Questions & Answers | Answers (linked to Questions) | Questions and answers contain data about what questions the candidate has answered and what answers were provided. Both of these exist as individual objects outside of the candidate. |
| Tags | Tags | Direct mapping. Normalize whitespace and case. |
| Comments | Notes | Notes (Comments) require a user and a candidate. If exact author mapping isn't possible, store the original author and timestamp inside the note body. |
| Candidate Resume (file) | Upload (linked to Candidate) | Must be staged at a temporary public URL for API-based import. |
| Departments | Departments | Direct mapping. |
| Offer data | No direct equivalent | Offer details need to be stored as notes or custom fields. |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Evaluations/Scorecards | high | Teamtailor has no native scorecard equivalent; must serialize into note text format |
| Pipeline Stage History | high | Only current stage is easily mapped; stage change timeline is lost |
| Email Correspondence | high | Workable email thread data is not accessible via standard API |
| Resumes/Attachments | medium | Excluded from CSV export; requires API extraction and temporary public hosting for load |
| Custom Fields | medium | Each value requires a separate API call with pre-created definitions and options |
| Offer Details | medium | No native offer object in Teamtailor's public API for import |
| Source Tracking | medium | Original candidate source may not map to Teamtailor's source taxonomy |
| Candidate Creation Dates | low | Preserved via API but lost in standard CSV import |
| Tags | low | Direct mapping with whitespace and case normalization |
| Notes/Comments | low | Map to Teamtailor notes with author and timestamp metadata in body |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Resume Temporary Hosting
Teamtailor requires resumes at a publicly accessible URL for up to 30 seconds. Migration scripts must upload to temporary storage (S3 pre-signed URLs) then orchestrate timing.
Multi-Request Loading
Each candidate with custom fields requires 6+ sequential API calls due to Teamtailor's relational model. Effective throughput is ~8 full records per 10-second window.
Dual Rate Limits
Workable extraction at 10 req/10s and Teamtailor loading at 50 req/10s are independent constraints requiring separate throttling in the pipeline.
Name Splitting Edge Cases
Workable stores a single name field; Teamtailor requires separate first-name and last-name. Compound names, hyphenated names, and single-name candidates break naive splitting.
Custom Field Dependencies
Custom field definitions and options must exist before values can be POSTed. Deleting a field during migration removes values for every candidate platform-wide.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can I export resumes from Workable via CSV?
No. Workable's Candidate Details CSV report does not include resume files. You must use the /candidates/:id API endpoint to download resumes individually, or request a full account data export from Workable support (which requires archiving all active jobs first).
What are the Workable and Teamtailor API rate limits?
Workable account tokens are limited to 10 requests per 10 seconds. Teamtailor allows 50 requests per 10 seconds. Exceeding either limit returns HTTP 429. A 300ms delay between Teamtailor requests is recommended, but each candidate with custom fields requires multiple API calls, so effective per-candidate throughput is much lower than the raw limit suggests.
How long does a Workable to Teamtailor migration take?
It depends on volume and method. A standard CSV import through Teamtailor takes 2-3 weeks. A custom API-based migration for 10,000+ candidates typically takes 2-6 weeks of engineering time in-house, or can be completed in days with a managed service like ClonePartner.
What is the X-Api-Version header in the Teamtailor API?
All Teamtailor API requests require an X-Api-Version header (currently 20240904). Omitting it is one of the most common causes of failed API calls in custom migration scripts. It ensures backwards-incompatible changes are handled correctly.
How do I preserve Workable scorecards and evaluations in Teamtailor?
Teamtailor has no native scorecard equivalent. Evaluations and ratings must be serialized into note-friendly text format and imported as Notes (Comments) attached to the candidate record. Verify the exact Notes endpoint behavior in your current Teamtailor API docs before building this.