Migrate from iTrent to Zoho Recruit

iTrent employee records with active employment status map to Zoho Recruit Candidate records. Core fields including name, email, phone, address, and employment status migrate directly. We map iTrent job title and department to Zoho Recruit's Current Title and Department custom fields. iTrent employee IDs are stored as an external ID field in Zoho Recruit for deduplication and cross-reference. Candidate records without an email address require a Last Name value to satisfy Zoho Recruit's mandatory field requirement; we substitute 'Not Provided' where necessary and flag these records for manual review post-migration.

iTrent active vacancies map to Zoho Recruit Job Opening records. The vacancy title, job description, hiring manager assignment, department, and location fields migrate directly. We map iTrent posting status to Zoho Recruit's Opening Status field. Pending onboarding tasks associated with a vacancy attach as Tasks to the Job Opening. Closed or archived vacancies are imported with status set to Closed to preserve historical hiring data for reporting.

iTrent applications link a candidate to a vacancy. We create Zoho Recruit Candidate records first, then associate them with the migrated Job Opening using Zoho Recruit's candidate-to-job association model. Application status from iTrent maps to Zoho Recruit Candidate Status values, and source tracking (Indeed, LinkedIn, direct) maps to the Zoho Recruit Source field. Interview rounds scheduled in iTrent are created as Interview records in Zoho Recruit.

Historical payslip data from iTrent's cyclical pay period records is the highest-risk migration object because Zoho Recruit has no native payroll module. We extract each payslip as a discrete row containing pay period, gross earnings, deductions, tax codes, National Insurance contributions, net pay, BACS reference, and bank detail hash. These rows are stored in a Zoho Recruit custom module called 'Payroll History' with a lookup relationship to the Candidate record. BACS references and bank details are flagged for re-entry post-migration due to data sensitivity and Zoho Recruit's field-level security defaults.

Salary figures, bonus structures, and benefit enrolments from iTrent map to custom fields in the Candidate record and a related 'Benefits' custom module. Auto-enrolment pension data is stored separately from voluntary benefit elections because they carry different UK compliance implications and must not be conflated in Zoho Recruit's flat object model. Benefit provider name, policy reference, enrolment date, and contribution amounts are mapped to typed custom fields. Zoho Recruit Standard edition caps custom fields at 50 per module, which may require splitting benefits data across the Candidate module and the custom Benefits module for larger organisations.

Contracts, offer letters, and policy documents stored in iTrent's document repository are exported as file blobs with metadata including filename, upload date, file type, and associated employee or vacancy. We attach each document to the corresponding Candidate or Job Opening record in Zoho Recruit using ContentDocumentLink. Zoho Recruit's file storage limits vary by plan (256MB for Standard, 1GB for Professional, 3GB for Enterprise), so we validate total document volume against the target plan's storage allowance during scoping. Document version histories are not always accessible via standard iTrent exports; we flag any truncated version chains for customer review.

Entitlement balances, accrual histories, and absence events tied to iTrent's custom leave year configurations are mapped to custom fields in the Candidate record. We preserve entitlement snapshots at the migration date as field values and flag any in-progress leave cycles for manual confirmation post-migration. Because Zoho Recruit is an ATS rather than an HRIS, absence management is not native; the absence data is stored as candidate context fields and the customer's HR team manages leave approvals in Zoho People or manually post-migration.

iTrent departments, cost centres, and locations are mapped to Zoho Recruit's Department picklist values. Reporting lines stored in iTrent are preserved as custom fields on the Candidate record (Manager Name, Reporting Manager ID). Org structure maps cleanly with no schema transformation required because both systems use standard reference data for departments and locations.

Performance review cycles, objectives, and competency ratings from iTrent are configurable and may use custom rating scales. We map review data to a custom 'Performance Reviews' module in Zoho Recruit with fields for review period, rating score, reviewer, and comments. Where iTrent uses custom rating values, we map each value explicitly to a Zoho Recruit picklist to avoid silent truncation. Zoho Recruit Standard edition does not support formula fields or lookup relationships, so performance data referencing related employee records may require custom fields with concatenated values instead of proper lookups on lower tiers.

iTrent conditional approval chains and authorisation rules are platform configuration, not data records. We extract workflow definitions as structured artefacts during discovery and deliver them as a written configuration transfer document for the customer's admin team to rebuild in Zoho Recruit's Workflow Rules (Professional: 5 rules, Enterprise: 50 rules) or Blueprint automation (Enterprise only). Recruitment approval workflows requiring multi-step escalation must be assessed against the Zoho Recruit edition's workflow limit during scoping.

Employee Self Service portal settings in iTrent determine which fields employees can view and update. These are platform configuration rather than data. We document the ESS-visible field set and salary display logic as part of the configuration transfer deliverable. Zoho Recruit's Candidate Portal is configured separately in Setup and is not migrated from iTrent ESS settings. The customer's admin rebuilds candidate self-service permissions and portal access based on the documentation we provide.

User-defined salary and benefit calculation rules in iTrent are stored as platform configuration rather than data. These rules often depend on historical payroll outputs, making them complex to replicate without the underlying payroll history. We extract the calculation logic as structured artefacts during discovery and document the recommended Zoho Recruit equivalent using custom fields, validation rules, or Zoho Creator extensions for the customer's admin team to implement post-migration.