Migrate from Happy Hire to Bullhorn ATS & CRM

Happy Hire candidate profiles (contact details, resume files, status, source attribution) map to Bullhorn Candidate records. The Candidate is the person; Bullhorn keeps Candidate records independent of specific job applications. We map Happy Hire source attribution fields to Bullhorn Candidate source fields and preserve the original Happy Hire candidate ID in a custom field hh_candidate_id__c for audit. Resume files migrate as ContentDocument records linked via ContentDocumentLink to the Candidate.

Happy Hire application records (linking a Candidate to a Job with stage and timestamp data) map to Bullhorn JobSubmission records. The JobSubmission is Bullhorn's object representing a candidate's application to a specific job order. We preserve the full application stage history including stage transitions and notes as JobSubmission status change records. The Happy Hire application date maps to the JobSubmission dateSubmitted field.

Happy Hire job records (title, description, location, department, status) map to Bullhorn JobOrder records. Active and closed jobs migrate with their current status. We remap Happy Hire job field names to Bullhorn JobOrder API field equivalents: title, description, address (for location), and status. Custom job fields from Happy Hire map to JobOrder custom fields or JobOrder customObject fields depending on Bullhorn edition and custom object provisioning.

Happy Hire application pipeline stages map to Bullhorn JobOrder status values within a configured Sales Process. We remap each Happy Hire stage name to the nearest Bullhorn-equivalent status (e.g., Applied to New, Screening to Interpreting, Interview to Interviewing, Offer to OfferExtended, Hired to Placed). Non-standard Happy Hire stage names require Bullhorn admin to add custom status values to the configured Sales Process before migration runs.

Happy Hire user accounts (name, email, role) map to Bullhorn User records. We resolve owners by email match against the Bullhorn destination org's User table. Role assignments from Happy Hire map to Bullhorn User roles or department assignments. Any Happy Hire user without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision before record import resumes.

Happy Hire post-hire Employee records (start date, department, employment status) map to Bullhorn Placement records. The Placement object is Bullhorn's representation of a candidate placed in a job and is the staffing-specific equivalent of an employee record in a recruiting context. We map Happy Hire start date to Placement dateBegin, employment status to Placement status, and department to a custom Placement field.

Happy Hire onboarding workflows (checklists and task assignments tied to new hires) export as task names, assignees, and completion statuses. Bullhorn does not have a native onboarding task object; we migrate the task data to a Bullhorn custom object (customObject1s or similar, if provisioned by Bullhorn Support before migration) linked to the Placement record. Subtask nesting may flatten during migration. We deliver a written record of the full task hierarchy for the Bullhorn admin to rebuild as a checklist in Bullhorn's native task system or a Bullhorn Marketplace onboarding app.

Happy Hire scorecard templates and completed evaluations (structured ratings and free-text notes) map to Bullhorn Candidate custom objects. Bullhorn custom objects must be set up by Bullhorn Support before migration begins; we coordinate with the customer to open a Bullhorn Support ticket early in the discovery phase. Scorecard structure migrates as the custom object definition; completed evaluations migrate as instances linked to the Candidate record. If Bullhorn Support has not yet provisioned the custom object at migration time, we hold scorecard data for a follow-on migration phase.

Happy Hire active postings to external job boards (board name and posting URL where available) map to Bullhorn JobOrder custom fields or JobOrder notes. We record which boards a job was posted to and the posting URL. Board-level analytics (click counts, application source breakdowns) do not migrate because these metrics are held by the job board platforms and are not stored in Happy Hire. We deliver a posting reinstatement checklist noting every board, job, and URL for the Bullhorn admin to re-establish after cutover.

Happy Hire source attribution fields (how a candidate entered the system) map to Bullhorn Candidate source and isHot fields. Candidate urgency flags in Happy Hire map to Bullhorn isHot boolean. We preserve the original Happy Hire candidate status field values in a custom field hh_status__c for reconciliation purposes.

Happy Hire candidate tags or category flags stored as multi-checkbox properties migrate to Bullhorn custom fields (multi-select picklist or customObject text fields). The customer's Bullhorn admin chooses the tag strategy during scoping. If tags are used for content classification, they migrate as Bullhorn Topics with TopicAssignment records.

Happy Hire jobs with active postings receiving applications during migration require a dual-write management phase. We identify open jobs at scoping, freeze Happy Hire as the write target during the cutover window, and migrate any delta applications received during migration before closing the window. JobOrder records remain Open in Bullhorn until the customer confirms the cutover is complete and new application routing is live.