Migrate from Lever to Bullhorn ATS & CRM

Lever Contacts map directly to Bullhorn Candidate records. The Lever Contact ID is preserved in a custom field lever_original_id__c for audit traceability. Multi-select fields on Lever (phone type, social links) map to Bullhorn Candidate's typed multi-value fields. Every Candidate must have an Owner at insert time; we resolve the Lever Owner by email match against Bullhorn User before inserting.

This is the highest-risk mapping in the pair. A Lever Contact with three active Opportunities (three separate role applications) must become one Bullhorn Candidate record plus three JobSubmission records — one per Opportunity. We export all Opportunity records per Contact, compute the split during transformation, and insert each JobSubmission linked to the correct JobOrder. The Opportunity stage maps to JobSubmission status; the Opportunity createdAt date maps to JobSubmission dateSubmitted. If Bullhorn does not yet have the target JobOrder created, we hold JobSubmission inserts until JobOrders are loaded.

Lever Jobs map to Bullhorn JobOrder. Job title, description, department, location, and employment type transfer directly. The Lever Job opening count maps to JobOrder numOpenings. Job status (Open, Closed, Draft) maps to JobOrder status. We flag any Lever Jobs with no published posting URL and note them for manual re-posting in Bullhorn.

Lever's pipeline stages are configurable per Job. We export the full stage configuration (stage name, order, probability) and recreate it in Bullhorn as JobSubmission status values plus the corresponding pipeline stages on JobOrder. Stage probabilities migrate to Bullhorn's expectedCloseDate and stage weight fields where supported.

Lever interview records (scheduling data, interviewer assignment, interview type, duration) map to Bullhorn JobSubmission interview event entries. Bullhorn captures interview scheduling as part of the submission workflow. We preserve interviewer assignment by resolving Lever user email to Bullhorn User ID. Interview cancellation records carry as a note on the JobSubmission. Full calendar integration re-connection is a post-migration step.

Lever scorecards use a structured evaluation format tied to Opportunities. Bullhorn has no direct scorecard creation API — we import scorecard data as Bullhorn Note records with a structured label prefix (e.g., SCORECARD:) so that admins can identify and manually recreate them. The customer receives a scorecard inventory document listing every scorecard, the evaluator, the rating fields, and the recommended Bullhorn form or custom object equivalent. This is not a data loss gap — it is a known API limitation disclosed during scoping.

Lever Offer records (compensation, start date, offer status) attach to the Opportunity. In Bullhorn, offer data lives on the JobSubmission. We extract the offer fields from Lever and write them into the corresponding JobSubmission's offer fields if Bullhorn's edition supports them, or into a custom object (if Bullhorn's edition allows) or a structured note. Offer history (extended offers, counter-offers) migrates as sequential note entries.

Lever Users map to Bullhorn Users by email address. We export the full Lever user roster including name, email, role, and department. Inactive Lever users flag separately. Bullhorn requires OwnerId on Candidate and JobSubmission at insert time, so any Lever user without a matching Bullhorn User must be provisioned by the Bullhorn admin before we resume the migration batch. We provide a user reconciliation worksheet listing every unmatched owner.

Lever has no formal ClientCorporation object; client associations on Opportunities are typically stored as text fields or linked Contacts. We extract every distinct client reference from Lever records, deduplicate by client name or domain, and create Bullhorn ClientCorporation records. The corresponding hiring manager or recruiter contact on the Lever record becomes a ClientContact linked to the ClientCorporation. If the Lever data uses a Contact record as the client (rare), we treat it as a ClientCorporation in Bullhorn.

Lever custom fields on Opportunities and Contacts vary by tenant configuration. We enumerate all custom field definitions during discovery, map them to equivalent Bullhorn Candidate or JobSubmission custom fields, or to Bullhorn Custom Objects if the field count exceeds standard limits. Bullhorn ATS supports 2 custom objects; Bullhorn Growth and Enterprise support up to 10. We configure Bullhorn custom fields before data import using the Bullhorn Field Mappings admin tool or REST API.

Lever stores attachment URLs as session-linked references that expire when Lever credentials are rotated. We download all candidate CVs and attachments during the export window — before the customer rotates any Lever API keys — and re-upload files to Bullhorn Candidate records directly via Bullhorn's REST API. Bullhorn parses uploaded resumes using its built-in resume parsing. This step has a hard dependency on export completion before credential cutover.

Lever's CRM layer includes talent pool tagging and nurture campaign associations with no direct Bullhorn equivalent. We carry these as Bullhorn Tags on the Candidate record plus a custom multi-select text field candidate_talent_pool__c. Any automated sequences or nurture logic tied to these pools cannot be migrated and must be rebuilt in Bullhorn Automation (formerly Herefish) or a dedicated email cadence tool. We document every unique talent pool and nurture campaign label during discovery.

Lever interview event records capture scheduling metadata, cancellation flags, and calendar sync status. Bullhorn does not recreate calendar integrations from imported interview data. We export interview event history as supplementary notes on the JobSubmission (labeled INTERVIEW_EVENT:) and flag that interviewers must reconnect their calendar accounts to Bullhorn post-migration. New interview slots must be scheduled via Bullhorn's scheduling tool or the customer's preferred calendar integration.