Migrate from HigherMe to Bullhorn ATS & CRM

HigherMe job postings (title, description, location, screening questions, fit-score weighting, and job board distribution status) map to Bullhorn JobOrder records. The HigherMe store identifier maps to a custom JobOrder field store_id__c that we create during schema setup. Bullhorn JobOrder is the primary record type for publishing; we map the job title, description, and address fields directly. Screening question configuration does not migrate as Bullhorn Intake Forms; we document the screening question set as a custom field group for the Bullhorn admin to rebuild in Bullhorn's intake form builder.

HigherMe's unified Candidate record, which aggregates all applications across jobs and locations for the same individual, maps to Bullhorn Lead for candidates not yet placed and Bullhorn Contact (attached to a Bullhorn Corporate record) for candidates who have been hired or have an active placement. We split at migration time using the HigherMe application status field. Name, email, phone, work authorization status, and geographic distance from the job location transfer as standard Bullhorn fields. The candidate's original HigherMe candidate ID is preserved in a custom field higherme_candidate_id__c for reconciliation.

Each HigherMe Application (a candidate's response to a specific job posting) maps to a Bullhorn Candidate record with the JobOrder reference stored in a custom field originating_job_id__c. Application-level data including availability windows, screening question answers, fit-score output, and application source channel transfer as custom fields. The application status (applied, interviewed, offered, hired, rejected) maps to a Bullhorn Candidate custom status field migration_status__c because Bullhorn Candidate status follows a placement-centric model that does not match HigherMe's hiring-pipeline stages.

HigherMe fit scores (0-100, computed per application from availability match, distance from location, and screening question responses) map to a Bullhorn Candidate custom numeric field fitscore__c that we create on the Candidate entity during schema setup. Bullhorn does not have a native fit-score model; this field is informational and used for sorting during reconciliation. We preserve the fit-score weighting configuration as a migration artifact document for the Bullhorn admin if they want to implement equivalent scoring in Bullhorn Amplify or a custom Flow.

HigherMe custom screening questions per job (single-choice, multi-choice, and free-text types with weighted scoring) map to Bullhorn Candidate custom fields. Each screening question becomes a custom field named with the pattern sq_question_<number>__c using the appropriate Bullhorn field type (picklist for single/multi-choice, text area for free-text). The weighted scoring configuration is preserved as a field description and migration artifact; Bullhorn does not natively compute weighted screening scores, so the customer admin configures any automated scoring in Bullhorn Workflows post-migration.

HigherMe 30-second video cover letters stored as hosted media URLs migrate to a Bullhorn Candidate custom URL field video_url__c. Bullhorn does not host video content natively. We preserve the URL reference and duration metadata as a text field video_duration__c. Candidates with video applications should be notified that re-recording in Bullhorn's supported format may be required for active recruitment campaigns; we flag this in the cutover handoff document.

HigherMe store locations (address, store identifier, and manager assignment) map to Bullhorn ClientCorporation records with a custom field store_id__c matching the HigherMe location identifier. The first Candidate migration pass uses store_id__c to route applicant records to the correct ClientCorporation. Bullhorn does not have a native multi-location hierarchy; franchise customers using Bullhorn Corporate typically configure a ClientCorporation per store or per region depending on reporting needs. We document the location inventory during scoping and coordinate the structure with the customer's Bullhorn admin before migration.

HigherMe WOTC eligibility questionnaire responses and associated tax credit data attach to the candidate record. We migrate the questionnaire answers as a set of custom Candidate fields (wotc_eligible__c as checkbox, wotc_questionnaire_blob__c as long text) and the eligibility flag as wotc_status__c. Bullhorn Custom Objects (available from Bullhorn ATS Growth tier with 2 objects or Bullhorn Front Office Growth/Enterprise with 10 objects at 55 fields each) are the supported way to capture structured WOTC data if the customer needs a dedicated record type. We recommend the Custom Object approach for customers with high WOTC claim volume. Note that WOTC eligibility is US-specific and has no equivalent in non-US Bullhorn deployments.

HigherMe interview scheduling (date/time, interviewer assignment, interview type: phone, video, in-person) maps to Bullhorn Task records with TaskSubtype set appropriately. Interviewer assignment resolves by email against Bullhorn User records. Interview notes and structured feedback attached to the application migrate as separate Task records with a custom field feedback_type__c. The interview event status (scheduled, completed, cancelled) maps to the Task Status field.

HigherMe manager notes and structured feedback attached to applications (free-text with author and timestamp) map to Bullhorn Note records linked via ContentDocumentLink to the parent Candidate record. Multi-author notes maintain the original author as a Note custom field. Bullhorn's Note object supports rich text; we preserve formatting where present in the source.

HigherMe background check results flow through integrated third-party providers (First Advantage and similar) and are not stored as readable records within the HigherMe ATS API. We do not migrate background check data. We document the provider name and the date of the last check for each candidate with an active check on file as a migration artifact. The customer coordinates re-initiating background checks in Bullhorn or their preferred third-party provider post-migration.

Post-hire onboarding documents, I-9 forms, and new-hire paperwork live in HigherMe HR Software, which is a separate product tier from the ATS. These records are not accessible via the HigherMe ATS API and fall outside our migration scope. We flag this boundary upfront during scoping. If the customer requires onboarding continuity, they should plan a parallel HR migration or accept manual re-documentation for new hires. Bullhorn Back Office (when licensed) handles post-placement onboarding workflows but does not import I-9 document blobs from HigherMe.