Migrate your TalentLyft data

Candidates are the central person record in TalentLyft, linked to Applications, education, experience, and custom fields. The private API exposes GET/PUT/DELETE on candidates directly. We can migrate Candidates 1:1, preserving all standard fields and avatar data.

Applications are the junction record linking a Candidate to a Job with a specific Pipeline Stage. The API supports moving Applications between stages (POST /move_to_stage) and disqualifying them with a reason. We preserve stage history and disqualification records during migration.

Jobs are the open requisition records that drive pipelines and job-board distribution. The API exposes full CRUD for jobs. We migrate Jobs as the parent of Applications and map to destination job equivalents. Job-board distribution settings require manual reconfiguration at the destination.

Pipelines define the ordered stages a candidate Application passes through. Each Job is assigned one Pipeline. We preserve pipeline-stage order and stage names and can map them to equivalent stages in the destination ATS.

Stages are the discrete steps within a Pipeline (e.g., 'Applied', 'Phone Screen', 'Interview', 'Offer'). The API exposes stage IDs used in move_to_stage operations. We preserve which stage each Application was in at time of export.

Custom fields are settable at both the Candidate and Application level via the Custom Fields API endpoints. These vary per-customer and are user-defined. We map each custom field by name and type, handling text, number, date, and picklist values. Picklist options may differ between source and destination and require explicit mapping.

Application-level custom fields store per-application metadata such as interview scores, offer details, or compliance flags. They follow the same custom-field API as Candidate-level fields. We map them by field name and preserve values per Application record.

Talent Pools are curated collections of Candidates who have been identified for future openings but are not currently in an active Application. They are a core CRM concept in TalentLyft. We migrate Talent Pool membership, preserving pool name and the set of Candidates assigned to each pool.

Education is a sub-record on an Application, containing degree, institution, field of study, and dates. The API exposes dedicated endpoints for create, update, and delete on education records per Application. We preserve all education entries linked to each Application.

Experience records (work history) are sub-records on an Application with employer, title, dates, and description. The API supports CRUD on experience entries per Application. We migrate all experience records tied to each Application.

Departments are organizational units used to categorize Jobs. The API exposes GET/POST for departments. We preserve department names and IDs and map them to destination organizational units.

User accounts represent hiring team members (recruiters, hiring managers). The API can list users and expose roles and assignments. Migration of user accounts requires mapping to destination user identities since the destination system has its own user directory.

Locations (sites) are used on Jobs to specify where a role is based. The API exposes GET /v2/codes/locations. We migrate location records and link them to Jobs at the destination.

Automation rules trigger email actions, stage moves, or CRM updates based on events such as a candidate submitting an application. Automation rules are platform-specific configuration that cannot be exported via the public API. We do not migrate automation rules; these must be rebuilt at the destination.

TalentLyft supports templated email communication with Candidates. Templates are stored per-account but the API does not expose direct read/write on templates. We can migrate template content as structured text blocks during CSV-based migration but template variables and personalization tokens require manual recreation.