Migrate from Teamtailor to Bullhorn ATS & CRM

Teamtailor Candidates map directly to Bullhorn Candidate records. The HubSpot-equivalent model in Bullhorn, Candidate stores name, email, phone, address, employment history, and education. Teamtailor custom fields on candidates migrate to Bullhorn custom fields on the Candidate entity, which we pre-create during schema design. We resolve the Teamtailor user (recruiter owner) by email match against Bullhorn User and assign OwnerId on insert.

Teamtailor Jobs map to Bullhorn Jobs. The job title, status (active/paused/closed), department, location, and body content transfer directly. Bullhorn Job status values map from Teamtailor's published, paused, and archived statuses. Job custom fields migrate to Bullhorn Job custom fields. We preserve the public job URL from Teamtailor as a reference field for back-links to the original posting.

Teamtailor Job Applications link a Candidate to a Job with a status, source, and timestamps. These map to Bullhorn Candidate Job Submissions, which are the primary join records between Candidate and Job in Bullhorn's ATS model. Application status, rejection reasons, and submission date transfer. We write Applications after both the Candidate and Job exist in Bullhorn to satisfy foreign key constraints.

Teamtailor Departments export as a flat list from the /v1/departments endpoint and map to Bullhorn Department records. Bullhorn uses Department as an organizational taxonomy on Job records. We import departments before Jobs so that the DepartmentId lookup is satisfied at Job insert time.

Teamtailor Locations map to Bullhorn Office records. Bullhorn Office stores geographic data (city, state/region, country) and can be linked to Job and Candidate records. We import Offices before Jobs to satisfy location lookups. If Teamtailor locations contain complex address components, we parse them into Bullhorn's address subfields during the transform step.

Teamtailor candidate custom fields are discovered by sampling candidate records during a discovery pass since Teamtailor does not expose a metadata endpoint. We inspect returned attributes across 25-50 sample records to build the full field list with types inferred from values. Each discovered field is pre-created in Bullhorn with a matching type (text, number, date, picklist) before the Candidate migration phase begins. Fields that exceed Bullhorn's per-entity custom field limit are flagged for Custom Object conversion.

Teamtailor job custom fields are scoped to the Job object and discovered alongside candidate custom fields during the same discovery pass. These map to Bullhorn custom fields on the Job entity. Job custom fields are typically fewer than candidate custom fields because Teamtailor's job templates have a more constrained schema. We create Bullhorn fields during schema design before the Job import phase.

Teamtailor Users (recruiters and hiring managers) map to Bullhorn User records by email match. We export the full user list from /v1/users and reconcile against Bullhorn's User table. Any Teamtailor user without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision before the Candidate migration phase runs.

Teamtailor Interview Kits group structured questions tied to jobs. Bullhorn does not have a native Interview Kit equivalent. We export kit names, question text, and question type from Teamtailor's API and write them as Bullhorn Note records linked to the corresponding Job, with the kit name in the Note title for discoverability. The customer's Bullhorn admin uses these as source material to rebuild structured interview guides in Bullhorn.

Teamtailor stores resumes, cover letters, and other files as upload objects with API URLs. We fetch each file from the provided URL and upload it as a Candidate Attachment in Bullhorn using the Bullhorn REST API's attachment endpoints. File type, filename, and upload date are preserved. Attachments are written after the parent Candidate record exists to satisfy the foreign key.

Teamtailor stores candidate answers to job application questions as separate answer objects linked to the application. We extract answers per application by querying /v1/answers with date-bounded pagination to avoid HTTP 500 errors on large datasets. Answers map to Bullhorn custom field values on the Candidate Job Submission record, using the question text as the field label.

Teamtailor Actions (stage changes, status updates, notes logged by recruiters) are exported from /v1/actions with date-bounded pagination. Bullhorn does not have a direct activity log equivalent, so we write Action records as Bullhorn Task entries with a custom field action_type__c carrying the original action type, preserving timestamps for audit. This is not a 1:1 migration of the activity timeline but a structured record of significant candidate interactions.

Teamtailor's Multi-Brand feature allows separate employer brands with separate career sites and candidate pools under one account. Bullhorn does not have a native multi-brand equivalent; brands are typically modeled as separate Bullhorn accounts or as a Job Classification taxonomy within a single account. We scope the export to a single Teamtailor entity during migration and document the multi-brand structure for the customer to decide whether to run separate Bullhorn accounts per brand or consolidate under one org.

Teamtailor application statuses (applied, screening, interview, offer, rejected, hired) map to Bullhorn Candidate Job Submission status values. We create a Bullhorn Status Category or use the existing status workflow to match Teamtailor's pipeline stages. Closed statuses (rejected, hired) map to Bullhorn's isClosed flag.