Migrate from IceHrm to Bullhorn ATS & CRM

IceHrm Employee records map to Bullhorn Candidate. We map firstName, lastName, dateOfBirth, gender, maritalStatus, bloodGroup, photo, privateEmail, workEmail, and address fields to Bullhorn Candidate standard fields. The IceHrm employment_start_date maps to dateAvailable; jobTitle maps to occupation. IceHrm custom fields added to the Employee module migrate to Bullhorn Candidate custom fields (first available custom field slot). If the customer uses IceHrm for internal employees who will be placed as contractors, we discuss the candidate sourcing strategy during scoping because internal employees and external applicants may need separate data flows in Bullhorn.

IceHrm Employee records marked as admin or manager roles map to Bullhorn User (internal recruiter) records if they will use Bullhorn. We resolve by email match against Bullhorn User. User provisioning is a manual step coordinated with the Bullhorn admin before migration; we provide a mapping table identifying which IceHrm employees should become Bullhorn Users and which remain Candidate-only records.

IceHrm Departments, branches, and offices map to Bullhorn Corporation (for client organizations) and a custom Department picklist on the Candidate record for internal org structure. IceHrm company-level settings migrate as Bullhorn Corporation if the customer is a staffing agency managing multiple client accounts. Internal department hierarchy (HR, Engineering, Sales) maps to a custom Candidate field or Candidate Custom Object tracking internal org assignment.

IceHrm Job Posting records (title, description, requirements, status, branch) map to Bullhorn JobOrder. The IceHrm job_status field maps to Bullhorn status (Open, Closed, Completed). jobType maps to employmentType; salaryStart and salaryEnd map to payRate or salaryRange custom fields. We map branches and locations to Bullhorn JobOrder address and location fields. Custom job posting fields in IceHrm migrate to JobOrder custom fields up to the Bullhorn field limit.

IceHrm Application records (applicant linked to job posting with stage, interview notes, rating) map to Bullhorn JobSubmission. The IceHrm application_status maps to Bullhorn status (New, Interview, Offer, Hired, Rejected). We preserve interview dates, ratings, and notes as submission history. If IceHrm stores multiple interview rounds, each maps to a separate note or activity record on the JobSubmission. Custom application-stage fields migrate to JobSubmission custom fields.

IceHrm employee documents (contracts, certifications, ID scans, resumes) linked to Employee records migrate as Bullhorn Candidate attachments via ContentDocumentLink. We extract files individually, preserve the original file name and MIME type, and link each document to the Candidate record. Bullhorn's resume parsing processes the attached resume into structured Candidate fields (skills, employment history, education) after migration. File upload is sequential per record with MIME type validation to avoid Bullhorn's rejection of malformed attachments.

IceHrm Leave module stores leave types (Annual, Sick, Personal), accrual balances, and approved requests. Bullhorn has no native leave balance tracking. We create a Bullhorn Candidate Custom Object (LeaveBalances) with fields per leave type (leaveType, balanceDays, accrualRate, lastAccrualDate) and link each record to the Candidate. Leave request history migrates as a second Custom Object (LeaveRequests) with date range, leave type, status, and approver. Bullhorn ATS editions are limited to 2 custom objects; we discuss with the customer whether leave tracking is migration-critical or handled by a separate HRMS post-migration.

IceHrm Time & Attendance stores punch-in/out timestamps, timesheets, and overtime entries per employee. Bullhorn has no native attendance module. If historical attendance records are migration-critical, we create a Bullhorn Candidate Custom Object (TimeEntries) with date, clockIn, clockOut, hoursWorked, overtimeHours, and status fields linked to the Candidate. Bullhorn ATS's 2-custom-object limit constrains this; we recommend the customer evaluate Bullhorn Time & Expense or a dedicated time-tracking integration for ongoing needs and treat historical data as an audit archive rather than a live-functional migration.

IceHrm Payroll stores salary components, pay schedules, and payroll run history. Bullhorn's native payroll (Bullhorn Connexys, Bullhorn Onboarding) handles time tracking and onboarding billing but is not a full payroll engine. We migrate the most recent payroll run summary (current salary, payFrequency, payGrade, lastPayDate) to a Bullhorn Candidate Custom Object (PayrollSummary) for audit and record continuity. Detailed payroll run history (per-pay-period earnings, deductions, tax withholdings) requires a separate payroll system and is documented as out-of-scope for Bullhorn migration; we recommend HRIS integrations like Gusto, ADP, or Paychex for ongoing payroll management.

IceHrm Performance Reviews store review cycles, templates, ratings, and peer feedback per employee. Bullhorn has no native performance review module. We create a Bullhorn Candidate Custom Object (PerformanceReviews) with reviewDate, reviewerName, overallRating, strengths, areasForImprovement, and status fields. Peer review comments migrate as long-text fields within the Review record. IceHrm custom review templates map to a templateName field; the structured template criteria migrate as separate custom fields. If the customer uses IceHrm for annual performance management, we recommend Bullhorn's partner ecosystem (Lattice, BambooHR, Culture Amp) for ongoing performance tracking post-migration.

IceHrm Training tracks courses, enrollments, completion dates, and learning paths per employee. Bullhorn has no native LMS. We create a Bullhorn Candidate Custom Object (TrainingRecords) with courseName, enrollmentDate, completionDate, status (Enrolled, In Progress, Completed, Failed), and certificationExpiry fields. Learning path associations migrate as a text field or link to a separate TrainingPrograms Custom Object if Bullhorn's custom object budget permits. The customer should evaluate Bullhorn's integrations with LMS platforms or dedicated training systems for ongoing learning management.

IceHrm allows custom fields per module independently, meaning the Employee module and Recruitment module may have different custom field schemas. We discover all IceHrm custom fields during the pre-migration audit, map each to the corresponding Bullhorn entity (Candidate, JobOrder, JobSubmission) custom field slot, and resolve data type compatibility (IceHrm picklist maps to Bullhorn drop-down; IceHrm text maps to Bullhorn text). Bullhorn's custom field limits per entity are published in the Bullhorn KB; we verify slot availability during scoping and flag any fields that exceed the limit for customer decision on exclusion or custom object fallback.