Migrate from Breathe to Bullhorn ATS & CRM

Breathe Employees map to Bullhorn Candidate records as the primary record in the destination. We extract name, contact details (email, phone, address), job title, department, start date, employment status, and manager relationship from the People Data Export. In Bullhorn, Candidate is the central record for any individual — whether internal hire, contractor, or external candidate — so Breathe's employment data (start date, job title, status) maps to Candidate fields or custom fields. We pre-create any required Bullhorn custom fields via Tools > Field Mappings before migration. The Candidate's email address serves as the primary dedupe key during import.

Breathe custom fields on the Employee record are extracted from the People Data Export with field name and value. Bullhorn creates custom fields via Tools > Field Mappings by typing 'custom' and pressing Enter to filter for all custom field options. We pre-create the destination custom field schema in Bullhorn during configuration, matching field names and selecting appropriate Bullhorn field types (text, number, date, picklist). Field type mapping is validated against the source data — for example, Breathe multi-select values map to Bullhorn multi-select picklist. Fields that do not map to a Bullhorn native type are stored as text with the original type noted for the customer's admin to restructure post-migration.

Breathe absence records (annual leave, sick leave, other absence types) map to Bullhorn Task records linked to the Candidate. Each absence entry generates one Task with TaskType or a custom absence-type field indicating the absence category, the original absence date as ActivityDate, and the approval status preserved in a custom field. Bullhorn does not have a native absence management module, so this mapping preserves the historical absence data in the candidate record for audit purposes but does not replicate Breathe's balance calculation engine. We flag this as a limitation and recommend the customer evaluate Bullhorn's optional absence management features or a third-party HR integration if active leave tracking is required post-migration.

Breathe leave balances are calculated internally from entitlement settings and approval records. We extract entitlement settings and approval records independently from the People Data Export, compute expected leave balances at the migration cutover date, and compare against any pre-calculated balance fields before loading. Verified balances are stored as custom fields on the Candidate record in Bullhorn. Because Bullhorn does not have a native leave balance engine, these values are static at migration cutover — the customer's admin must configure any ongoing balance tracking in Bullhorn or a connected absence management tool.

Breathe sickness entries — a distinct record type linked to employees with dates, reasons, and Fit Note references — map to Bullhorn Task records with a sickness-specific custom field indicating absence type and a separate custom field carrying Fit Note reference where present. Sickness records are migrated as a separate task sequence from other absence types to allow the customer's admin to filter and report on sickness history independently in Bullhorn.

Breathe onboarding task lists and completion status migrate as Bullhorn Task records linked to the Candidate, with the original task name, due date, and completion status preserved in custom fields. Bullhorn's optional paid Onboarding product is not activated by default; we document the onboarding task structure so the customer's admin can decide whether to rebuild it natively in Bullhorn Onboarding or continue managing it as a task checklist. This is a configuration decision, not a direct automation migration.

Breathe performance review module exports include review cycle, template, ratings, and reviewer comments. Bullhorn does not have a native performance review object. We store review history as Bullhorn Note records with rich text for comments and custom fields for rating scores and review dates, or we create a Bullhorn custom object for performance review if the customer's data volume warrants the schema complexity. The customer chooses the storage strategy during scoping. Bullhorn's Note object supports ContentDocumentLink for any supporting documents from the review.

Breathe Remuneration Report and Payroll Export data (salary, additional payments, benefits, auto-enrolment status) is extracted as structured records. Bullhorn Placement records carry bill rate, pay rate, start date, and end date for temporary workers, which maps cleanly for staffing firms with placement-based pay. For permanent employee salary data with no placement context, we store remuneration fields as custom fields on the Candidate record. The customer confirms during scoping whether the migration is for a staffing firm (placement-centric) or a company using Breathe for internal HR (salary on Candidate). Bullhorn Back Office product may be relevant for ongoing payroll integration but is out of migration scope.

Breathe Company-level documents (policies, handbooks, templates) are stored in a separate silo from employee documents and cannot be bulk-exported via API. We document the manual download steps for the customer (Company > Company documents section) and provide a checklist. Downloaded documents are stored locally and handed to the customer for manual upload into Bullhorn as ContentDocument records, linked to the relevant ClientCorporation or Candidate. Bullhorn's package deployment or REST API can handle bulk document attach if the customer provides a named file inventory.

Breathe Employee documents (contracts, ID copies, certification records) are stored in the Profile > More > Documents section with no bulk export API. We flag this as a high-severity manual step in the scoping checklist and advise the customer to begin document downloads at the start of the engagement. Documents downloaded from Breathe are handed to the customer for manual upload into Bullhorn, where they attach via ContentDocumentLink to the corresponding Candidate record. This is a manual step that adds time to the overall migration timeline depending on document volume.

Breathe Learn completion records (GDPR awareness, health and safety compliance training) may not be included in the standard People Data Export if the customer is on a lower Breathe tier or if Learn is an add-on module. We perform a pre-migration data audit against the customer's module list and flag any Learn records that require additional extraction. Bullhorn does not have a native learning management system; completion records can be stored as Note records on the Candidate or as a custom object if the customer requires auditable compliance history in Bullhorn. This is a configuration decision documented during scoping.

Breathe owners (HR administrators, line managers) referenced on employee records are resolved by email match against Bullhorn User records in the destination. We extract all distinct owner IDs and emails from the source export and cross-reference against Bullhorn User. Owners without a matching Bullhorn User are placed in a reconciliation queue for the customer's admin to provision before record import resumes, because Bullhorn requires a valid OwnerId on Candidate and related Task records.