Migrate from Darwinbox to Bullhorn ATS & CRM

Darwinbox's unified Employee record does not map directly to a single Bullhorn object. We split based on employment status at migration time: active employees become Bullhorn Employee records (in the HCM module), former employees or applicants without an employment record become Bullhorn Candidate records, and current applicants still in the recruitment pipeline become Bullhorn Candidate records with status preserved. The original Darwinbox employee ID migrates as a custom field darwinbox_id__c on both Bullhorn Candidate and Employee for audit traceability. The split rule is defined during discovery and reviewed with the customer before migration day.

Darwinbox organisational units, cost centres, and location hierarchies map to Bullhorn Corporate Structure using the corporateCorporationID and parentID fields. The top-level org unit becomes the root CorporateCorporation record in Bullhorn, and child departments map as child CorporateCorporation records with the appropriate parent references. Cost-centre assignments from Darwinbox migrate as custom fields on each CorporateCorporation record. Location data maps to Bullhorn's Address object linked via the CorporateCorporation.

Darwinbox attendance punch logs (employee ID, timestamp, in/out status, machine ID, shift-date reference) map to Bullhorn TimeTracking records. Darwinbox shift policies and weekly-off names are extracted alongside attendance data and mapped to Bullhorn's time-tracking configuration before punch records are loaded. Each punch record receives a shift-policy mapping tag so that records remain auditable against Darwinbox's original shift rules. We flag any punch records that reference shift policies not representable in Bullhorn's model for customer review.

Darwinbox leave types (annual, sick, maternity, paternity, unpaid) and per-employee accrual balances map to Bullhorn Time-Off entries with accrual-type rules. We extract each employee's leave entitlement by type with the accrual rate, balance, and policy name, and create Bullhorn time-off entries with the corresponding accrual category. Darwinbox's multiple leave policies per org unit require a policy-mapping step before bulk leave loading. Leave that does not have a direct Bullhorn equivalent (for example, Darwinbox-specific leave types) migrates as a custom field on the Employee record.

Darwinbox effective-dated compensation rows (salary, bonus, deductions, tax codes) map to Bullhorn as historical records on the Employee object. Each effective-dated row becomes a dated entry in a custom compensation history object we pre-create in Bullhorn, with fields for effective_date, salary_amount, currency, bonus_amount, and deduction_type. The most recent effective-dated row becomes the active compensation on the Bullhorn Employee record. We sequence compensation rows chronologically and flag any overlapping effective dates for customer review before applying.

Darwinbox recruitment candidate profiles, applicant-stage history, sourcing information, feedback, and offer data export as Bullhorn Candidate records. The Darwinbox candidate ID migrates as a custom field darwinbox_candidate_id__c on Bullhorn Candidate for cross-reference. Applicant-stage history (applied, screening, interview, offer, hired, rejected) maps to Bullhorn's CandidateStatus field, and custom stage names are mapped to Bullhorn status values during the pre-migration schema review. Offer letters migrate as content document attachments on the Candidate record.

Darwinbox performance review cycles, ratings, goals, and manager feedback have no direct Bullhorn standard object equivalent. We pre-create a Bullhorn custom object (PerformanceReview__c) with fields for cycle_name, employee_id, reviewer_id, rating_value, rating_scale, goal_content, and feedback_text. Each review migrates as a PerformanceReview__c record linked to the Bullhorn Employee record via a lookup field. Rating scale values are normalised to a consistent numeric range defined during discovery.

Darwinbox users carrying admin, manager, or employee roles map to Bullhorn User records with the corresponding Bullhorn permission set or role hierarchy. We extract user-role assignments from Darwinbox and map them to Bullhorn's role and permission-set model during the migration. Any Darwinbox user without a matching Bullhorn User email is placed in a reconciliation queue for the customer's Bullhorn admin to provision before record import resumes.

Darwinbox tenant-specific custom fields (text, number, boolean, date, predefined-list types) require Bullhorn custom field creation before migration. We introspect the Darwinbox tenant's custom field registry during discovery to build the complete field list, then pre-create matching Bullhorn custom fields on the corresponding Bullhorn objects (Candidate, Employee, CorporateCorporation) using the Bullhorn Custom Object framework. Field types are mapped: Darwinbox text becomes Bullhorn String, number becomes Numeric, boolean becomes Boolean, date becomes Date, and predefined-list becomes a Bullhorn picklist.

Darwinbox recognition events (peer awards, reward points, social recognition) with timestamps and point values map to Bullhorn Activity records (type = Note or Custom) on the Employee record. Recognition content migrates as a Note attached to the Employee with the point value stored in a custom field. Bullhorn does not have a native rewards/recognition module, so recognition history is preserved as an audit trail rather than as a functional module.

Open and historical job postings from Darwinbox migrate to Bullhorn JobOrder records. Fields including job_title, department, employment_type, location, and description migrate directly. Status (open, closed, on-hold) maps to Bullhorn JobOrder status. JobOrder ID is stored as a cross-reference field for any candidate applications linked to the original Darwinbox job posting.

Employee documents (contracts, IDs, certifications) stored in Darwinbox's document management module cannot be accessed via the Darwinbox public REST API and are not migratable programmatically. We extract document metadata (filename, document type, attached employee ID, upload date) as a written inventory list that the customer's admin uses to manually upload files into Bullhorn or a linked document store post-migration. This step is flagged as out-of-scope for the automated migration.

Darwinbox approval chains, routing rules, and workflow logic are platform-stored automation configurations rather than data records and cannot be exported as structured objects. These do not migrate. We deliver a written inventory of every active Darwinbox workflow and approval chain with its trigger, conditions, actions, and assigned approvers. Bullhorn's own workflow and automation rebuild is a separate engagement or internal admin task documented in the handoff package.