Migrate from ELMO Software to Bullhorn ATS & CRM

ELMO employee records map to Bullhorn Candidate profiles. The ELMO user name, contact details, email, and phone migrate to Candidate firstName, lastName, email, and phone. Employment type (full-time/part-time/casual), start date, and position migrate as custom fields on the Candidate record. Bullhorn's Candidate does not store payroll frequency or superannuation details natively; we create custom text or date fields to carry these for HR reference.

ELMO employee records also map to Bullhorn Contact if the organisation uses Bullhorn for internal staffing or contractor relationship tracking. Contact firstName, lastName, email, and phone copy directly. Department and position from ELMO map to Bullhorn Contact custom fields. The customer chooses whether to use Candidate, Contact, or both during scoping based on whether the Bullhorn instance serves external candidates, internal candidates, or both.

ELMO positions (GET /positions) define role titles and reporting lines. We map position title to Bullhorn Candidate.customText1 or a dedicated jobtitle custom field. If Bullhorn Jobs are in scope, the position also maps to JobOrder custom fields to preserve the original position hierarchy. Bullhorn does not have an organisational hierarchy object; we document the hierarchy as a note or structured field for admin reference.

ELMO department records (GET /departments) map to Bullhorn custom fields on Candidate and Contact. For staffing firms tracking candidate placement by department, we create a custom picklist field mapped to the ELMO department name. If departments correspond to client organisations, we map them to ClientCorporation records. We preserve the full department tree in a structured reference document.

ELMO location records (GET /locations) contain physical address and timezone. Bullhorn Candidate has address fields (address, city, state, zip) and JobOrder has a location field. We map ELMO location address to Bullhorn Candidate address and timezone to a custom field. Multi-location organisations with distinct compliance jurisdictions (AU vs NZ vs SG) require separate location records and corresponding Bullhorn custom fields.

ELMO legal entities (GET /legal-entities) define ABN/ACN-level employer records for AU/NZ payroll. Bullhorn ClientCorporation serves as the Account counterpart but is not payroll-linked. We map legal entity name to ClientCorporation name, ABN/ACN to a custom field, and address to the ClientCorporation address. If the organisation operates multiple legal entities, each becomes a separate ClientCorporation in Bullhorn. Bullhorn does not support payroll calendar configuration; legal entity metadata migrates as structured fields only.

ELMO employment details (GET /employment-details) include start date, employment type, pay frequency, and superannuation fund. We map these to Bullhorn Candidate custom fields: employmentStartDate (date), employmentType (picklist), payFrequency (picklist), superannuationFund (text). Employment type values (full-time, part-time, casual, fixed-term) map to Bullhorn picklist values that we define during schema design. Superannuation fund name migrates as text but is not linked to any Bullhorn payroll feature.

ELMO leave balances (GET /leave-requests BETA endpoint) contain current entitlement, accrued, and taken values per leave type. Because Bullhorn has no leave management object, we create custom numeric fields per leave type (annualLeaveBalance, sickLeaveBalance, parentalLeaveBalance) on the Candidate record, or attach a structured Note with all leave data serialised. We cross-validate against payroll reports exported from ELMO's UI before finalising the import.

ELMO configurable leave types (annual, sick, parental, long service, etc.) map to Bullhorn custom picklist fields on Candidate. We extract the full leave type schema from GET /configurable-fields-meta during scoping and create matching picklist values in Bullhorn. Leave type entitlement rules (accrual rates, carry-over limits) do not migrate as executable logic; we document them in the migration handoff notes for the customer's HR admin to reconfigure.

ELMO payroll calendars define pay periods, pay run dates, and STP reporting cycles. Bullhorn has no payroll calendar object. We export the calendar definition as a structured Note attached to the primary ClientCorporation or as a Bullhorn Custom Object named PayrollCalendar with fields for payPeriodStart, payPeriodEnd, and payRunDate. The customer uses this as reference data; Bullhorn does not execute payroll scheduling.

ELMO groups (GET /groups) define organisational units for access control and reporting. Bullhorn uses User roles and, in Nova (S-Release), Teams to manage access. We map ELMO group membership to Bullhorn role assignments and document the mapping. Bullhorn Nova Teams do not map directly to ELMO groups; we flag any structural mismatch during scoping.

ELMO organisations define custom metadata fields via GET /configurable-fields-meta. We extract field definitions (label, type, picklist values) and create matching Bullhorn custom fields before import. Bullhorn entity limits on custom fields vary by object and edition; we check limits during scoping and recommend Custom Objects for field counts exceeding entity limits. Field-level data migrates directly as values once the Bullhorn schema is deployed.

ELMO payroll data (pay runs, PAYG withholdings, superannuation contributions) does not migrate to Bullhorn. Bullhorn is a recruitment ATS and CRM, not a payroll system, and has no equivalent payroll execution object. We export payroll summaries as PDF or CSV from ELMO for the customer's finance team to retain for audit purposes. The payroll calendar metadata migrates as documentation only (see Leave Type entry).