Migrate from TalentLyft to Bullhorn ATS & CRM

TalentLyft Candidates map to Bullhorn Candidate records. We extract Candidates via cursor-paginated GET /v2/candidates with the 500-requests-per-minute TalentLyft limit and stage them in a temporary dedupe key table (email as primary). Bullhorn Candidate requires no parent lookup, so Candidates insert first and resolve the Bullhorn candidateID before any downstream Application import. Standard fields (firstName, lastName, email, phone, source) map directly; custom fields map after we retrieve TalentLyft field definitions via GET /v2/custom_fields.

TalentLyft Applications link a Candidate to a Job with a specific Pipeline Stage. They map to Bullhorn JobSubmission records. The JobSubmission requires a valid jobOrderID (from the mapped Job) and a candidateID (from the mapped Candidate) before insert. Pipeline stage name from TalentLyft maps to JobSubmission status, and we use the mapping table built during scoping to translate to equivalent Bullhorn submission status values. Application-level custom fields migrate to custom fields on JobSubmission.

TalentLyft Jobs map to Bullhorn JobOrder. The JobOrder requires a ClientCorporation (mapped from TalentLyft's Department or created as a Bullhorn ClientCorporation if the source has no client entity) before insert. We extract Jobs via GET /v2/jobs, map title, description, employmentType, and location, and link to the Bullhorn JobOrder recordType and salesProcess determined during scoping. Job board distribution settings do not migrate.

TalentLyft Pipelines define ordered stage sequences for job requisitions. Bullhorn models equivalent stage sequences as Record Types (one per TalentLyft Pipeline) with corresponding Sales Processes that whitelist stage values. We extract the stage order and names during discovery, build the Bullhorn Record Types and Sales Processes via metadata API before any JobOrder import, and map JobOrder recordTypeID during migration. The customer configures Page Layouts post-migration.

TalentLyft Pipeline Stage names map to Bullhorn JobSubmission status values (Added, Submitted, Interview, Offer, Placement, Rejected). We build a stage name mapping table during scoping and apply it during the JobSubmission insert phase. Custom stage names not recognized by Bullhorn default to the nearest standard status and are flagged in the reconciliation report.

TalentLyft Talent Pools are curated candidate collections. Bullhorn has no native Talent Pool equivalent; we model them as Bullhorn Candidate Lists (for sourcing pools) or as a ClientCorporation association on the Candidate record using a custom field. The customer chooses the strategy during scoping based on how they use Talent Pools. List membership migrates as Candidate List Assignment records.

Education records are sub-records on a TalentLyft Application. The API requires GET /v2/applications/{applicationId}/education which depends on the parent applicationId. We run a two-pass extraction: first stage all Applications with their IDs, then resolve the parent chain and pull education sub-records per Application. Bullhorn Candidate does not have a native structured education sub-record; we map education fields to custom fields on the Candidate record or to formatted Note records with structured body text.

Experience records follow the same two-pass extraction pattern as Education: Application IDs staged first, then GET /v2/applications/{applicationId}/experience sub-records pulled per Application. Bullhorn Candidate does not have native structured work history; we map to custom fields on Candidate or to formatted Note records. Employer, job title, start/end dates, and description migrate as separate structured fields.

TalentLyft Candidate-level custom fields vary per-account and are retrieved via GET /v2/custom_fields before migration. We cross-reference field IDs, labels, and data types against Bullhorn Candidate field names. Bullhorn uses customText, customDate, customBoolean, and customInteger fields (custom1–custom50 depending on edition). Customers with more than 10 Candidate-level custom fields require the Front Office Growth edition or a customObject to hold overflow fields. We run explicit field-by-field mapping sessions for accounts with 10 or more custom fields.

TalentLyft Application-level custom fields store per-application metadata such as interview scores, compliance flags, or offer terms. They map to Bullhorn JobSubmission custom fields. Bullhorn supports custom fields on JobSubmission (customText1–customText50, etc.) at the ATS and Front Office Growth tiers. Application-level custom field values are tied to the Application record; we resolve the JobSubmission bullhornID at import time before inserting the custom field values.

TalentLyft Departments organize Jobs. Bullhorn uses ClientCorporation (for client companies) or Division (for internal organizational units). If the TalentLyft Department represents an internal hiring function, we map to Bullhorn Division. If it represents a client organization, we map to ClientCorporation. We extract all Departments via GET /v2/departments during discovery and decide the mapping strategy with the customer during scoping.

TalentLyft Locations (sites) used on Jobs are retrieved via GET /v2/codes/locations and map to Bullhorn JobOrder address fields (address, city, state, zip, country). We preserve location name as a text field on JobOrder and link it to the Bullhorn standardized address where possible. Locations without an address (e.g., remote) map to a jobCity value of Remote with a note field populated.

TalentLyft Users (recruiters, hiring managers) map to Bullhorn User records by email match. We extract all users via GET /v2/users during discovery, then match by email against the Bullhorn org's User table. Any TalentLyft User without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision. OwnerID references on JobOrder, JobSubmission, and Candidate require a valid Bullhorn User before insert.

TalentLyft accounts with custom object concepts (modeled as structured custom fields or linked records) map to Bullhorn customObject1 through customObject10 depending on the Bullhorn edition. Bullhorn ATS Growth excludes custom objects; Bullhorn ATS allows 2; Front Office Growth and Enterprise allow 10. We pre-create the Bullhorn custom object schema via Bullhorn Support's Custom Object Setup Sheet before any data import, then import records via the customObject REST API endpoints. Each customObject supports 55 searchable fields.

TalentLyft Automation Rules (trigger-based email actions, auto-stage moves, CRM updates) are platform-specific configuration not accessible via the API. We do not migrate them. We deliver a written automation audit document listing every active TalentLyft Automation Rule with its trigger conditions, actions, and recommended Bullhorn Automation equivalent. The customer's Bullhorn admin rebuilds each automation in Bullhorn Automation post-migration. This document is produced during scoping.

TalentLyft email templates with personalization tokens are stored in the platform's configuration layer and are not exposed via the API. We do not migrate them. We produce a template audit document listing every active template with its personalization fields, subject line, and body content. Bullhorn admins rebuild templates in Bullhorn using Bullhorn's template editor or via the REST API POST /entity/EmailTemplate. The rebuild is a manual step handled by the customer's Bullhorn admin post-migration.