HRMS migration
Field-level mapping, validation, and rollback between Asanify and Recruit CRM & ATS. We move data and schema; workflows are rebuilt natively in Recruit CRM & ATS.
Asanify
Source
Recruit CRM & ATS
Destination
Compatibility
6 of 10
objects map 1:1 between Asanify and Recruit CRM & ATS.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Asanify and Recruit CRM serve fundamentally different functions. Asanify is an India compliance-first HRMS covering the full employee lifecycle from onboarding through payroll, including TDS auto-calculation, PF, ESIC, and professional tax filing. Recruit CRM is a cloud ATS and CRM built for small to mid-sized recruitment agencies, with candidate pipeline management, job ordering, and placement tracking as its core objects. There is no shared data model between these platforms. The migration is scoped to Asanify's ATS module objects (Candidates, Jobs, Applications) and to Employee records that are re-purposed as Candidate profiles. We do not migrate payroll runs, payslips, statutory deductions, leave balances, attendance records, performance reviews, OKRs, KPI trackers, expense reimbursements, or EOR assignments because Recruit CRM has no schema to receive them. We deliver a written inventory of these records so the customer's admin can decide whether to retain them in Asanify, export to a spreadsheet, or load into a dedicated HRMS at the destination.
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 Asanify 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.
Asanify
Employee
Recruit CRM & ATS
Candidate
1:1Asanify Employee records are the primary migration object when re-purposing the ATS module for recruitment use. Core fields (name, email, phone, department, employment status, start date) map to Recruit CRM Candidate fields. Employment dates become work history start and end dates. Salary revision history becomes a Compensation sub-record on the candidate, though Recruit CRM does not natively support structured compensation history, so we map the most recent salary to a custom field and flag salary ranges that require manual entry. Active vs inactive employment status maps to Candidate status in Recruit CRM. Employees with no recruitment-relevant history (pure payroll records) are excluded from the ATS migration scope and inventoried separately.
Asanify
Org Structure (Departments)
Recruit CRM & ATS
Organization
1:1Asanify department assignments and org chart hierarchy map to Recruit CRM Organizations. The full org tree is preserved as a parent-child organization hierarchy in Recruit CRM. Department head names and reporting relationships map to Organization contact roles rather than as standalone fields. If the org structure is deep (more than 4 levels), we flatten it to a two-level hierarchy in Recruit CRM and note the full depth in a custom field for admin reference.
Asanify
Job Postings (ATS module)
Recruit CRM & ATS
Job
1:1If Asanify's ATS module exposes job posting records, they map directly to Recruit CRM Job records. Job title, description, requirements, location, employment type, and salary range migrate to the equivalent Recruit CRM fields. Job status (open, closed, on hold) maps to Recruit CRM Job status. Any custom job fields from Asanify map to Recruit CRM Job custom fields. If Asanify's ATS module does not expose a standalone Job object, we create Job records from the context of active candidate application records.
Asanify
Application / Candidate-Job Association
Recruit CRM & ATS
Application
1:1Asanify candidate-to-job application records map to Recruit CRM Application records linked to the Candidate and Job. Application stage, submission date, source, and referred-by fields migrate to the equivalent Recruit CRM Application fields. Stage history (application moving through interview rounds) maps to Recruit CRM application stage values, and the stage transition timestamps are preserved. Multiple applications per candidate (re-applications or cross-job submissions) are migrated as separate Application records.
Asanify
Contractor Records
Recruit CRM & ATS
Candidate (contractor flag)
1:1Asanify Contractor records (billed at $18/contractor/month separately) map to Recruit CRM Candidates with a contractor_type or engagement_type custom field set to indicate the contractor relationship. Contract terms, invoicing frequency, and multi-currency payment details migrate to custom fields on the Candidate record. Ongoing active contracts are flagged as open assignments in Recruit CRM. Contractor records do not become Employees in Recruit CRM because Recruit CRM has no HRMS payroll layer.
Asanify
Payroll Runs and Payslips
Recruit CRM & ATS
Not migrated
lossyAsanify payroll runs, payslip records, TDS deductions, PF contributions, ESIC deductions, and professional tax deductions have no equivalent schema in Recruit CRM. These records are inventoried as a CSV export during the pre-migration review and handed off to the customer for retention in Asanify or archival storage. We do not load payroll or statutory deduction data into Recruit CRM because there is no payroll module, no payslip object, and no TDS/PF/ESIC field structure in the destination platform.
Asanify
Leave Balances and Attendance Records
Recruit CRM & ATS
Not migrated
lossyLeave balances, accrual states, attendance logs with geo-tracking coordinates, and shift schedules from Asanify do not map to any Recruit CRM object. Recruit CRM has no leave management, attendance tracking, or shift scheduling module. These records are excluded from the migration scope and inventoried separately as a structured CSV export. We recommend the customer retains Asanify access or exports these records to a dedicated HRMS for ongoing compliance needs.
Asanify
Performance Reviews, OKRs, KPI Trackers
Recruit CRM & ATS
Not migrated
lossyPerformance review cycles, 360-degree feedback ratings, OKR goal records, key results, progress percentages, and KPI tracker values are not available in Recruit CRM. These VIP-tier objects are excluded from migration and inventoried as a written handoff. Candidates with performance history in Asanify can have a free-text summary note added to their Recruit CRM Candidate record as a custom field, but structured review data, ratings, and OKR progress cannot be preserved as records in the destination platform.
Asanify
EOR Employee Assignments
Recruit CRM & ATS
Not migrated
lossyAsanify EOR records represent employees legally employed through an Asanify-owned entity in a specific country. Migrating these records to Recruit CRM—which has no EOR module and no employer-of-record schema—would strip the EOR relationship and create compliance risk. Every EOR assignment is flagged during scoping, labeled with the employer entity and country of legal employment, and excluded from the migration scope. The customer should retain Asanify for EOR employee management or engage a dedicated EOR provider post-migration.
Asanify
Employment Documents
Recruit CRM & ATS
Candidate Documents (partial)
1:1Employee documents (offer letters, contracts, identification records) accessible via the Asanify UI migrate as file attachments linked to the corresponding Candidate record in Recruit CRM. We export the file and map the file type to a Recruit CRM document category. Documents tied to payroll compliance (Form 16, pay-slips, statutory certificates) are excluded because Recruit CRM has no payroll document schema. Document access requires an active Asanify account at the VIP tier where document storage is available.
| Asanify | Recruit CRM & ATS | Compatibility | |
|---|---|---|---|
| Employee | Candidate1:1 | Fully supported | |
| Org Structure (Departments) | Organization1:1 | Fully supported | |
| Job Postings (ATS module) | Job1:1 | Fully supported | |
| Application / Candidate-Job Association | Application1:1 | Fully supported | |
| Contractor Records | Candidate (contractor flag)1:1 | Mapping required | |
| Payroll Runs and Payslips | Not migratedlossy | Fully supported | |
| Leave Balances and Attendance Records | Not migratedlossy | Fully supported | |
| Performance Reviews, OKRs, KPI Trackers | Not migratedlossy | Fully supported | |
| EOR Employee Assignments | Not migratedlossy | Mapping required | |
| Employment Documents | Candidate Documents (partial)1:1 | 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.
Asanify gotchas
Minimum headcount requirements vary by plan tier
Performance module and OKRs are VIP-only and not available on Essential
Geo-tracking attendance data may be sparse or inconsistently captured
Pending expense reimbursements require explicit cutover handling
EOR records represent a separate employer-of-record entity
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 export capability assessment
We audit the Asanify account across plan tier, accessible modules, and record volumes for ATS-relevant objects (Employees, Contractors, ATS Job Postings, Applications) and unsupported objects (Payroll Runs, Payslips, Statutory Deductions, Leave Balances, Attendance, Performance, OKRs). We confirm the export method: UI-based CSV download or, if API access is later confirmed, programmatic extraction. We deliver a written record inventory listing every object, its record count, and whether it migrates, archives, or is excluded. This inventory forms the migration scope baseline and the customer retention strategy for unsupported records.
Recruit CRM schema setup and field mapping
We configure the Recruit CRM destination schema before any data loads. This includes provisioning custom fields for compensation data (mapped from Asanify salary revision history), a contractor_type flag (mapped from Asanify Contractor records), a compliance_data text field (holding TDS/PF/ESIC references as unstructured text), and any custom candidate fields the customer requires. Job custom fields are provisioned to match Asanify job posting custom attributes. We configure Organization hierarchies matching the Asanify department structure and set up application stage values matching the customer's existing Asanify ATS stage labels.
Data extraction, deduplication, and transformation
We guide the customer through exporting all relevant Asanify objects as CSV files. We deduplicate records (removing duplicate candidate entries, duplicate employee records, and orphaned application records) before transformation. We apply the mapping rules: Employee records become Candidate records with work history; department assignments become Organization records with parent-child hierarchy; ATS job postings become Job records; applications become linked Application records. Salary revision history is reduced to the most recent salary figure in a custom compensation field. All India statutory field values (TDS, PF, ESIC) are placed in the compliance_data__c text field as unstructured text. Recruit CRM's documented REST API (api.recruitcrm.io, bearer auth) is used for any API-based loading where available.
Staging validation and reconciliation
We load all transformed data into a Recruit CRM staging environment (or the production account if the customer prefers a single-phase migration for smaller datasets). We reconcile record counts: Candidates in, Employees out; Organizations in, Departments out; Jobs in, Job Postings out; Applications in, linked correctly to Candidate and Job. We spot-check 25-50 records against the source CSV for field-level accuracy, verify that application stage transitions are in chronological order, and confirm that document attachments link to the correct Candidate records. The customer reviews the staging data and signs off before production cutover.
Production cutover and unsupported record handoff
We run the final data load into the production Recruit CRM account using the validated staging transformation. We freeze Asanify writes during the cutover window to prevent delta records from being created during load. Any records modified in Asanify between the initial export and cutover are identified as a delta and merged into the destination. We deliver the unsupported record inventory (payroll runs, payslips, statutory deductions, leave balances, attendance, performance reviews, OKRs, EOR assignments) as structured CSV exports with a field index, so the customer can retain or archive these independently. We do not load unsupported records into Recruit CRM.
Hypercare and unsupported object handoff
We support a one-week hypercare window following production cutover, resolving any record linkage issues, missing documents, or stage mapping errors reported by the customer's team. We deliver the unsupported object inventory as a written document with record counts, field indexes, and recommended retention actions for each object type. We do not rebuild Asanify workflows, automations, or shift schedules in Recruit CRM; these do not have equivalents in the destination platform and are documented as scope exclusion. Post-hypercare, the customer retains Asanify access for payroll, statutory, and HRMS records that do not migrate, or migrates those to a dedicated HRMS platform separately.
Platform deep dives
Asanify
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 Asanify 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
Asanify: Not publicly documented.
Data volume sensitivity
Asanify 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 Asanify to Recruit CRM & ATS migration scoping. Not seeing yours? Book a call.
Walk through your Asanify 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 Asanify
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.