Migrate from Darwinbox to Crelate

Darwinbox candidate records (applicant profiles, contact details, sourcing channel, stage history, ratings, and notes) map to Crelate Contact records. The Darwinbox candidate_id becomes the Crelate externalId for dedupe. Stage history (applied, screening, interview, offer, hired, rejected) migrates as a note on the Contact or as a custom Activity linked to the Contact, preserving the timeline but not the pipeline automation trigger. We extract candidate data via the Darwinbox recruitment API endpoints, which require the privileged API access (see gotcha). Crelate's Contact supports phone, email, address, and custom fields natively.

Darwinbox job postings and requisitions map to Crelate Job Posting records. The Darwinbox job_code, title, department, location, employment type, and job description fields map directly to Crelate's Job Posting fields. Open or closed status from Darwinbox sets the Crelate isOpen flag. We extract active job postings during the initial migration run; closed postings migrate on request with an isOpen=false flag.

Darwinbox applications link a candidate to a job posting with a stage, timestamp, and source. Each application creates a Crelate Contact record (if not already present) and associates it with the relevant Job Posting via Crelate's native association. If a single Darwinbox candidate has applied to multiple Darwinbox jobs, we create one Contact per unique candidate email and associate it with all migrated Job Postings. Application source (referral, job board, direct) migrates as a custom field or tag on the Contact in Crelate.

Darwinbox interview ratings, interviewer feedback, and scorecards stored against the application record migrate as Crelate Notes linked to the Contact or as custom fields (picklist or numeric) if the customer elects to structure them. We request read access to the feedback schema during discovery to determine whether the data is structured (API-returned as JSON) or unstructured text, which determines whether we can automate field mapping or fall back to note migration.

Darwinbox offer records (offer letter, offered salary, start date, offer status: accepted, declined, pending) map to Crelate Opportunity records representing placement tracks. The Darwinbox offered_compensation and start_date fields map to Opportunity fields; offer status maps to a custom Opportunity field or stage name in Crelate. We flag that Crelate Opportunity is the container for placement and billing records, not a traditional CRM deal, and confirm the customer's naming convention with them during scoping.

Darwinbox Employee records do not map to Crelate's primary ATS model. However, if the Darwinbox instance contains former applicants who are now employees (and the customer wants to track them as placed candidates in Crelate), we extract employees with a Darwinbox application history, map their employee_id to Crelate contact's externalId, and link them to the relevant Opportunity as a placed candidate. Employees with no prior application record are out of scope unless the customer elects a manual CSV import as a separate step.

Darwinbox hierarchical org units, cost centres, departments, and locations have no Crelate equivalent. Crelate uses Companies (as employer or client entities) and Job Posting departments as free-text or picklist fields, not a full org tree. We do not migrate org structure data. We provide a written list of Darwinbox departments and locations extracted during discovery so the customer's Crelate admin can configure them as picklist values post-migration.

Darwinbox attendance punch logs (timestamps, machine IDs, in/out status, shift-date references) have no Crelate equivalent. Crelate is an ATS and does not include time and attendance tracking. We do not migrate attendance data. If the customer needs attendance tracking alongside Crelate, they must configure a separate time-tracking integration post-migration.

Darwinbox leave entitlements, accrual rules, and current balances per employee have no Crelate equivalent. Crelate does not include a leave management module. We do not migrate leave data. We deliver a CSV extract of Darwinbox leave balances by employee as a courtesy so the customer's HR admin can record them manually in their chosen leave management tool.

Darwinbox payroll runs, compensation components, effective-dated salary rows, deductions, and tax codes have no Crelate equivalent. Crelate uses Bill and Pay rates on Opportunity (placement) records, not a payroll module. We do not migrate payroll data. Effective-dated compensation history remains in Darwinbox exports or the customer's payroll system of record as a manual step post-migration.

Darwinbox review cycles, ratings, goals, and manager feedback have no Crelate equivalent. Crelate's Opportunity (placement) includes placement notes and status but not a performance review module. We do not migrate performance data. We deliver a CSV extract of Darwinbox performance ratings by employee as a courtesy for HR admin records.

Darwinbox custom fields on candidate and application records are tenant-specific and not in the public API schema (see gotcha). We introspect the Darwinbox tenant's custom field registry during discovery to identify all candidate and application custom fields by name, type (text, numeric, picklist, date, boolean), and attached object. We then configure matching custom fields in Crelate (which exposes custom fields on Contacts, Companies, and Opportunities with documented logical names for API use) and map values during migration. Both platforms require manual field configuration before data loads begin.

Darwinbox document blobs (contracts, offer letters, certificates, government IDs stored in the document management module) are not accessible via the public REST API. Crelate does not have a native HR document management module; document storage is typically handled externally or via integrations. We do not migrate documents. We flag this as a manual step requiring Darwinbox vendor-assisted export or manual download, then re-upload to the customer's chosen document storage solution.

Darwinbox recognition events, peer awards, reward points, and social recognition stored in the engagement module have no Crelate equivalent. Crelate does not include an employee recognition or engagement module. We do not migrate engagement data.

Darwinbox user accounts with recruiter and hiring manager roles map to Crelate user provisioning. We extract the Darwinbox user list (email, name, role) during discovery. Crelate User creation is a manual admin step because Crelate's user provisioning requires the admin to invite users directly within Crelate's settings. We provide a user mapping spreadsheet linking each Darwinbox user to their Crelate email and role so the admin can provision them in bulk.