Migrate from Namely to Bullhorn ATS & CRM

Namely Employee records map to Bullhorn Candidate records. Core fields (name, email, phone, address, hire date, termination date, employment status, job title, department, cost center) transfer to Bullhorn's Candidate standard fields or to custom fields if no standard equivalent exists. The Candidate's email address is used as the dedupe key during import. Former employees migrate as inactive Candidates with a status flag so they appear in talent pool searches for future roles.

Salary history, bonus records, and compensation effective-dates from Namely transfer to custom fields on Bullhorn Candidate (e.g., base_salary__c, bonus_history__c, comp_effective_date__c). Bullhorn has no native compensation management module, so compensation data becomes reference-only fields that inform placement rate discussions but do not drive payroll. Historical pay ranges are preserved as text or number fields per year.

Health, dental, vision, and 401k enrollment elections map to custom multi-select picklist or text fields on Candidate (e.g., health_plan__c, dental_elect__c). Carrier-specific plan IDs (e.g., Aetna PPO 2024) have no Bullhorn equivalent and are stored as text strings for reference only. The customer must configure equivalent benefit plan offerings in their own HRMS or PEO before employee re-enrollment. We extract enrollment records but flag that plan IDs are not operational records in Bullhorn.

Payroll run summaries, earnings, deductions, taxes, and year-to-date gross-to-net figures from Namely are exported as custom fields on Candidate (e.g., ytd_gross__c, ytd_deductions__c, last_pay_date__c). Bullhorn does not process payroll, so this data is historical reference for staffing placement rate conversations. We preserve YTD figures as of the migration snapshot date and do not create operational payroll records.

PTO, sick leave, and accrual balances migrate as custom number fields on Candidate (e.g., pto_balance_hours__c, sick_balance_hours__c). For unlimited PTO policies, there is no balance to export; we note this in the migration report and recommend a policy document as a placeholder artifact. Bullhorn has no native time-off tracking module.

Namely departments, cost centers, and reporting hierarchies map to custom fields on Candidate. Reporting manager relationships (employee to manager employee ID) are resolved by matching manager email or employee ID to the Bullhorn Candidate record to establish the hierarchy reference. Org chart visualization is not a Bullhorn feature.

Performance ratings, review cycle names, goals, and feedback text migrate as a combination of custom fields (rating_score__c, review_cycle__c) and Note records attached to the Candidate. Custom rating scales from Namely are preserved as text strings rather than numeric scores to avoid value-range mismatches. Bullhorn has no native performance management module.

Employee documents (offer letters, I-9s, tax forms, contracts) export from Namely's Documents module as binary files with inconsistent naming conventions. We normalize file names to {employee_id}_{document_type}.pdf before Bullhorn import. Files attach to the Candidate record via Bullhorn's resume and attachment upload mechanism. Document metadata (upload date, uploader) migrates as a JSON sidecar. Bullhorn's document storage is designed for resumes and candidate attachments, not HR-form documents.

Namely custom properties on Employee records map to Bullhorn custom Candidate fields. Bullhorn custom objects must be initially set up by Bullhorn Support via a support ticket (not self-service). We discover custom field definitions via the Namely API during discovery and coordinate with Bullhorn Support to pre-create equivalent custom fields before migration. Field types (text, number, date, picklist) map to nearest Bullhorn field types.

Namely approval workflows and automation chains are not structurally portable to Bullhorn. We export workflow names, associated employee records, and approval chain descriptions as a written inventory document. Bullhorn's own workflow and automation features differ architecturally (tearsheets, hotlists, automations vs. property-triggered HR workflows). The customer's admin rebuilds any required recruiting automation in Bullhorn's automation engine post-migration.

Namely user accounts that will manage Bullhorn (recruiters, account managers, admins) map to Bullhorn User records. User provisioning in Bullhorn is handled by the customer's Bullhorn account team; we match users by email address during migration and flag any unmatched accounts in a reconciliation queue. Active and inactive status preserves from Namely.

If Namely contains client or vendor company records (in addition to the internal employer company), these map to Bullhorn ClientCorporation records. The company name, address, industry, and key contact information transfer to standard Bullhorn fields. This mapping is applicable only if the customer used Namely's organizational module for external company records, which is an optional configuration.