HRMS migration
Field-level mapping, validation, and rollback between IceHrm and Recruit CRM & ATS. We move data and schema; workflows are rebuilt natively in Recruit CRM & ATS.
IceHrm
Source
Recruit CRM & ATS
Destination
Compatibility
4 of 12
objects map 1:1 between IceHrm and Recruit CRM & ATS.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from IceHrm to Recruit CRM is a specialized migration that crosses between a broad HRMS platform and a recruitment-agency-focused ATS. IceHrm covers the full employee lifecycle including payroll, leave, attendance, performance reviews, and training, while Recruit CRM is purpose-built for agencies managing candidate pipelines, job postings, and client relationships. The migration centers on IceHrm employee records (which become candidates in Recruit CRM) and the IceHrm Recruitment module (which maps directly to Recruit CRM's job and application objects). We flag the IceHrm modules with no Recruit CRM equivalent — payroll, leave balances, time tracking, performance reviews, and training records — during scoping so the customer decides what to archive versus migrate. Custom fields added to IceHrm modules require discovery per module before mapping begins, and document attachments on employee records are extracted individually and linked to the candidate post-import. Workflows, approval chains, and payroll configurations do not migrate; we deliver a written inventory for the customer's admin to evaluate in Recruit CRM's setup.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a IceHrm object lands in Recruit CRM & ATS, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
IceHrm
Employee
Recruit CRM & ATS
Candidate
1:1IceHrm Employee records are the primary migration object and map to Recruit CRM Candidate records. We extract the employee's full name, contact details, employment history, qualifications, and status (active, inactive, terminated) and create a Candidate record in Recruit CRM. The candidate's original hire date in IceHrm migrates as the candidate_joined_date field in Recruit CRM. Inactive and terminated employees require a scoping decision: they can migrate as candidates (archived status) or be excluded from the migration scope to keep the Recruit CRM candidate database lean.
IceHrm
Recruitment: Job Posting
Recruit CRM & ATS
Job
1:1IceHrm job postings migrate to Recruit CRM Job records. We map job title, job description, requirements, location, employment type, and department from IceHrm to Recruit CRM's job structure. If IceHrm has custom fields on the job posting module, we discover those during the audit phase and create corresponding custom fields in Recruit CRM before migration.
IceHrm
Recruitment: Applicant
Recruit CRM & ATS
Candidate (linked to Job)
1:1IceHrm applicants attached to a job posting map to Recruit CRM Candidate records linked to the corresponding Job record via the application relationship. Application stage in IceHrm (application received, screening, interview, offer, hired, rejected) maps to Recruit CRM pipeline stages. If IceHrm has custom pipeline stages, we document them and configure matching stages in Recruit CRM before the application data migrates.
IceHrm
Employee Document
Recruit CRM & ATS
Candidate Document
1:1IceHrm stores employee documents (contracts, certifications, ID scans) as file attachments linked to the employee record. We extract documents individually via the web interface or file system access on self-hosted instances, preserving the original filename, MIME type, upload date, and employee link. Each document is reattached to the corresponding Candidate record in Recruit CRM post-import. This requires file-by-file handling; there is no bulk document export in IceHrm.
IceHrm
Organization Structure (Departments, Titles)
Recruit CRM & ATS
Job Custom Fields and Tags
lossyIceHrm organizational hierarchy (departments, job titles, employment types, branch offices) maps to Recruit CRM through custom fields on the Candidate and Job objects. Department from IceHrm becomes a picklist or tag in Recruit CRM. We create the department taxonomy in Recruit CRM during configuration so the original organizational context is searchable in the candidate database.
IceHrm
Custom Fields (Employee module)
Recruit CRM & ATS
Custom Fields (Candidate)
lossyIceHrm allows custom fields to be added independently to the Employees module, meaning the same module may have different custom field schemas across two IceHrm instances. We run a custom field discovery step against the source IceHrm instance before mapping begins, capturing all extended attributes. If custom fields reference picklist values, we also extract the value options and create matching picklist values in Recruit CRM. Custom field discovery is repeated per active IceHrm module.
IceHrm
Custom Fields (Recruitment module)
Recruit CRM & ATS
Custom Fields (Job and Application)
lossyIceHrm custom fields on job postings and applicants migrate to Recruit CRM custom fields on Job and Application objects. We apply the same discovery process as the Employee module: extract schema, map field types, and create the destination custom fields in Recruit CRM before the application data migrates.
IceHrm
Leave / Time-off
Recruit CRM & ATS
Not migrated
lossyIceHrm leave management (balances, accrual rules, approval workflows, and time-off requests) has no direct equivalent in Recruit CRM, which is a recruitment and applicant tracking platform and does not include HR leave management. We do not migrate leave data to Recruit CRM. We flag this module during scoping and recommend the customer either retain the leave data in IceHrm read-only post-migration, export it as a spreadsheet, or migrate it separately to a destination HRMS if the customer is adopting Recruit CRM as their standalone ATS.
IceHrm
Payroll
Recruit CRM & ATS
Not migrated
lossyIceHrm payroll data (salary components, pay schedules, payroll run history, custom salary structures) has no equivalent in Recruit CRM. Recruit CRM does not include payroll or compensation management. We do not migrate payroll data to Recruit CRM. If the customer needs payroll continuity, we scope a separate migration to a destination HRMS platform (BambooHR, Rippling, Gusto) as an additional engagement.
IceHrm
Performance Reviews
Recruit CRM & ATS
Not migrated
lossyIceHrm performance review templates, review cycles, peer-to-peer ratings, and comments have no equivalent in Recruit CRM. We do not migrate performance review data to Recruit CRM. We export the review history as a structured CSV inventory delivered to the customer for manual re-entry or archive. Review templates are documented in the written migration inventory for the customer's admin to evaluate rebuilding in Recruit CRM's custom fields or a separate performance management tool.
IceHrm
Training / Learning Management
Recruit CRM & ATS
Not migrated
lossyIceHrm training modules (courses, enrollments, completion records, learning paths) have no equivalent in Recruit CRM. We do not migrate training data to Recruit CRM. We deliver a CSV export of completion records per employee as part of the written migration inventory. If the customer requires learning management continuity, we scope a separate migration to an LMS destination.
IceHrm
Expense Requests
Recruit CRM & ATS
Not migrated
lossyIceHrm expense requests and approval statuses have no equivalent in Recruit CRM. We do not migrate expense data. We export the expense history as a structured CSV for the customer to archive or migrate to a separate expense management platform.
| IceHrm | Recruit CRM & ATS | Compatibility | |
|---|---|---|---|
| Employee | Candidate1:1 | Fully supported | |
| Recruitment: Job Posting | Job1:1 | Fully supported | |
| Recruitment: Applicant | Candidate (linked to Job)1:1 | Fully supported | |
| Employee Document | Candidate Document1:1 | Fully supported | |
| Organization Structure (Departments, Titles) | Job Custom Fields and Tagslossy | Fully supported | |
| Custom Fields (Employee module) | Custom Fields (Candidate)lossy | Fully supported | |
| Custom Fields (Recruitment module) | Custom Fields (Job and Application)lossy | Fully supported | |
| Leave / Time-off | Not migratedlossy | Fully supported | |
| Payroll | Not migratedlossy | Mapping required | |
| Performance Reviews | Not migratedlossy | Fully supported | |
| Training / Learning Management | Not migratedlossy | Fully supported | |
| Expense Requests | Not migratedlossy | Mapping required |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
IceHrm gotchas
Self-hosted schema modifications cause migration surprises
Employee count billing model on IceHrm Cloud
Custom fields per module require manual field-level discovery
Document attachment export requires file-by-file handling
Recruit CRM & ATS gotchas
API rate limits are license-scaled and can throttle bulk migration
Custom field schemas vary per organization and require field-level mapping
Files and email attachments require separate extraction and re-upload
Email sequences and automation logic do not transfer between platforms
Pair-specific challenges
Migration approach
Discovery and module inventory
We audit the source IceHrm instance across all active modules: Employees, Recruitment, Leave, Payroll, Time and Attendance, Performance Reviews, Training, Documents, and any custom fields. For self-hosted instances, we also inspect the MySQL schema to capture any direct database modifications the customer may have made. We produce a written migration scope document that distinguishes between modules with a Recruit CRM equivalent (Employees to Candidates, Recruitment to Jobs and Applications), modules with partial equivalents (Documents to Candidate attachments), and modules with no equivalent (Payroll, Leave, Performance, Training, Expenses). The customer reviews and approves the scope before any data moves.
Data cleanup and deduplication
We run a data quality assessment on the IceHrm employee roster, identifying duplicate records, missing required fields (name, email), and inactive or terminated employees that require a scoping decision. We deduplicate the employee list before migration using a composite key of name plus email. For the Recruitment module, we audit job postings and applicants, flagging any with missing job links and duplicates across the candidate pool. Data cleanup is performed in the source IceHrm data extract before import into Recruit CRM, not after, because post-migration cleanup is three to five times more labor-intensive.
Recruit CRM schema configuration and custom field creation
We configure the Recruit CRM destination environment before any data import. This includes creating custom fields on the Candidate, Job, and Application objects that correspond to IceHrm custom fields discovered during the audit. We map IceHrm departments and job titles to Recruit CRM tags and picklists. We configure the candidate pipeline stages to match the IceHrm application stages, or document any custom stages that require new stage creation in Recruit CRM. Recruit CRM's setup is performed in the customer's live environment or a sandbox, depending on the migration agreement.
Employee-to-Candidate migration and document attachment transfer
We migrate IceHrm Employee records as Recruit CRM Candidates in dependency order: first the candidate base record (name, contact, employment status), then custom fields, then organizational context (department, title, branch). Document attachments are extracted individually from IceHrm and uploaded to the corresponding Candidate record in Recruit CRM, preserving the original filename and upload date. The customer reviews a sample of 25-50 migrated candidate records against the IceHrm source data before the full migration is committed. Any mapping corrections are applied before the remaining records migrate.
Recruitment module migration (Jobs and Applications)
We migrate IceHrm job postings to Recruit CRM Job records, mapping title, description, requirements, location, and department. For each job, we migrate the linked applicants as Candidate-to-Job applications, preserving the application stage and any application-specific custom fields. If IceHrm has custom pipeline stages, we document the full stage history and configure matching stages in Recruit CRM before the application data loads. We run a row-count reconciliation comparing IceHrm applicant records against Recruit CRM application records after migration.
Cutover, validation, and non-migrated module handoff
We freeze writes to IceHrm during cutover, run a final delta migration of any records modified during the migration window, then enable Recruit CRM as the active ATS. We deliver a written inventory document covering the non-migrated IceHrm modules (payroll, leave, performance, training, expenses), including record counts, field definitions, and export files. The customer uses this inventory to decide whether to retain IceHrm read-only, export to spreadsheets, or migrate to a separate HRMS. We support a one-week post-cutover window for reconciliation issues. We do not rebuild IceHrm workflows, approval chains, or payroll configurations in Recruit CRM; those are outside standard migration scope.
Platform deep dives
IceHrm
Source
Strengths
Weaknesses
Recruit CRM & ATS
Destination
Strengths
Weaknesses
Complexity grading
Standard HRMS migration. 1 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across IceHrm and Recruit CRM & ATS.
Object compatibility
1 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
IceHrm: Not publicly documented.
Data volume sensitivity
IceHrm doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during IceHrm to Recruit CRM & ATS migration scoping. Not seeing yours? Book a call.
Walk through your IceHrm to Recruit CRM & ATS migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave IceHrm
Other ways to arrive at Recruit CRM & ATS
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.