Migrate from TRAFFIT to Bullhorn ATS & CRM

TRAFFIT Candidate records map directly to Bullhorn Candidate. We extract first name, last name, email, phone, location, tags, talent-pool status, and custom field values from the TRAFFIT API or filtered XLS export. Soft-deleted candidates require an explicit active-record filter; TRAFFIT's default export may include soft-deleted records which we exclude before import. Bullhorn's Candidate entity stores resume content, skills, and availability alongside contact fields.

TRAFFIT applications link a candidate to a job with a stage, source attribution, and timestamp. Bullhorn does not have a native application object separate from Candidate and JobOrder; we create a custom Candidate_Submission__c object to preserve the job-to-candidate association, stage history, source label, and application date. Where Bullhorn's Candidate_Submission__c is already provisioned, we map into that existing custom object.

TRAFFIT Jobs map to Bullhorn JobOrder. The job title, description, requirements, status, assigned user, and client reference all transfer directly. TRAFFIT's pipeline stages (from application to hire) map to Bullhorn JobOrder status values or a custom status field. Client assignment in TRAFFIT's job record resolves to the corresponding ClientCorporation in Bullhorn at migration time.

TRAFFIT Adverts are job-listing records with publication dates, board assignments, and status. We split advert data into the Bullhorn JobOrder (core job content and internal status) and a custom JobBoardPosting object or Bullhorn JobBoardPosting if the module is provisioned, capturing board name, publication date, and advert status. Where Bullhorn's job-board module is not included in the subscription, advert status is recorded in a custom field on JobOrder.

TRAFFIT maintains a separate CRM Persons object for contacts outside the recruitment funnel. Bullhorn separates companies (ClientCorporation) and individuals (ClientContact) as two linked records. We merge each TRAFFIT CRM Person into a ClientContact and derive the ClientCorporation from the CRM Person's company association, creating the parent corporation record if it does not exist. Custom fields on TRAFFIT CRM Persons map to custom fields on ClientContact.

TRAFFIT user records (role, email, active status) map to Bullhorn BullhornUser entities. Hiring Manager accounts (free-tier in TRAFFIT) map to Bullhorn Employee module records with limited permissions. We resolve TRAFFIT owner references on candidate and job records to Bullhorn User IDs by email match during migration. Any TRAFFIT owner without a matching Bullhorn User is placed in a reconciliation queue for the customer's admin to provision before record import resumes.

TRAFFIT tags serve both candidate categorization and talent-pool segmentation. We preserve tag names and talent-pool membership as Bullhorn CandidateTag records linked to Candidate. Talent-pool status (active, passive, sourced) is stored in a custom field on Bullhorn Candidate. Where the destination Bullhorn instance uses a different tagging taxonomy, we apply a mapping table documented during scoping.

TRAFFIT custom fields on Candidates, Jobs, and CRM Persons require pre-creation in Bullhorn before any data import. We validate field types from the TRAFFIT API schema against actual record values during the data audit phase, flag any type-mismatch records, and create Bullhorn custom fields with matching types (text, number, picklist, checkbox, date). Required-flag settings and restricted-editing configurations are replicated at the Bullhorn field level. Field type changes made mid-use in TRAFFIT may cause type-incompatible values that we flag for manual review before import.

Resume files, cover letters, and uploaded documents attached to TRAFFIT candidate profiles export with their file associations. We transfer files as Bullhorn Candidate attachments linked by candidate ID. Bullhorn's storage limits and attachment size caps vary by tier; we verify available storage during scoping and flag any records requiring file compression or document-type prioritization. Files without a valid candidate match go to a review queue.

TRAFFIT consent records track when candidates gave or withdrew permission for data processing, with timestamps per consent type. We export consent timestamps and type labels, then map to a Bullhorn custom consent object or compliance fields on Candidate (HasOptedOutOfEmail, custom consent date fields). If the TRAFFIT GDPR Assistant add-on has automated anonymization scheduled, we check during discovery whether anonymization has already run, which may leave consent records partially redacted. Any gaps are documented in the consent handoff report.

TRAFFIT tracks the origin of each application (job board, referral, direct, sourcing tool). We export source labels and attribution data and apply them as a custom picklist value on the Candidate_Submission__c record. Bullhorn's standard source taxonomy differs from TRAFFIT's; we create a mapping table during scoping that collapses or renames TRAFFIT source labels to match Bullhorn's allowed values.

TRAFFIT candidate activity records — calls logged, notes added, stage-change events, and internal comments — are stored in TRAFFIT's internal event system and are not exposed via API or XLS export. We do not migrate activity timelines as there is no stable export path. We disclose this limitation explicitly in scoping and scope only objects with confirmed export routes: candidate profiles, applications, jobs, adverts, CRM persons, tags, and GDPR consents. The customer should plan to rebuild candidate interaction notes as Bullhorn Task records or Note attachments post-migration.