Migrate from Yello to Bullhorn ATS & CRM

Yello Candidate records map to Bullhorn Candidate. Standard fields (name, email, phone, address, source, pipeline stage, tags) migrate directly. Any custom Candidate properties discovered during the custom field audit phase map to Bullhorn custom fields on the Candidate entity or to Bullhorn Custom Objects (customObject1s-customObject10s) if the customer is on Front Office Growth/Enterprise tier. Candidates without an email are flagged in a deduplication pass because Bullhorn uses email as the primary Candidate dedupe key. Tags from Yello map to Bullhorn Tags (category, skill, school) via the tag relationship in Bullhorn's Candidate schema.

Yello Job Requisitions map to Bullhorn JobOrder records. Requisition metadata (title, department, location, headcount, status, employment type) migrates directly to corresponding JobOrder fields. The Requisition-to-Candidate association migrates as JobSubmission records in Bullhorn, preserving the applicant relationship. JobOrder's status field maps from Yello's Requisition status (Open, Closed, On Hold) to Bullhorn's jobStatus values.

Yello Campus Events spanning multiple days require flattening. Yello exports a multi-day Event as a single record with a start date and end date. We parse the date range, split into individual day records, and write each as a separate Bullhorn Event. If the destination Bullhorn edition supports Custom Objects, we create a parent Event Custom Object (customObject1) to link the daily records back to the original Event for reporting. Registration lists and Candidate attendance records migrate as EventAttendee or custom Event registration records.

Yello Evaluations are structured feedback records tied to a Pipeline Stage including scores, comments, and evaluator attribution. Bullhorn does not have a native evaluation form object below the Front Office tier, so we evaluate the customer's Bullhorn edition during scoping. For Front Office Growth/Enterprise, Evaluations map to a Bullhorn Custom Object (customObject2) with numeric score fields, comment body, evaluator name, and timestamp. For Bullhorn ATS tier, Evaluations map to the Candidate Scorecard feature. Custom evaluation forms with non-standard field names require a pre-migration field-mapping table generated from the Yello export sample.

Yello Pipeline Stages (configurable stage names and ordering) map to Bullhorn's Placement Track stages or to a Bullhorn Custom Object (customObject3) representing the customer's Yello-specific hiring workflow. Stage ordering is preserved by writing stages in ascending position order. We validate that the stage names in the export are supported by Bullhorn's jobStatus and placementStatus picklists or document any custom status values requiring Bullhorn Support to add.

Yello Notes (free-text commentary attached to Candidates or Requisitions) migrate to Bullhorn Note records linked via ContentDocumentLink to the parent Candidate or JobOrder. Note body migrates as plain text. Author and timestamp preserve. Bullhorn Note records display in the Candidate and JobOrder activity timeline alongside Tasks and Emails.

Yello flexible label system (Candidates tagged by school, degree, role, recruiting season) migrates to Bullhorn Tags. Bullhorn stores Tags as a separate entity linked to Candidate and JobOrder via the tag relationship. We extract the flat tag list from Yello and create corresponding Tag records in Bullhorn before attaching them to Candidates. Tags that do not exist in Bullhorn are created during migration.

Binary files associated with Candidates including resumes, cover letters, and portfolio items migrate as Bullhorn ContentDocument records attached to the Candidate via ContentDocumentLink. The original filename and file blob preserve. Bullhorn's resume parsing runs on ingestion, extracting structured fields (skills, experience, education) from the uploaded document. We migrate the blob first, then trigger Bullhorn's parse action if enabled on the customer's tier.

Yello internal recruiter and admin user accounts map to Bullhorn User records. We resolve by email match. Owner references on Candidate, JobOrder, and other records migrate by resolving the Yello user ID to the Bullhorn User ID via the User mapping table. Any Yello user without a matching Bullhorn User goes to a reconciliation queue for the customer's admin to provision before record import resumes.

Yello custom Candidate properties discovered during the discovery phase map to Bullhorn Candidate custom fields (standard field type: text, number, date, picklist, checkbox) or to a Bullhorn Custom Object (customObject1) if the customer's edition limits standard custom fields. We generate a field-mapping table covering field name, data type, and target Bullhorn field API name before any data writes. Custom field discovery must complete before migration scoping because missed custom fields appear as unmapped blanks in Bullhorn and require a correction pass.

Yello custom Requisition properties map to Bullhorn JobOrder custom fields or to a Bullhorn Custom Object (customObject4) if the destination edition limits standard JobOrder extensions. Multi-select picklist values from Yello map to Bullhorn picklist fields with values created in advance via Bullhorn Support if the values do not already exist in the target org's value set.

The many-to-one relationship between Yello Requisitions and Candidates (a Candidate can apply to multiple Requisitions) maps to Bullhorn JobSubmission records. Each JobSubmission links a Candidate to a JobOrder and captures application status, submission date, and source. We preserve the application status from Yello (Applied, Screening, Interview, Offer, Rejected) as JobSubmission status values.