Migrate from TalentLyft to Recruit CRM & ATS

TalentLyft Candidates map directly to Recruit CRM Candidates. We resolve the candidate record via TalentLyft's paginated GET /v2/candidates endpoint, preserving name fields, email, phone, location, source, and tags. The candidate's original created_at timestamp migrates as a custom field original_created_at__c for audit. Any TalentLyft candidate with no email address is flagged in the reconciliation report for manual review because Recruit CRM's deduplication logic relies on email uniqueness.

TalentLyft Talent Pools are curated candidate collections for long-term relationship management and map to Recruit CRM Hotlists. Each Talent Pool name becomes a Hotlist name, and pool membership (the set of candidate IDs in each pool) maps to Hotlist entries. We export pool membership via the candidates endpoint filtered by pool assignment and create Hotlist records with candidate_id lookups during import. Customers with overlapping candidate membership (same candidate in multiple pools) result in that candidate appearing in multiple hotlists.

TalentLyft Applications are the junction records linking a Candidate to a Job with a specific Pipeline Stage. We migrate Applications with their stage assignment and stage entry timestamp. The Application ID from TalentLyft is preserved in a custom field original_application_id__c on the Recruit CRM Job Application for traceability. Stage history (which stages an application passed through) is captured by querying TalentLyft's stage-change events if available via the timeline API; otherwise, we migrate the current stage only and document this limitation.

TalentLyft Jobs (open requisition records) map directly to Recruit CRM Jobs. The job name, description, location, department, and status migrate. We preserve the job's assigned Pipeline ID and map it to Recruit CRM's pipeline stage configuration during migration. Jobs with a status of 'closed' or 'on hold' in TalentLyft are migrated as inactive jobs in Recruit CRM.

TalentLyft Pipeline Stages (Applied, Phone Screen, Interview, Offer, etc.) map to Recruit CRM pipeline stages. We retrieve all pipeline definitions via TalentLyft's GET /v2/pipelines endpoint, extract stage order and names, and configure equivalent Recruit CRM pipeline stages before migration. Stage probabilities are optional on TalentLyft and may not be populated; we default to Recruit CRM's standard stage probability percentages if source is blank.

TalentLyft Education records are sub-records on an Application containing degree, institution, field of study, start date, and end date. The API endpoint requires both candidate_id and application_id in the path. We implement a two-pass extraction: first stage all Applications with their IDs, then resolve the parent-record chain before pulling education sub-records per application. Education records attach to the migrated candidate in Recruit CRM via the candidate education endpoints. Customers with applications that share the same candidate across multiple jobs may have duplicate education entries if the same education record is tied to multiple applications; we deduplicate by institution and degree during import.

TalentLyft Experience records (work history) are sub-records on an Application with employer, title, dates, and description. Same two-pass resolution as Education: stage Applications first, then resolve parent-record chain before pulling experience sub-records. Experience records attach to the migrated candidate in Recruit CRM. Job titles and employer names migrate as free-text fields. Any experience record without a start date is flagged for manual review.

TalentLyft Candidate-level custom fields store per-candidate metadata (source details, rating scores, consent flags, etc.) and vary per account. We retrieve field definitions via GET /v2/custom_fields before migration, map each by name and type (text, number, date, picklist, checkbox), and create equivalent custom fields in Recruit CRM before candidate import. Fields with type mismatch (e.g., TalentLyft free-text storing a date value) are flagged for transformation. Customers with ten or more custom fields require an explicit field-by-field mapping session during scoping.

TalentLyft Application-level custom fields store per-application metadata such as interview scores, offer amounts, background check status, or compliance flags. Same field definition retrieval and typed mapping process as Candidate-level custom fields. Application-level custom fields migrate to Recruit CRM Job Application custom fields and are attached to the relevant application record after application creation. Notes field is the most common type mismatch at this level.

TalentLyft Departments are organizational units used to categorize Jobs. We retrieve department records via GET /v2/departments and map to Recruit CRM Departments. Department names and IDs preserve for reporting consistency. If Recruit CRM does not have a dedicated department object, we map departments to a custom picklist field on the Job record.

TalentLyft User accounts represent hiring team members. We extract users via GET /v2/users, preserving name, email, and role assignment. During Recruit CRM import, we match users by email to resolve OwnerId on candidate, job, and application records. Users without a matching Recruit CRM account are held in a reconciliation queue; the customer provisions missing users before record import resumes.

TalentLyft Locations specify where a role is based and are retrieved via GET /v2/codes/locations. We migrate location records and link them to Jobs at the destination. If a TalentLyft location does not have an equivalent in Recruit CRM, we create it as a new location during import rather than mapping to a generic 'Other' value.