Migrate from Ashby to Bullhorn ATS & CRM

Ashby Candidate records map directly to Bullhorn Candidate. We preserve name, contact info, employment history, skills, source, and status. Ashby custom fields on Candidates map to Bullhorn Custom Object fields or native Candidate fields via Field Mappings (configured in Bullhorn Admin > Field Mappings). Bullhorn's Candidate entity supports up to 55 custom fields if a Custom Object is provisioned; we audit Ashby custom field count during scoping to determine whether native fields suffice or a Custom Object is required.

Ashby Applications (candidates linked to specific jobs) map to Bullhorn JobSubmission records. We preserve submission date, current stage, stage transition history, rejection reason, and all stage timestamps. Bullhorn JobSubmission tracks the candidate's journey through the job order pipeline and supports status flags (active, rejected, placed). Stage names from Ashby map to Bullhorn JobSubmission status values via a configurable mapping table.

Ashby Job records map to Bullhorn JobOrder. We preserve title, description, department, team, location, employment type, status (open/closed/draft), and job board distribution history. Ashby's multi-opening structure (one Job with multiple Opening slots) maps to Bullhorn's JobOrder with the opening count preserved in a custom field. Bullhorn JobOrder includes client-facing fields (Client Corporation, Client Contact, Client Job ID) that Ashby does not have; these are populated where the Ashby Job has an associated client organization or left blank for in-house-position-only migrations.

Ashby Openings (individual headcount slots within a Job) map to Bullhorn JobOrder headcount slots. Multi-opening positions require individual Opening-to-JobOrder mapping to ensure that each slot receives the correct candidate pipeline. We preserve opening status (filled, open, cancelled) and link each Opening to its parent Job in Ashby, which becomes a single Bullhorn JobOrder with multiple submissions tracked via JobSubmission.

Ashby Offers (compensation details, start dates, e-signature status, offer history) do not have a direct Bullhorn equivalent because Bullhorn's placement lifecycle begins at the placed candidate, not the offer stage. We migrate Offer data to a Bullhorn Custom Object (OfferHistory__c) with fields for compensation, start date, e-signature status, and offer-to-placement transition. Bullhorn Placements capture the placed record and ongoing assignment but not pre-placement offer details; we close that gap with the custom object.

Ashby Users (recruiters, hiring managers, admins) map to Bullhorn User records. Role assignments from Ashby map to Bullhorn permission structures (Admin, Standard). We match by email address. Bullhorn's user licensing model differs from Ashby's seat model; we document the user's Ashby role and tier so the customer's Bullhorn admin can assign the appropriate Bullhorn license (Full, Limited Recruiter, Limited Sales) during provisioning.

Ashby Interview Plans export with stage structures, stage names, and activity definitions. Automated activity triggers tied to stage entry (sending booking links, assessments, questionnaires) are tier-gated at Ashby Plus and Enterprise and do not migrate as functional rules. We deliver a written Interview Plan inventory with each stage, its associated activities, and the automation trigger (if any) documented for Bullhorn admin to rebuild in Bullhorn Automation or Bullhorn's scheduling configuration.

Ashby email Sequences (templates, stage definitions, cadence rules) export as templates and configuration notes. Live-running sequences require scoping to determine whether to migrate as templates or close them before migration. Bullhorn Automation (formerly Herefish) handles outbound cadence and candidate engagement separately from Bullhorn ATS/CRM. We do not migrate sequences as functional automations; we deliver a sequence inventory document with step definitions, timing, and action types for Bullhorn Automation rebuild.

Ashby Activities (emails, notes, calls, scorecards, meetings) map to Bullhorn equivalents. Emails migrate as Bullhorn Note records linked to the Candidate and JobSubmission; calls migrate as Note records with call-type classification; scorecards migrate as Note records with structured fields (score, criteria, feedback). Bullhorn's activity model differs from Ashby's unified activity API; we use Bullhorn's REST API to write activities as Note records with activity type, date, author, and content preserved.

Ashby custom fields on Candidates, Applications, and Jobs enumerate via customField.list. Bullhorn supports custom fields via Custom Objects (55 fields per object on Front Office Growth/Enterprise; 2 on ATS Growth). We audit the Ashby custom field inventory during scoping, group fields by entity, and determine whether native Bullhorn fields, Custom Object fields, or a combination is required. Bullhorn Field Mappings (Admin > Field Mappings) controls display behavior for native fields. Custom Objects require Bullhorn Support ticket and the Custom Object Setup Spreadsheet.

Ashby Department records map to Bullhorn Department. Department hierarchy and department-level permissions are preserved in the migration. Bullhorn's department structure supports reporting and security group assignment at the department level.

Ashby Team records within departments map to Bullhorn Team. Team assignments on jobs and users are preserved. Bullhorn Teams manage recruiter workload distribution and can be assigned to JobOrders for routing.

Ashby Assessments from integrations like HackerRank and CoderPad link to Ashby but live in third-party systems. We export assessment results attached to Applications and map the association as a Note on the Bullhorn JobSubmission, with the assessment type, score, and external link preserved. The assessment tool itself requires reconnection as a new integration in Bullhorn.

Ashby Report definitions export as CSV via the report endpoint, including funnel analytics, pipeline metrics, and time-to-hire data. Bullhorn configurable reports and performance dashboards require rebuild post-migration. We export all available report data as CSV and deliver a report inventory with the Ashby report name, metric definition, and recommended Bullhorn report equivalent (BH Analytics, configurable reports, or third-party BI tool). Dashboard layouts do not export via API from Ashby and are documented as a manual rebuild checklist.