Migrate from SignalHire to Bullhorn ATS & CRM

SignalHire People Profiles map directly to Bullhorn Candidate records. The person's name maps to firstName and lastName; current job title maps to Candidate.occupation; current employer maps to Candidate.companyName; location maps to Candidate.address. SignalHire's verification status (Valid / Risky / Unknown) is preserved in a custom field sh_email_verification__c. The SignalHire UID is stored in a custom field sh_profile_id__c as an audit reference. If the SignalHire profile contains work history beyond the current position, employment records migrate as Bullhorn CandidateEmployment records via the employmentHistory sub-entity or as a structured note if the destination Bullhorn instance does not have the employment sub-entity enabled.

SignalHire Company Profiles map to Bullhorn ClientCorporation records. Company name maps to ClientCorporation.name; domain maps to ClientCorporation.website; industry maps to ClientCorporation.industry; size range maps to ClientCorporation.numberOfEmployees or a custom size-tier field. SignalHire's company records are scraped derivatives from professional profile pages rather than authoritative company data, so we flag this provenance in a custom field sh_company_provenance__c. If the staffing agency already uses Bullhorn's ClientCorporation structure for real clients, SignalHire company profiles are imported as separate records with a type flag to distinguish sourced prospects from active client accounts.

The primary verified email address from SignalHire maps to Candidate.email. Additional emails on the profile map to Candidate.email2 and Candidate.email3. The SignalHire deliverability status (Valid / Risky / Unknown) is preserved per address in custom fields sh_email1_status__c, sh_email2_status__c, and sh_email3_status__c. Risky-flagged emails are flagged in Bullhorn but not excluded from import; the customer's admin decides whether to suppress outreach to those addresses.

SignalHire phone numbers with country code and line type (mobile/landline) map to Candidate.phone, Candidate.phone2, and Candidate.phone3. The SignalHire verification confidence score is preserved in custom fields sh_phone1_confidence__c and sh_phone2_confidence__c. Mobile numbers are flagged with a sh_phone1_type__c custom field set to Mobile or Landline. If SignalHire returns no phone for a profile, no phone field is populated in Bullhorn.

SignalHire's LinkedIn URL maps to Bullhorn's standard Candidate.customText34 field, which is the designated LinkedIn URL field in Bullhorn's Candidate Search! configuration. Any additional social profiles (Twitter, GitHub, etc.) are stored in a custom text area sh_social_links__c as a semicolon-delimited URL list. The LinkedIn UID from SignalHire is preserved in sh_linkedin_uid__c for reference.

SignalHire talent pools and lead lists represent a many-to-many membership relationship between profiles and named lists. Bullhorn has no native equivalent for named prospect lists as a standalone object type. We resolve this by either creating a Bullhorn CustomObject (CustomObject1) to store list membership as records with a lookup to Candidate plus a listName field, or by using a Candidate custom picklist field (sh_talent_pool__c) with multi-select values for list membership. The choice depends on the number of lists and the expected query patterns. During import, we reconstruct each list by resolving the SignalHire profile UIDs to Bullhorn Candidate IDs and writing the membership records. If CustomObject is chosen, Bullhorn Support ticket is required to provision the custom object before migration begins.

SignalHire's per-email deliverability scoring (Valid, Risky, Unknown) has no native Bullhorn equivalent. We create custom fields sh_email1_status__c, sh_email2_status__c, and sh_email3_status__c on the Candidate entity as picklist fields with those three values. This allows Bullhorn admins to filter candidates by email quality for outreach prioritization or suppression. The custom fields are deployed via Bullhorn metadata API or Admin Field Mappings before the Candidate import begins.

SignalHire's phone verification confidence (high/medium/low or numeric score) is preserved in custom fields sh_phone1_confidence__c and sh_phone2_confidence__c on the Candidate entity. Bullhorn does not have a native confidence scoring model for phone numbers, so this is a custom field configuration. The confidence value is stored as text to accommodate both numeric scores and label-based confidence tiers depending on what SignalHire returned for each record.

SignalHire company profiles include a size range (e.g., 51-200 employees) rather than a precise headcount. Bullhorn's ClientCorporation.numberOfEmployees field is an integer field. We map SignalHire's size range to a custom picklist field sh_company_size_range__c on ClientCorporation to preserve the original granularity, and we optionally populate numberOfEmployees with the midpoint of the range as an approximate integer for reporting purposes. The custom field is created before the company import phase.

If the SignalHire profile includes multiple employment periods (past job titles and employers), these map to Bullhorn's CandidateEmployment sub-entity on the Candidate record. Each employment period maps: title to CandidateEmployment.title, companyName to CandidateEmployment.companyName, startDate and endDate to CandidateEmployment.dateAdded and endDate, and location to CandidateEmployment.location. Employment history is loaded after the parent Candidate record is created to satisfy the entity dependency.

The SignalHire-generated profile UID is stored in a custom field sh_profile_id__c on the Candidate record. This field is non-editable by recruiters and serves as an audit reference linking Bullhorn records back to the original SignalHire source data. It is critical for reconciliation if the customer needs to cross-reference migrated records against a future SignalHire export or if a data dispute arises post-migration.

SignalHire team member records (name, email, role) are extracted for documentation purposes only. Bullhorn User records must be provisioned through Bullhorn's own user management, not imported. We provide a team roster reconciliation document listing every SignalHire team member with their email and role so the Bullhorn admin can provision matching Users before migration begins. User-level permission structures are not exposed via SignalHire API and must be manually reconfigured in Bullhorn by the admin.