Migrate from Greenhouse to Bullhorn ATS & CRM

Greenhouse Candidate records map to Bullhorn Candidate. We preserve all standard fields (firstName, lastName, email, phone, social URLs) and custom field values across Greenhouse value types (single_select, multi_select, currency, date, user reference). Phone number formatting is normalized to E.164 before insert. Tags migrate as Bullhorn Tags. Active candidate records require manual export from Greenhouse for bulk import if the customer is on Core tier; Plus and Pro customers can use the Greenhouse bulk import method guided by our exported CSV template.

Greenhouse Application records (linking Candidate to Job) map to Bullhorn JobSubmission. We preserve application date, rejection or hire status, current stage, and all stage history timestamps. Rejection reasons migrate to a custom field on JobSubmission. The migration of interviewer feedback and notes requires a separate decision: either entered in the bulk import spreadsheet at import time or added manually post-import; Greenhouse's documentation states this is a customer-performed step.

Greenhouse Job records map to Bullhorn JobOrder. We preserve job title, department, office location, open/closed status, opening date, and job description. Job posting URLs migrate as reference links rather than republished postings. Bullhorn JobOrder has a different stage model from Greenhouse: Greenhouse stages are application-stage steps while Bullhorn stages track placement workflow. We map Greenhouse stages to Bullhorn JobOrder status values and document any unaligned stage names for the customer's Bullhorn admin to configure post-migration.

Greenhouse scorecards are nested objects under Applications containing structured evaluator ratings and interview kit questions. Bullhorn has no native scorecard entity. We flatten each scorecard into named custom fields on the Candidate or JobSubmission record: one field per rating (e.g., technical_skills_rating, communication_rating) and one field for overall recommendation. We use Bullhorn's custom field API (customObject1s through customObject10s or custom fields on Candidate) based on the customer's Bullhorn edition. The interview kit structure (questions, rubric, scoring scale) is preserved as a JSON blob in a long-text custom field for admin reference. Scorecard migration requires Bullhorn Support to create any custom fields beyond standard Candidate fields.

Greenhouse Offers store compensation packages attached to an Application: start date, salary, equity, and custom offer fields. Bullhorn has no native offer entity for the ATS tier; offers are tracked through custom fields or, in Bullhorn Growth/Enterprise, through custom objects. We migrate start date, base salary, equity values, and custom offer fields into Bullhorn custom fields on JobSubmission. Bullhorn Support must create these custom fields before migration. Offer status (pending, accepted, declined, retracted) migrates as a picklist field.

Greenhouse Users (recruiters, hiring managers, admins) map to Bullhorn User records. We resolve owners by email match against the Bullhorn destination org. Users without a matching Bullhorn User go to a reconciliation queue for the customer's Bullhorn admin to provision. Role and permission mapping (Greenhouse permission levels to Bullhorn role-based security) is documented in the migration scope but not enforced programmatically.

Greenhouse custom fields across all value types (short_text, long_text, yes_no, single_select, multi_select, currency, number, date, url, user_reference) migrate to Bullhorn equivalent field types. Bullhorn editions limit custom objects: ATS Growth = 0, Bullhorn ATS = 2 custom objects (55 fields each), Growth/Enterprise = 10 custom objects (55 fields each). We validate the customer's Bullhorn edition during scoping and route custom field mapping accordingly. Fields beyond the custom object limit require the customer to upgrade their Bullhorn edition before migration.

Greenhouse's flat Office/Department structure (Core tier) maps to Bullhorn's Category or Business Sector taxonomy. Greenhouse's hierarchical tiered offices and departments (Plus/Pro) have no direct Bullhorn equivalent and require flattening into a single-level structure or a custom object hierarchy. We flag tiered structures during scoping and document the flattening strategy for the customer's Bullhorn admin to configure.

Resume files, cover letters, and portfolio attachments on Greenhouse Candidates and Applications migrate as Bullhorn Attachment records linked to the corresponding Candidate. We handle file type detection, preserve file names, and map binary blobs to Bullhorn's attachment storage. Bullhorn's file size limits apply (typically 25 MB per attachment); files exceeding the limit are flagged for the customer's admin to handle manually.

Tags on Greenhouse Candidates and Applications migrate as Bullhorn Tags. Greenhouse allows unlimited tags; Bullhorn supports tags on Candidate, ClientContact, ClientCorporation, JobOrder, Opportunity, and Placement. We preserve tag labels as-is and map them to Bullhorn's tag entity. Tagset groupings from Greenhouse are not natively supported in Bullhorn and are flattened into the candidate record as individual tags.

Greenhouse tracks candidate source (referral, job board, direct apply) as a field on Application. We preserve source attribution as a custom field on Bullhorn Candidate. Sourcing campaign UTM data stored in Greenhouse custom fields migrates alongside as text fields. Source history (multiple sources per candidate over time) is preserved as a comma-separated or JSON-formatted string in the source field if Bullhorn's data model does not support multi-value source tracking.

Greenhouse pipeline stages define the hiring workflow for each Job. Bullhorn JobOrder has a stage/status model but with different semantics. We map Greenhouse stage names to Bullhorn JobOrder status values and document any stage-specific scorecards or requirements for the Bullhorn admin to recreate in Bullhorn's workflow configuration. Custom stage names and stage-dependent scorecards are preserved as metadata in our migration scope document.