Migrate from empeon to Bullhorn ATS & CRM

Empeon Employee records map to Bullhorn Candidate records. The primary mapping key is employee email address to Candidate email. Employment status in Empeon (Active, Inactive, Terminated) maps to Candidate status in Bullhorn (Active, Lead, Inactive). Hire date maps to dateAdded; job title maps to occupation. We flag candidates who are currently employed versus former employees so the customer can set appropriate Candidate statuses in Bullhorn. The mapping excludes payroll compensation fields that have no standard Bullhorn equivalent; those are passed as structured CSV alongside the Bullhorn import.

Empeon employees who represent staffing firm clients or contacts map to Bullhorn Contact records on the relevant ClientCorporation. This handles the scenario where a healthcare facility's HR contact at a client organization is stored in Empeon and needs to become a Bullhorn Contact for business development purposes. We distinguish between internal employees (mapped to Candidate) and external client contacts (mapped to Contact on ClientCorporation) using Empeon's organizational hierarchy data.

Empeon Company Settings departments and cost centers map to Bullhorn ClientCorporation records when the department represents a client organization. For internal-only departments (IT, Finance, Clinical), we document the mapping without creating Bullhorn records since Bullhorn is a staffing ATS and does not use internal org structures. The customer's Bullhorn admin decides which departments represent staffing clients requiring ClientCorporation records.

Empeon direct deposit routing numbers and account numbers do not have native Bullhorn equivalents because Bullhorn ATS is not a payroll system. We map these to Bullhorn custom text fields on the Candidate entity. Routing numbers are encrypted in transit and stored with masked display (showing only last four digits). The customer provisions these custom fields during Bullhorn admin setup, or we coordinate with Bullhorn Support to create the fields. Direct deposit data is never written to logs or intermediate files.

Empeon benefit plan names, carrier codes, coverage tiers, and enrollment dates are exported as structured records per employee and mapped to Bullhorn custom fields on the Candidate entity. Plan names and carrier codes require a cross-reference table because Empeon plan identifiers often differ from the carrier's standard naming convention. We deliver benefit enrollment data as a structured CSV alongside the Bullhorn import, with the customer deciding whether to use Bullhorn Onboarding (formerly Able) for digital benefit enrollment post-migration.

Empeon PTO, sick leave, and accrual balances map to Bullhorn custom numeric fields on Candidate. Effective-dated balance snapshots migrate as the current balance value only; historical balance change logs are not transferred because Bullhorn does not have a native accrual audit trail object. We flag accrual balance data in the scoping document and recommend the customer retain Empeon for accrual tracking if the business requires historical accrual audit trails.

Empeon documents attached to employee profiles (offer letters, performance reviews, certifications, credentials) are exported as binary files with metadata and mapped to Bullhorn Candidate document attachments via the Bullhorn REST API. Certification documents migrate with the certification name in the document title and the expiration date stored in a custom date field. We process documents in batches of 50 to observe Bullhorn API rate limits and retry failed uploads with exponential backoff.

Empeon time entries and clock punches are not standard Bullhorn ATS records. If the customer licenses Bullhorn Time & Expense, we map Empeon clock punches to Bullhorn time entries by employee and date. If Bullhorn Time & Expense is not licensed, we deliver a time-and-attendance CSV export for the customer's payroll administrator to reconcile. We do not migrate Advanced Scheduling assignments because Bullhorn's scheduling model (Candidate availability, JobOrder shifts) differs fundamentally from Empeon's Employee View and Daily View scheduling paradigm.

Empeon payroll registers, pay periods, gross/net pay amounts, tax withholding, and deduction line items do not migrate into Bullhorn because Bullhorn is not a payroll system. We export payroll history as structured CSV organized by pay period, with each row representing an employee's earnings for that period. The customer retains Empeon for payroll operations or migrates to Bullhorn One's back-office payroll module as a separate implementation project. We flag this clearly in the scoping document and do not attempt to map payroll fields to Bullhorn Candidate fields.

Empeon free-text Input fields and Checkbox fields map to Bullhorn custom text and checkbox fields on the Candidate entity. Free-text values are copied verbatim; checkbox values (yes/no) map to Bullhorn checkbox fields. Because Empeon does not support picklists or date fields natively, any structured data stored as free text (e.g., a date entered as '01/15/2024') is parsed and coerced to the appropriate Bullhorn field type during migration. Data quality in unstructured free-text fields cannot be guaranteed.

Empeon Live Report definitions are documented as written specifications during scoping. We export the underlying row data as structured output and note the column configuration required to reproduce each report. Report formatting, grouping hierarchies, and custom column ordering do not transfer. The customer uses Bullhorn's built-in reporting to reconstruct equivalent views. Standard Reports are handled the same way.

The ESS Hub email-must-match requirement means the employee's email in their Empeon Workforce profile must match the email they use for self-service authentication. We capture all employee email addresses during discovery and cross-reference against the destination Bullhorn candidate email to flag mismatches before cutover. Email domain changes during migration (e.g., corporate rebranding) break ESS access and require employee re-registration. We document all flagged mismatches in the migration handoff document.