Migrate from greytHR to Zoho Recruit

Active employees, employees on notice, and re-hire-eligible former employees map to Zoho Recruit Candidate records. Employment status determines the Candidate Status value in Zoho Recruit: Active employees map to Active; those on notice map to On Hold or a custom status; former employees with prior satisfactory tenure map to Sourced or Referred for re-hire consideration. We extract current department, designation, grade, employment start date, and contact details. Statutory fields (UAN, PAN, PF, ESI) and compensation data do not map to Zoho Recruit and are flagged in the cutover checklist for retention in a separate compliance repository. Zoho Recruit's Last Name field is mandatory; greytHR stores a single Full Name field in many configurations, so we apply name-split logic during transformation using common Indian name conventions and space-based splitting as a first pass, with records flagged for admin review where splitting is ambiguous.

greytHR departments map to Zoho Recruit's Department picklist field on the Candidate module. We extract the full LOV value set from greytHR during scoping, then pre-create matching picklist values in Zoho Recruit under Setup > Recruiting > Picklists before any records are imported. Where greytHR uses a nested department hierarchy (e.g., Engineering > Frontend > React Team), we flatten to the top two levels as Department and Sub-Department custom fields. Department headcount and cost-center data from greytHR does not map to any Zoho Recruit field and is not migrated.

greytHR designations map to a custom picklist field (Current Title) on the Candidate module in Zoho Recruit. We extract the greytHR designation LOV values and pre-create matching picklist entries in Zoho Recruit. Grade and band-level data from greytHR maps to a separate custom picklist (Grade/Level) if the customer requires it; otherwise it is documented in the cutover notes. Salary range and compensation figures from greytHR designation records do not map to Zoho Recruit.

The most recent position record from greytHR (current department, designation, employment start date, and location) maps to the Work Experience section on the Candidate record in Zoho Recruit. Employment Start Date becomes the From Date; End Date is set to the migration date for active employees and to the actual exit date for separated employees. Historical position changes (prior roles, promotions, transfers) are documented as a structured notes attachment because Zoho Recruit's Candidate object does not natively support a multi-row employment history table. If the customer requires full position history in Zoho Recruit, a custom module (Work History) must be pre-created and linked via a lookup relationship.

Employee documents exported from greytHR (offer letters, ID proofs, joining letters) migrate as attachments to the corresponding Candidate record in Zoho Recruit's Document Library. We export document binary files via the greytHR document API where access is granted, and store them as Zoho Recruit attachments linked via ContentDocumentLink. Proof-of-identity documents (PAN card copies, Aadhaar) are flagged as sensitive and are migrated only over an encrypted channel with a post-migration deletion confirmation. Document metadata (issue date, expiry, document type) is preserved in a structured CSV alongside the binary files for admin reference.

greytHR HR admin users who will also recruit in Zoho Recruit map to Zoho Recruit User accounts. We resolve greytHR user email addresses against Zoho Recruit User provisioning. greytHR role definitions (HR Admin, Manager, Employee Self Service permissions) have no Zoho Recruit equivalent and are documented separately for the customer's admin to configure in Zoho Recruit's Roles and Profiles. Employee-level greytHR users who are not recruiters are not provisioned as Zoho Recruit users unless the customer intends to use Zoho Recruit's candidate-facing portals.

greytHR custom fields on the Employee record that are not covered by standard mappings (current title, department, email, phone) are recreated as custom fields in Zoho Recruit under the Candidates module. We extract the greytHR custom field definitions (field type, required flag, LOV values) during scoping, then the customer's Zoho Recruit admin creates matching fields under Setup > Module Builder > Candidates before migration. greytHR custom field values are then imported as standard data values in the CSV migration file. LOV-based greytHR custom fields require pre-creation of matching Zoho Recruit picklist values. This is a manual configuration step outside our API-driven import; we document the full field list and provide the mapping CSV.

greytHR leave entitlement, accrual, balance, carry-forward, and encashment records have no Zoho Recruit equivalent. Zoho Recruit has no leave or attendance module; leave data is HRMS-specific and belongs in Zoho People or another HRMS, not an ATS. We export current leave balances as a structured CSV for the customer's admin to import into their destination HRMS (Zoho People or another platform) separately. Leave policy rules (carry-forward percentages, encashment eligibility) are documented in the cutover checklist as a manual configuration item at the destination.

Payslip data (gross salary, deductions, net pay, TDS deducted) and payroll run history do not map to Zoho Recruit. An ATS does not store compensation data as a standard field. We recommend the customer export greytHR payslip records for the current and prior fiscal years as a supplemental manual export from the greytHR payroll reports module, and retain these in a secure HRMS repository (Zoho People or a dedicated payroll archive). Salary structure definitions from greytHR are documented in the cutover checklist but cannot be migrated as Zoho Recruit does not expose a salary or compensation object.

UAN, PF numbers, ESI numbers, PAN, and TDS section data stored as structured fields on greytHR Employee records do not map to any Zoho Recruit field. ATS platforms do not maintain government-filing compliance data. We flag these as high-priority cutover items: the customer must download official PF and ESI challans from the respective government portals (EPFO, ESIC) and retain statutory records in a separate compliance archive. PAN and Aadhaar copies are migrated as sensitive document attachments (see Documents mapping) but are not stored as structured ATS fields. This is a critical mid-year migration concern: switching HRMS mid-compliance cycle without a statutory data retention plan can cause government-filing errors.

Swipe logs, shift schedules, overtime records, and attendance regularization status from greytHR do not map to Zoho Recruit. The ATS has no attendance module. We export raw attendance data for the 90 days prior to migration as a supplemental CSV for the customer's admin to retain in a separate HRMS. Attendance regularization discrepancies (where swipe data contradicts the regularization status, a known greytHR gotcha) are flagged in the pre-migration audit so that the customer does not carry forward false absence flags into a new HRMS.

Completed review cycles, ratings, goals, and feedback text from greytHR Performance Management module have no Zoho Recruit equivalent. An ATS does not store performance review data. We export completed review records as a structured CSV for the customer's HR admin to import into their destination performance management system (Zoho People performance module, or another platform). In-progress review cycles are migrated with a status flag indicating completion percentage; cycle finalization must occur in the destination HRMS post-migration. Review templates and rating scales are documented in the cutover checklist for manual reconfiguration.