Migrate from Dayforce to Recruit CRM & ATS

Dayforce Workers with active recruiting context (candidates submitted through Dayforce Recruiting) map to Recruit CRM Candidate records. We extract Worker biographical data (name, contact, employment status) and map it to Candidate fields. Note that Dayforce Workers are primarily HCM records; we scope migration to Workers flagged as candidates in the Dayforce recruiting module to avoid importing full employee populations into an ATS. Workers without a candidate record in Dayforce do not generate Candidates in Recruit CRM.

Dayforce Job Assignment records (exported via CSV from Dayforce Recruiting module) map to Recruit CRM Job records. The Job title, description, requirements, and status transfer directly. Dayforce exports Job Assignment.csv and Job.csv with all fields including Workers Comp classification codes. We preserve the job posting status from Dayforce and set the corresponding Recruit CRM Job status field.

Dayforce Position Management defines organizational hierarchy and position terms with effective dates and status. These records do not map to a single Recruit CRM object because Recruit CRM is an ATS not an HRIS. We extract the Position hierarchy as reference data and present it as a supplemental organizational mapping document for the customer to use if they configure department or division fields in Recruit CRM's Job or Company records.

Dayforce Legal Entities (multi-jurisdiction payroll entities stored as LegalEntityXRefCode in payroll exports) map to Recruit CRM Company records representing the customer's own organization. Dayforce supports multiple legal entities per organization; we extract all active entities and create corresponding Company records in Recruit CRM with the LegalEntityXRefCode stored in a custom field for reference.

Dayforce Pay Rates (effective-dated on Workers) do not have a direct equivalent in Recruit CRM's Candidate object. Recruit CRM stores compensation expectations as a text or currency field on Candidate records. We extract the Worker's current base pay rate and map it to the Candidate compensation expectation field, flagging that this represents Dayforce pay data as of the extraction date and is not a live payroll feed.

Dayforce supports custom fields at the Worker level and on document entities. We extract all custom field values from Worker and Job Assignment records and map them to Recruit CRM Custom Fields. Recruit CRM uses nested custom field schemas; we translate Dayforce custom field functions and computed values into static custom field values at migration time and note that any computed-field behavior requires manual rebuild in Recruit CRM.

Dayforce manages documents attached to Workers, Jobs, and Positions. We extract document metadata and binary blobs where accessible and attach them as Files to the corresponding Recruit CRM Candidate or Job record. Document type configurations in Dayforce do not map directly to Recruit CRM file categories; we store the original Dayforce document type as a tag on the File record.

Dayforce Benefits Enrollments and tiered coverage elections have no equivalent in Recruit CRM's recruitment-focused data model. We extract a summary of benefit plan enrollments as a reference export for the customer's records but do not load this into Recruit CRM. Benefits data belongs in an HR system or benefits administration platform, not an ATS. We flag this boundary clearly in the scoping document.

Dayforce accrual balances, carryover rules, and time-off usage records have no equivalent in Recruit CRM. These records belong to a payroll or time and attendance system, not a recruitment platform. We extract a time-off balance snapshot as a reference export for the customer's HR team but do not load this into Recruit CRM.

Dayforce supports Tax Identification Number and Social Insurance Number migration for employee National IDs. We map these to Candidate records in Recruit CRM where the platform supports national ID storage. Note that Dayforce's migration interface supports only TIN and SIN; any other national ID formats (passport numbers, visa numbers, national registry IDs) cannot be migrated through the standard interface and are flagged for manual entry.