Migrate from Ceipal ATS to Recruit CRM & ATS

Ceipal Applicant records map to Recruit CRM Candidate. We extract applicant profiles, structured contact details, skills, and work history via Ceipal's API (not CSV) to preserve parsed fields. Candidate email addresses are validated during staging against the Dice-portal-email corruption pattern—if a Ceipal candidate's primary email matches a third-party portal domain, we flag it for manual review and optionally preserve the corrected email in a secondary custom field in Recruit CRM. Resume files transfer as binary attachments via Recruit CRM's file upload endpoint so parsing triggers on the destination side.

Ceipal Job records map to Recruit CRM Job. We map title, description, location, requirements, and pipeline stages to Recruit CRM job fields. Ceipal job stages translate to Recruit CRM pipeline stages during migration; if the customer has custom stage names, we create matching stages in Recruit CRM before import. Active job status preserves; archived jobs migrate as inactive unless the customer specifies a different cutoff.

Ceipal Submissions link an Applicant to a Job with submission status, submittal date, and recruiter assignment. Recruit CRM does not have a native Submission object equivalent; we represent the submission chain as a Candidate record linked to a Job with a custom Submission Status field and the submission date preserved. The recruiter assignment resolves via owner email mapping against Recruit CRM User records. Ceipal's encrypted submission IDs are held in the staging ID-mapping table so the full chain remains traceable post-import.

Ceipal Client records (company name, contact info, billing details) map directly to Recruit CRM Company. We preserve address data, client status, and any associated contacts as Recruit CRM Contact records linked to the Company. Client status from Ceipal maps to a Company custom field if the customer's workflow relies on client lifecycle stages.

Ceipal Leads are distinct from Clients with different status fields and source attribution. Recruit CRM uses Company as the account-level record and Contact as the person-level record without a separate Lead object. We map Ceipal Leads to Recruit CRM Contacts or Companies depending on whether the Lead has person-level detail (name, email, phone) or company-level detail only. The original lead status and source attribution migrate as custom fields on the destination record for reporting continuity.

Ceipal Placements (final hiring outcome tying Applicant to Job under Client) map to Recruit CRM Deal. Placement start date, compensation, and billing details migrate to Deal fields. The Deal is linked to the candidate (as the primary Contact) and the Company (client) in Recruit CRM, and the original placement record is preserved as a custom field set for audit. Ceipal's encrypted Placement ID is logged in the staging ID-mapping table.

Ceipal WorkForce module records (employee profiles, compensation, department, location) are outside Recruit CRM's data model scope because Recruit CRM does not include an HR/employee management module. If the customer uses WorkForce alongside the ATS, we scope the WorkForce migration as a separate engagement. If the customer only needs placement history and candidate records in Recruit CRM, we exclude WorkForce records from the standard migration scope and note this in the written scope document.

Timesheet records in Ceipal WorkForce track hours per employee per period. Recruit CRM does not have a native timesheet object; time-tracking is not a standard feature. We do not migrate timesheets as part of the ATS migration. If the customer requires timesheet data in Recruit CRM, it would need to be represented as custom line items or notes on a Deal, which we document as a configuration option rather than a standard mapping.

Ceipal allows admins to add custom columns to grids and custom properties on Applicants, Jobs, and Placements. These are organization-specific with no published schema. During discovery, we enumerate all custom fields by querying the Ceipal API's field metadata endpoints and manually reviewing the admin UI with the customer's access. Each custom field is then created in Recruit CRM with the matching type (text, number, date, picklist, checkbox) before any data import, because Recruit CRM requires custom fields to exist before values can be written to them via API.

Ceipal stores documents against applicants, jobs, and placements (resumes, offer letters, contracts). We transfer documents as binary blobs via Recruit CRM's file upload API. Resume files attach to the corresponding Candidate record and trigger re-parsing. Offer letters and contracts attach to the associated Deal or Company record. Ceipal's encrypted document IDs are logged in the staging ID-mapping table so attachment associations are preserved across the migration.

Ceipal Owner records (the recruiter or staff member assigned to a candidate, job, or submission) map to Recruit CRM User. We resolve owners by email match. Any Ceipal Owner without a matching Recruit CRM User goes to a reconciliation queue where the customer's admin provisions the User before record import resumes, because OwnerId references are required on most standard object inserts in Recruit CRM.