HRMS migration
Field-level mapping, validation, and rollback between Factorial and Zoho Recruit. We move data and schema; workflows are rebuilt natively in Zoho Recruit.
Factorial
Source
Zoho Recruit
Destination
Compatibility
10 of 12
objects map 1:1 between Factorial and Zoho Recruit.
Complexity
CModerate
Timeline
1-3 weeks
Overview
Factorial and Zoho Recruit serve different phases of the employee lifecycle, which is the central challenge of this migration. Factorial is an HRMS that manages active employees, time-off accruals, payroll, and employment documents; Zoho Recruit is an ATS focused on job openings, candidates, interviews, and hiring pipelines. The migration is not a direct object replacement — it is a selection of which Factorial records map meaningfully into a recruiting context. Employee profiles migrate as Zoho Recruit Candidates or Users depending on whether the organization intends to run internal hiring processes or onboard recruiters into the system. Department hierarchies map directly. Custom fields on Factorial employee records require pre-creation in Zoho Recruit because custom fields are gated by edition (50 per module on Standard, 300 on Enterprise). Documents attached to employee profiles in Factorial have no bulk export endpoint — we paginate the list API and download each file individually, which extends timeline for document-heavy archives. We do not migrate Factorial Workflows, Approvals, or payroll configurations as code; we deliver a written inventory of these for your admin to rebuild in Zoho Recruit.
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 Factorial object lands in Zoho Recruit, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Factorial
Employee
Zoho Recruit
Candidate or User (split required)
1:manyFactorial employee records require a split decision at migration scoping. Employees who will use Zoho Recruit as a recruiter or hiring manager map to User records (provisioned by the customer's admin before migration); employees who represent past or potential candidates for internal job openings map to Candidate records. We extract name, email, department, start date, employment status, and contact information from Factorial's employee endpoint during discovery. Zoho Recruit requires Last Name as a mandatory field on Candidates — employees without a Last Name in Factorial receive a placeholder value ('not provided') that must be corrected manually or flagged for the customer's admin after migration.
Factorial
Department
Zoho Recruit
Department
1:1Factorial departments and cost centers map directly to Zoho Recruit Departments. The parent-child hierarchy (nested departments) migrates as a flat list with a parent_department reference that Zoho Recruit resolves during import. No orphaned departments should result if the Factorial organizational structure is well-formed. We validate department record counts post-import against the source department list.
Factorial
Document
Zoho Recruit
Attachments or Document Library
1:1Employee-attached documents in Factorial (contracts, policy files, identification documents) migrate as Zoho Recruit Attachments linked to the corresponding Candidate or User record. Factorial imposes no bulk document download endpoint — we paginate the document list API, retrieve each file individually, and associate it by employee reference. Document-heavy archives (over 500 files per employee) extend the migration timeline significantly. We flag document-heavy cases during scoping and set timeline expectations accordingly.
Factorial
Custom Fields (Employees)
Zoho Recruit
Custom Fields
lossyFactorial per-customer custom fields on employees have no schema discovery endpoint — we enumerate active fields by calling the employee and contract endpoints during discovery. Each discovered custom field requires pre-creation in Zoho Recruit (Setup > Customization > Modules) before migration begins. Custom fields are gated by Zoho Recruit edition: 50 per module on Standard, 300 on Enterprise. If Factorial exceeds the Standard-tier limit, the customer must upgrade or select which custom fields to prioritize.
Factorial
Contract
Zoho Recruit
Attachments or Notes
1:1Factorial employment contracts (contract type, working hours, probation period, legal entity reference) do not have a native equivalent in Zoho Recruit's Candidate record structure. We migrate contract data as formatted Notes attached to the Candidate record, preserving contract type, start date, and working hours in a structured text block. For organizations that need contract data as structured fields, we create a Contract Info custom section in Zoho Recruit's Candidate layout before migration.
Factorial
Compensation History
Zoho Recruit
Notes or Custom Currency Fields
1:1Factorial's effective-dated salary changes, bonuses, and equity grants do not have a Zoho Recruit native equivalent since Zoho Recruit is an ATS, not an HRMS. We store the most recent compensation snapshot as a Note on the Candidate record with a structured format (base salary, bonus, effective date). If the customer requires structured compensation fields for offer management, we pre-create currency custom fields on the Candidate module before migration.
Factorial
Absence Record
Zoho Recruit
Notes
1:1Factorial absence types, balances, and accrual rules have no Zoho Recruit equivalent. We do not migrate absence data as structured records because Zoho Recruit has no absence management module. We document the absence types and accrual balances in a written summary delivered with the migration handoff, which the customer's HR admin uses to configure absence tracking separately (through Zoho People if the customer uses the broader Zoho ecosystem, or through a third-party tool).
Factorial
Time Entry
Zoho Recruit
Not Migrated
1:1Historical time entries (clock-in/out records, timesheets) do not migrate to Zoho Recruit. The ATS data model has no time-tracking module, and importing time entry records as Notes or custom fields would create operational noise without recruiting utility. We document the time entry volume and date range during discovery so the customer understands what is not moving and can retain the data in a reporting context if needed.
Factorial
Payroll Run
Zoho Recruit
Not Migrated
1:1Factorial payroll data (gross compensation, tax withholdings, net-pay calculations, social security contributions) is tied to the country legal entity configuration and requires country-specific recomputation in any destination system. Zoho Recruit has no payroll module. We do not migrate payroll runs as structured records. We deliver a payroll data summary document that captures the last three payroll run totals per employee so the customer's finance team can set up compensation fields in their next HRMS or payroll system.
Factorial
Job Opening
Zoho Recruit
Job Opening
1:1If Factorial contains any active job postings or requisitions (typically in organizations using Factorial's hiring module for internal postings), these map to Zoho Recruit Job Opening records. Job title, department, location, employment type, and description migrate directly. Active job status in Factorial maps to the Open status in Zoho Recruit; closed postings map to Closed.
Factorial
Workflow and Approval
Zoho Recruit
Not Migrated
1:1Factorial approval chains for time-off, expenses, and documents are stored as platform-specific workflow objects that have no export representation and cannot be imported into Zoho Recruit. We document the existing workflow structure (triggers, conditions, approvers, actions) during discovery and deliver a written inventory that maps each Factorial workflow to a Zoho Recruit Workflow Rule, Blueprint, or Assignment Rule equivalent. Rebuilding is the customer's admin responsibility post-migration.
Factorial
Employee Self-Service Settings
Zoho Recruit
Not Migrated
1:1Factorial employee self-service configurations (portal preferences, notification settings, time-off request UI defaults) are platform-specific and do not migrate. Zoho Recruit's candidate-facing and recruiter-facing settings are configured independently. We deliver a settings summary as-is for the customer's admin to review and reapply relevant preferences in Zoho Recruit.
| Factorial | Zoho Recruit | Compatibility | |
|---|---|---|---|
| Employee | Candidate or User (split required)1:many | Fully supported | |
| Department | Department1:1 | Fully supported | |
| Document | Attachments or Document Library1:1 | Fully supported | |
| Custom Fields (Employees) | Custom Fieldslossy | Mapping required | |
| Contract | Attachments or Notes1:1 | Fully supported | |
| Compensation History | Notes or Custom Currency Fields1:1 | Mapping required | |
| Absence Record | Notes1:1 | Fully supported | |
| Time Entry | Not Migrated1:1 | Fully supported | |
| Payroll Run | Not Migrated1:1 | Fully supported | |
| Job Opening | Job Opening1:1 | Fully supported | |
| Workflow and Approval | Not Migrated1:1 | Fully supported | |
| Employee Self-Service Settings | Not Migrated1:1 | Fully supported |
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.
Factorial gotchas
No public bulk export API for documents
Custom fields are not discoverable via a schema endpoint
Payroll data is country-locked to the legal entity
Workflow automation does not export
Zoho Recruit gotchas
Daily API rate limits are tier-gated and per-user capped
User import hard cap of 2,000 records
Attachment folder hierarchy must be preserved exactly
Resume parsing quota varies by plan and resets daily
Custom fields unavailable in Free and Standard editions
Pair-specific challenges
Migration approach
Discovery and scoping
We audit the Factorial account via API to enumerate employee records, department hierarchy, document attachment counts, and custom field inventories. We assess which employees map to Zoho Recruit Candidates (for internal hiring) versus Users (for recruiting team provisioning). We identify document volume and flag any archive exceeding 500 files as a timeline risk. The discovery output is a written scope document confirming record counts, custom field priority list, and a Zoho Recruit edition recommendation based on custom field count.
Zoho Recruit schema preparation
We pre-create all required custom fields in Zoho Recruit before any data migration begins. This includes custom fields on the Candidate module for any Factorial employee custom properties that cannot be stored as Notes. We configure the Candidate layout to include the custom fields, a Contract Info section, and a Compensation summary block. We set up the Department hierarchy to match Factorial's organizational structure. All schema work happens in the customer's Zoho Recruit instance with admin credentials provided during setup.
User provisioning in Zoho Recruit
Factorial employees who will use Zoho Recruit as recruiters require User accounts provisioned in Zoho Recruit before Candidate import. We extract the owner list from Factorial and match by email against the Zoho Recruit User table. Any User not yet provisioned goes to a reconciliation queue for the customer's admin to resolve. Migration cannot proceed past this step because Candidate records must reference an OwnerId at import time. We provide a User provisioning checklist as part of the migration handoff.
Sandbox test migration and validation
We run a full migration into a Zoho Recruit sandbox environment (if available) or a staging subset using a representative data sample. The customer's HR lead validates record counts, spot-checks 25-50 Candidate records against the Factorial source, and confirms that document attachments are associated with the correct records. Any field mapping corrections, custom field additions, or department hierarchy issues are resolved here before production migration begins.
Production migration in dependency order
We run production migration in record-dependency order: Departments (flat import with parent references), Users (validated from step 3), Candidates (with Last Name placeholder applied and OwnerId resolved), Job Openings (if any exist in Factorial), Notes (containing contract summaries and compensation snapshots), and Attachments (paginated per-file downloads from Factorial). Each phase emits a row-count reconciliation report. Document attachment import is the longest phase and runs last to avoid blocking other record types.
Cutover, validation, and workflow handoff
We freeze Factorial writes during cutover and run a final delta pass to capture any records modified during the migration window. We deliver the migration handoff package: a record-count reconciliation report, a document manifest (file name, associated Candidate, file size), a custom field mapping sheet, and the workflow inventory document. We do not rebuild Factorial workflows in Zoho Recruit — that work is scoped separately for the customer's admin or a Zoho partner.
Platform deep dives
Factorial
Source
Strengths
Weaknesses
Zoho Recruit
Destination
Strengths
Weaknesses
Complexity grading
Moderate HRMS migration. 1 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Factorial and Zoho Recruit.
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
Factorial: 200 requests per minute for POST requests per Factorial's published API docs. GET-side limits are not separately enumerated; we tune extraction concurrency conservatively against the customer's tenant during scoping..
Data volume sensitivity
Factorial 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 Factorial to Zoho Recruit migration scoping. Not seeing yours? Book a call.
Walk through your Factorial to Zoho Recruit migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Factorial
Other ways to arrive at Zoho Recruit
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.