Migrate from Gem to Bullhorn ATS & CRM

Gem's Candidate object (internally Prospect in Gem's UI) maps directly to Bullhorn's Candidate object. We preserve all standard fields: firstName, lastName, email, phone, LinkedIn URL, currentTitle, currentCompany, location, and the full work history and education sub-objects. Gem's linked_in_handle deduplication logic requires us to query existing Bullhorn Candidates by LinkedIn URL before insert and use update instead of create when a match is found, preventing duplicate records and preserving existing candidate data while applying new custom field values.

Gem's Projects (grouped sourcing initiatives) have no direct Bullhorn equivalent. Bullhorn Candidates support tagging and custom objects. We map Project membership to Bullhorn Candidate custom fields or a CustomObject that stores the Project name, Project status, and date-added. If Bullhorn's custom object tier limit is reached (2 on Bullhorn ATS, 10 on Front Office Growth/Enterprise, none on ATS Growth), we fall back to a multi-select picklist using the Tags field or a freeform text field. The customer chooses the strategy during scoping based on their Bullhorn edition.

Gem's candidate custom fields (single-select, multi-select, date, freeform text) map to Bullhorn custom fields on the Candidate entity or to Bullhorn CustomObject fields. Single-select and multi-select Gem fields map to Bullhorn DropDown and Multi-Select Picklist fields. Date fields map to Bullhorn Date fields. Freeform text fields map to Bullhorn Text fields but inherit Bullhorn's 255-character limit per field; fields exceeding this limit split across multiple text fields or stored in a Notes relationship. Bullhorn edition tier limits (10 custom objects with 55 fields each on Front Office Growth/Enterprise; 2 on Bullhorn ATS) are checked against Gem's custom field count before migration begins.

Gem's email, InMail, and SMS engagement records map to Bullhorn Note and Task objects. Emails migrate as Note records with the full email body and sender/recipient preserved. Calls migrate as Task with TaskSubtype = Call and duration stored in a custom Task field. Meetings and calendar events migrate as Appointment records. Each activity record links to the parent Candidate via the CandidateID field. Gem's activity timestamp preserves the original date for activity timeline ordering.

Gem's Owner records map to Bullhorn User accounts. We resolve each Gem Owner by email match against Bullhorn's User table. Any Gem Owner without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision before record import resumes. Bullhorn user roles and permissions (Recruiter, Sales, Hiring Manager, Admin) must be reconfigured at the destination because Gem and Bullhorn use different permission models.

Gem's ATS Position records (synced from linked ATS integrations) map to Bullhorn JobOrder. JobOrder title, description, status, and linked candidate associations migrate with the candidate mapping. Full ATS pipeline stage data from Gem depends on which ATS was connected; if Gem was used as the CRM layer over a homegrown or entry-level ATS, the JobOrder migration scope may be limited to whatever Gem stored.

Gem's interview data (from BrightHire integration for AI-generated scorecards or from integrated ATS tools) maps to Bullhorn Note records on the Candidate. BrightHire-specific interview scorecards may be stored in a separate Notes section if the integration was active; we migrate available interview notes and preserve interview date, interviewer name, and scorecard summary as Bullhorn Note content. Full AI-generated scorecard structure (rubric, ratings) may require a custom object if the customer wants structured data post-migration.

Gem's Candidate work history sub-records map to Bullhorn's Candidate Employment list. Each work history entry carries company name, job title, start date, end date, and description. Bullhorn supports multiple employment entries on a Candidate record with ordered display. We migrate work history entries in reverse chronological order as they appear in Gem.

Gem's Candidate education sub-records map to Bullhorn's Candidate Education list. Each education entry carries institution name, degree, field of study, graduation date, and notes. Bullhorn supports multiple education entries on a Candidate record. We preserve the full education history for compliance and client-facing candidate profiles.

Gem's Project custom fields (project-wide fields applied to all candidates in a sourcing initiative) require a dedicated Bullhorn CustomObject because Bullhorn does not have a native Project entity. If Bullhorn's CustomObject limit for the customer's edition has been consumed by other custom objects, we discuss reducing the project field scope or storing project fields as structured Note records attached to candidate groups. Project-level fields in Gem are not searchable or reportable in Gem; the customer should not expect different behavior in Bullhorn for this data.

Gem Sequences cannot be migrated because Gem does not expose sequence definitions via API. We deliver a written sequence inventory documenting each active Gem Sequence with its step count, step type (email, InMail, SMS), delay between steps, A/B test configuration (if any), and the candidate list or Project it was attached to. The inventory includes recommended Bullhorn Automation (formerly Herefish) rebuild steps for each cadence. Bullhorn Automation is a separate product licensing; the customer must ensure this is active before automation rebuild begins.

Gem's automated workflow rules (property-triggered follow-up actions, task creation, field updates) are not exposed via API and cannot migrate. We deliver a written workflow inventory with each automation's trigger condition, actions, and recommended Bullhorn equivalent. Bullhorn Automation (separate license) handles outbound cadence automations; Bullhorn Workflow Rules (native, no separate license on Corporate and Enterprise) handle record-triggered actions like task assignment, email alerts, and field updates. The customer's Bullhorn admin rebuilds these post-migration.