Migrate from Teamdoor to Bullhorn ATS & CRM

Teamdoor's candidate record maps directly to Bullhorn's Candidate entity. The candidate's profile (name, email, phone, resume, skills, work history) transfers as Bullhorn Candidate fields. Bullhorn parses the resume on import using its built-in resume parser. The candidate's original source (job board, referral, career site) is preserved in Bullhorn's source field.

Teamdoor's job posting (title, description, requirements, location, employment type, salary range) maps to Bullhorn's JobOrder entity. Bullhorn JobOrder includes address, pay rate, employment type, and status fields that correspond directly to Teamdoor's job configuration. The job's published/unpublished status maps to Bullhorn's JobOrder 'isOpen' field.

Teamdoor's kanban card represents a candidate applied to a specific job with a pipeline stage. FlitStack AI splits this into a Bullhorn JobSubmission record linked to the Candidate and JobOrder, with the JobSubmission status mapped from the Teamdoor stage name (Applied, Screening, Interview, Offer, Hired). Bullhorn's JobSubmission status field is used to track the application workflow.

Teamdoor's Talent Pool stores candidates not attached to an active job. These migrate as Bullhorn Candidate records tagged with a custom 'Talent_Pool__c' field set to true. Bullhorn has no native talent pool concept — all candidates are in one candidate database, so tagging with a custom field distinguishes passive-sourced candidates from active applicants.

Teamdoor's customizable employer branding pages (career site with company logo, banner, job listings) have no direct equivalent in Bullhorn. Bullhorn offers a Career Portal module but it must be configured separately from the ATS data. FlitStack preserves the page content as a structured export so Bullhorn admins can recreate the branding in Bullhorn's career portal builder.

Teamdoor interview schedules with candidate name, job, date/time, interviewer, and location map to Bullhorn Notes of type 'Interview'. Bullhorn does not have a native interview scheduling entity — calendar integration with Outlook/Gmail is managed separately. The interview details (interviewer name, interview type, notes) are preserved as Bullhorn Note records linked to the Candidate and JobSubmission.

Teamdoor companies (employer clients with name, industry, contact info, size) map to Bullhorn's ClientCorporation entity. Bullhorn ClientCorporation stores the client name, address, industry, website, and a list of associated contacts. The client corporation is the parent entity for JobOrders and Placements in Bullhorn's data model.

When Teamdoor's pipeline reaches the 'Hired' stage, FlitStack creates a Bullhorn Placement record linking the Candidate, JobOrder, and ClientCorporation. Bullhorn Placement includes start date, end date, pay rate, bill rate, and employment type — these map from Teamdoor's offer details and the job posting's compensation fields.

Teamdoor custom fields at the candidate level (e.g., clearance level, certification expiry, preferred location, availability date) require Bullhorn custom fields. Bullhorn allows up to 55 custom fields per entity (Front Office Growth/Enterprise tier). FlitStack creates these via Bullhorn Admin > Field Mappings before data loads and maps field values value-by-value. Fields exceeding the Bullhorn per-entity limit must be consolidated or stored on a Bullhorn custom object.

Teamdoor job-level custom fields (e.g., security clearance requirements, travel percentage, remote policy) map to Bullhorn JobOrder custom fields. Bullhorn JobOrder custom fields are created in the same Admin > Field Mappings interface. Bullet points from Teamdoor job descriptions that contain structured data (e.g., 'Remote: Yes') can be parsed into Bullhorn custom fields if the data is consistently formatted.

Teamdoor notes attached to a candidate record (recruiter comments, interview feedback, screening notes) migrate as Bullhorn Note records linked to the Candidate. Bullhorn Note includes the note body, author (mapped by email to Bullhorn User), and create date. Original timestamps are preserved for audit continuity.

Teamdoor email threads and communication history attached to candidates map to Bullhorn Notes of type 'Communication'. Bullhorn does not store raw email threads as a native object — communication history is surfaced through the Candidate's activity feed. We preserve the sender, recipient, subject, and body as Bullhorn Note records for reference.

Teamdoor's analytics dashboard (channel-level conversion rates, pipeline stage drop-off, time-in-stage metrics) is a reporting construct that does not transfer. Bullhorn's Reports module rebuilds analytics from migrated data — but historical conversion rates calculated by Teamdoor's engine are not available post-migration. FlitStack exports Teamdoor's report snapshots as CSV reference files for Bullhorn admins to use as benchmarks when configuring Bullhorn reports.

Teamdoor users (recruiters, HR admins) are matched to Bullhorn Users by email address. Bullhorn User records include firstName, lastName, email, and role (internal employee or external recruiter). Unmatched Teamdoor users are flagged before migration — your Bullhorn admin either creates a Bullhorn User record first or assigns the records to a fallback owner.

Teamdoor skill tags and candidate labels (e.g., 'Python', 'CPA', ' bilingual') map to Bullhorn's Candidate Specialty field for standard skills, or to a custom multi-select field if Teamdoor uses structured tag categories. Bullhorn's Candidate entity has a 'specialty' text field; for multi-value tags, a custom pick-list field is created and populated with Teamdoor's tag values.