Migrate from Asanify to Bullhorn ATS & CRM

Asanify Employee records map to Bullhorn Candidate. Core fields that transfer: firstName, lastName, personalEmail or workEmail as email, phone, dateOfJoining as dateAvailable, departmentName as currentTitle, and employmentStatus mapped to a CandidateStatus picklist value. Custom fields carry the original Asanify employee ID, employment type (full-time/part-time), and any EOR employer entity as a text field. Address data from Asanify maps to Candidate address fields. Bullhorn requires lastName, so any Asanify record without a last name is flagged for customer review before import.

Asanify department assignments on employees map to a Bullhorn ClientCorporation record representing the customer's internal organization if they operate as both an employer and a staffing firm. Department hierarchy (reporting lines) is preserved as a custom field parent_department__c rather than a native hierarchy object because Bullhorn ClientCorporation does not support nested corporate structures natively.

Asanify contractor records map to Bullhorn Candidate with employmentType set to Contract and contractor-specific fields (contractRate, contractStartDate, contractEndDate, currency) mapped to custom Candidate fields. Multi-currency contractor rate from Asanify ($18/contractor/month) is stored as a decimal custom field rather than a Bullhorn native currency field because Bullhorn's currency handling is US-dollar-based for staffing placements. The EOR flag on contractor records carries forward as a text field identifying the employer-of-record entity and country.

EOR records from Asanify preserve the employer-of-record entity and country of legal employment as custom fields on Bullhorn Candidate: eor_entity__c (text), eor_country__c (picklist), and eor_relationship__c (text description). Bullhorn has no native EOR concept, so the EOR relationship is metadata rather than a system-enforced employment entity. Compliance review is recommended before migrating EOR records to any non-EOR system because the legal employment relationship does not transfer—only the record does.

Asanify employment documents (offer letter, NDA, ID copies) available on VIP and Enterprise tiers migrate as Bullhorn ContentDocument records linked via ContentDocumentLink to the Candidate. File types map to Bullhorn document categories. Documents are exported from Asanify as binary files and attached to the Candidate record during migration. Document count per employee is reported in the pre-migration inventory so the customer can decide whether to attach all documents or a subset.

Salary revision history is too granular for direct field mapping in Bullhorn. We export the most recent salary record (currentAnnualSalary, currency, effectiveDate) as custom Candidate fields. The full revision log is exported as a CSV and delivered alongside the migration for compliance audit or future payroll system integration. Bullhorn has no native payroll or compensation history object.

Leave balances are a leave-management concept with no Bullhorn equivalent. Bullhorn Candidate and Placement records do not include leave entitlement, accrual, or carry-forward fields. We export current leave balances as a CSV report keyed by employee ID and present it to the customer during pre-migration review. The customer decides whether to retain this in Asanify, import to a separate HR system, or accept the gap.

Geo-tracked attendance logs, punch timestamps, and biometric attendance records have no Bullhorn equivalent. Bullhorn's entity model covers recruiting (Candidate, JobOrder, Placement) but not HR operations. We export attendance records as a CSV for the customer's records. Geo-tracking data quality in Asanify is variable (sparse or approximate coordinates), which further limits migration utility even if a destination existed.

Payslip records, TDS deductions, PF contributions, ESIC contributions, and net pay amounts are payroll data with no Bullhorn analog. Bullhorn Placement records hold the bill rate and pay rate for staffing placements but not payroll compliance fields. We export payslip summary data as a CSV for the customer's finance or payroll team. Statutory compliance records (TDS, PF, ESIC, professional tax) should remain in Asanify or a payroll-compliant destination.

Performance management and 360-degree feedback are VIP-tier features in Asanify with no Bullhorn equivalent. Bullhorn Candidate has skills ratings and a limited scorecard model but not structured performance review cycles, ratings, or free-text feedback. VIP-tier Asanify accounts with active performance history receive a written inventory of review records by employee with cycle dates, ratings, and feedback text for manual re-entry or alternative HR system placement.

OKR-based goal tracking is a VIP-tier feature in Asanify. Bullhorn has no native OKR or goal management module. We export company-level and individual OKR records, key results, and progress percentages as a CSV. Customers moving to Bullhorn for ATS purposes typically retain goal tracking in a separate system (Lattice, 15Five, or a renewed Asanify contract) or accept the gap.

KPI definitions and current values stored against employee records in Asanify VIP tier have no Bullhorn destination. Bullhorn Placement records hold bill rate, pay rate, and start/end dates but not employee performance KPIs. We export KPI definitions and values as a CSV keyed by employee ID. The customer chooses the destination for this data during scoping.

Shift scheduling is a VIP-tier feature in Asanify. Bullhorn has no shift management or time-tracking module. We export shift definitions, assigned employees, and shift dates as a CSV for the customer's operations team. Shift-based staffing agencies using Asanify for internal workforce management retain this capability in Asanify or move it to a dedicated scheduling tool.

Expense reimbursement workflows on VIP and Enterprise tiers have no Bullhorn equivalent. Bullhorn Placement and Candidate records do not include expense tracking. We export reimbursement records with amounts, categories, and approval status as a CSV. Pending reimbursements at migration time require explicit resolution (approve or reject) before the Asanify cutover to prevent orphaned requests.