Migrate from iTrent to Bullhorn ATS & CRM

iTrent Employee records split into Bullhorn Candidate (for workers who are candidates for roles) and Contact (for client companies, hiring managers, and HR administrators stored in iTrent). We use the employment_status, employee_type, and department fields from iTrent to route each record: internal employees become Bullhorn Candidates with a custom field employment_type__c; external contacts from iTrent's third-party or contractor lists become Bullhorn Contacts. Name, email, phone, address, and right-to-work fields map directly to Bullhorn's standard Candidate and Contact field names. NI numbers map to a custom Candidate field national_insurance__c for compliance reference.

Where iTrent stores organisations as employer entities and the migration scope includes multi-company or multi-entity configurations, iTrent employer companies map to Bullhorn Client Corporation records. The iTrent company_name and registration_number map to Bullhorn name and billingAddress respectively. This mapping applies when the migration moves an internal HR team onto Bullhorn CRM to track client relationships alongside internal workforce data.

iTrent payroll history is stored as cyclical pay-period rows with earnings codes, deductions, tax codes, BACS references, and net pay. Bullhorn has no native payroll object on the ATS/CRM tiers. We create Bullhorn Custom Objects named itrent_payroll_history__c and itrent_payslip__c scoped to the Candidate record, with fields for pay_period, earnings_gross, tax_deducted, national_insurance_employee, national_insurance_employer, pension_contribution, net_pay, and bacs_reference. We snapshot at the nearest pay-period boundary to avoid split-cycle records and flag any in-progress period for manual confirmation post-migration.

iTrent leave-year configurations, entitlement balances, and absence events have no Bullhorn native equivalent. We create a Bullhorn Custom Object itrent_absence__c scoped to Candidate with fields for leave_type, entitlement_total, entitlement_used, entitlement_remaining, accrual_rate, and leave_year_end. Active absence events at migration time are inserted as records with status in_progress. Completed absence cycles are migrated as historical records. Leave-type picklist values (Annual Leave, Sick Leave, Carers Leave, etc.) are recreated as Bullhorn custom field dropdowns before import.

iTrent benefit elections (private medical, life assurance, cycle-to-work, voluntary benefits) and auto-enrolment pension data map to a Bullhorn Custom Object itrent_benefits__c scoped to Candidate. Auto-enrolment pension staging and contribution rate history migrate as separate records within the object with fields for pension_scheme, staging_date, contribution_employee_percent, contribution_employer_percent, and opt_out_date. Voluntary benefits and salary sacrifice schemes migrate as benefit_type and employee_contribution fields. Benefit provider links are stored as text fields pointing to the external provider reference.

iTrent document repository stores contracts, offer letters, and policy documents. We export file blobs alongside their metadata and ingest them into Bullhorn's ContentDocument system, linking each document to the relevant Candidate or Contact record via ContentDocumentLink. File type, original upload date, and document category migrate as ContentVersion fields. Bullhorn's 60 MB per file limit applies; documents exceeding this are flagged for manual splitting or alternative storage before migration.

iTrent departments, cost centres, locations, and reporting lines map to Bullhorn Client Corporation (for employer entities) and custom fields on Candidate (for internal org structure). The reporting_line from iTrent maps to a custom Candidate field manager__c which we resolve to a corresponding Candidate record by email match. Cost centre codes migrate as text fields on the Corporation record for financial reporting alignment.

iTrent ESS portal configuration determines which fields employees can view and update. Bullhorn ESS does not replicate this model. We extract the ESS-visible field list and permission structure from iTrent during scoping and deliver it as a written configuration inventory noting which Bullhorn standard or custom fields provide equivalent visibility for candidate-facing ESS on the Bullhorn Recruitment CRM platform. Salary display values derived from user calculations in iTrent ESS are flagged as display-derived data requiring manual reconciliation in Bullhorn.

iTrent performance review cycles, objectives, and competency ratings migrate to Bullhorn Custom Objects. We create itrent_review__c (for review cycle metadata) and itrent_objective__c (for individual objectives linked to the review) scoped to Candidate. Custom rating scales from iTrent are mapped explicitly to numeric values with a translation table because Bullhorn does not support arbitrary rating scales natively. Reviewer assignments migrate as linked Contact records.

Where iTrent stores vacancies, applications, and onboarding tasks (typically for organisations that use iTrent's optional recruitment module), these map to Bullhorn Job Order, Job Submission, and Onboarding (via Bullhorn Onboarding, formerly Able Teams WFM). Active vacancies migrate as Bullhorn Job Order records with status migrated; pending onboarding tasks migrate as Bullhorn Onboarding checklist items linked to the Placement record. Completed workflows are flagged as closed in Bullhorn with a status reason field carrying the original completion date.

iTrent user-defined salary and benefit calculation rules are platform configuration rather than data records. We extract them as structured artefacts during scoping and deliver a written inventory mapping each calculation to either a Bullhorn Custom Object field formula (if the calculation can be expressed as a formula field) or a manual reconciliation note for the customer's HR admin. Rules that depend on historical payroll outputs are flagged for compensation review before Bullhorn go-live.

iTrent conditional approval chains and authorisation rules are platform configuration extracted by MHR during the discovery phase as workflow XML or equivalent artefacts. Bullhorn Automation (formerly Herefish) handles workflow and task automation differently. We do not migrate workflows as code. We deliver a written inventory of every iTrent approval workflow with its trigger conditions, routing rules, and action types, plus a recommendation for Bullhorn Automation equivalents where the customer licenses that add-on. The customer's Bullhorn admin or a Bullhorn partner rebuilds approval logic post-migration.