Migrate from iCIMS Talent Cloud to Bullhorn ATS & CRM

iCIMS Person Profile records map to Bullhorn Candidate records with standard field mappings: first name, last name, email, phone, address, and employment history. We extract custom fields via the iCIMS Schema API using the numeric field identifier and map them to Bullhorn custom fields on the Candidate object. The iCIMS external ID (unique ID assigned during export) becomes the Bullhorn Candidate externalID for deduplication. Resume files attach to Bullhorn Candidate as parsed attachments with the original file name preserved. Note that iCIMS AI Talent Discovery Role Fit scores and tier levels do not have a native Bullhorn equivalent; we store the tier (e.g., Tier 1 Role Fit) in a custom Candidate field icims_role_fit_tier__c.

iCIMS Job Profile records map to Bullhorn JobOrder. We map title, department, location (city/state/country), employment type (full-time, contract, etc.), and the job description. The iCIMS Job Profile's associated hiring workflow (pipeline stages and routing rules) becomes a Bullhorn Placement Workflow on the JobOrder; we create the placement track and stage mapping during Bullhorn configuration. JobOrder status in Bullhorn (Open, Placed, Closed) maps from iCIMS Job Profile status. Published job board distribution settings from iCIMS are noted for manual reconfiguration in Bullhorn.

iCIMS Submittals represent the association between a Person Profile and a Job Profile at a specific pipeline stage. We map Submittal records to Bullhorn JobSubmission with three required lookups: Candidate (from the mapped Person Profile), JobOrder (from the mapped Job Profile), and the submitting recruiter User. The Submittal status (Applied, Phone Screen, Interview, Offer, Hired, Rejected) maps to Bullhorn JobSubmission status with a custom field icims_submittal_status__c preserving the original iCIMS stage name. Submittal routing history migrates as a custom text field recording each stage transition with timestamp.

iCIMS Company profiles (distinct from candidate employer history) map to Bullhorn ClientCorporation records. Standard fields include company name, industry, size, address, and website. The iCIMS Company external ID becomes the Bullhorn ClientCorporation externalID for deduplication. Bullhorn ClientCorporation supports custom fields for any extended company attributes stored in iCIMS. Note that iCIMS Company records used in the context of candidate employer history (previous employment) migrate as part of the Candidate work history section rather than as ClientCorporation.

iCIMS Offer records containing compensation details (salary, start date, offer status, bonus, equity) map to Bullhorn custom fields on the JobOrder or a custom Offer object depending on the Bullhorn edition in use. Bullhorn ATS Growth (limited to 2 custom objects) may require storing offer data as custom fields on JobOrder or Placement rather than a dedicated Offer object. We create the destination custom fields before migration and map compensation data accordingly. Offer status (Accepted, Declined, Withdrawn, Pending) migrates as a picklist field.

iCIMS Onboard records tracking post-hire onboarding activity, document completion, and employee setup map to Bullhorn Placement. Bullhorn Placement stores the placed candidate, the related JobOrder, start date, pay rate, and bill rate. Onboard completion status and document flags migrate as custom fields on Placement. Bullhorn's onboarding document management (for I-9s, tax forms, background checks) does not natively import iCIMS Onboard document records; we migrate document file references and names as custom fields and advise the customer's Bullhorn admin to re-upload the actual files post-migration.

iCIMS Talent Pools containing AI-tiered groupings of candidates organized by skill match and engagement scoring map to Bullhorn Lists. Pool membership migrates as List membership records with each Candidate linked to the relevant Bullhorn List. The iCIMS Role Fit tier (Tier 1, Tier 2, Tier 3) and AI-calculated Role Fit score migrate as custom fields on the Candidate record (icims_role_fit_tier__c and icims_role_fit_score__c) rather than as a native scoring system. If the customer has multiple Talent Pools per candidate, each pool becomes a separate Bullhorn List and the candidate belongs to all applicable lists.

iCIMS custom fields carry a numeric internal identifier alongside the attribute name. During migration, we read the full custom field schema via the iCIMS Schema API to capture both the field label and the numeric ID. Bullhorn custom fields are created in the destination org with names matching the iCIMS field label (sanitized for Bullhorn API naming conventions). We map the numeric internal ID as a custom field icims_custom_field_id__c on each Bullhorn custom field for audit traceability. Bullhorn ATS Growth edition limits custom objects to 2; if the customer uses Bullhorn ATS Growth, custom field migration is scoped to the most business-critical fields and remaining fields are documented for manual recreation.

iCIMS Hiring Workflows define the pipeline stages and routing rules for a Job Profile. Workflow configurations are specific to each iCIMS instance and may use custom stage names and approval chains. We extract the full workflow definition including stage names, transition rules, and approval requirements via the iCIMS API and document it in a written Workflow Inventory. Bullhorn uses Placement Workflows and Placement Tracks to define the stages a placement moves through. We map each iCIMS workflow to a Bullhorn Placement Track and document the stage-to-stage mapping. Approval chains do not migrate automatically; the customer's Bullhorn admin configures Bullhorn Workflow Automation rules as a post-migration step.

iCIMS iForms are electronic documents completed by candidates or employees — I-9s, background check authorizations, new-hire paperwork. iForm data must be retrieved by the completed form's ID in iCIMS; the standard data migration export does not bundle iForm PDF files automatically. We retrieve completed iForm records by their completed ID, extract the form field values, and map them to Bullhorn custom fields on the Candidate record. The actual iForm PDF files are attached to the Bullhorn Candidate record as documents. We flag any iForms that cannot be retrieved by ID due to data retention or access restrictions and document them in the iForm inventory for manual retrieval by the customer's iCIMS admin.

iCIMS Connect Events log candidate engagement activities — email opens, career site visits, chatbot interactions, career site page views, and email link clicks. The connectevent profile type is documented in the iCIMS Schema API. Bullhorn Activity records (Task with TaskSubtype variants) store recruiter-initiated activities on a Candidate, but iCIMS Connect Events representing passive candidate behavior (site visits, email opens) do not have a direct Bullhorn equivalent. We migrate email engagement events as Bullhorn Activity records with a custom type icims_connect_event__c and the engagement detail stored in the Activity description or custom fields. Career site visit and chatbot interaction data migrates as a summary Activity record with the count and date range rather than individual event records.

Referral tracking in iCIMS logs the source of contacts who were referred by existing employees. Referral attribution data attached to Person Profiles (referrer name, referral source, referral date) migrates to Bullhorn Candidate records via custom fields (icims_referral_source__c, icims_referrer_name__c) and the Bullhorn standard source field. We extract referral metadata from the Person Profile during scoping and map it to the corresponding Bullhorn Candidate custom fields. The Bullhorn standard Candidate source picklist (Employee Referral, LinkedIn, Job Board, etc.) is mapped where the iCIMS referral type matches a Bullhorn standard source value.