Migrate from Namely to Zoho Recruit

Namely Employee records map to Zoho Recruit Candidates with schema transformation. The Employee ID becomes a custom field namely_employee_id__c for reference linking. First Name and Last Name are mandatory in Zoho Recruit — we confirm both are populated in Namely; records without Last Name receive a placeholder value ('Not Provided') per Zoho Recruit's import requirements. Email, phone, address, department, and hire date migrate to standard and custom Candidate fields. Employment status (active, terminated) maps to Candidate status. We flag that Namely's full employee profile includes payroll and benefits data that has no native Zoho Recruit equivalent — these are delivered as a structured JSON sidecar for custom field population post-import.

Namely job requisitions and posting records map to Zoho Recruit Job Openings. The job title, job description (HTML), department, employment type (full-time, part-time, contract), and location map to standard Job Opening fields. Salary range from Namely's compensation fields migrates to a custom salary range field. Open and closed status maps to Job Opening status. We confirm that Namely's upper-tier recruiting workflows (interview scorecards, offer approval chains) are documented for Zoho Recruit Blueprint rebuild rather than imported.

Namely Departments map to Zoho Recruit Clients. The department name becomes the Client name. Cost center and reporting hierarchy in Namely are stored as custom fields on the Client record. If the customer's hiring managers align to departments, we create Client Contacts in Zoho Recruit and link them to the corresponding Client so that hiring-manager-specific workflows can reference the correct Client record.

Namely salary history, bonus records, and compensation effective-dates have no native Zoho Recruit ATS field. We create a custom field section on the Candidate record — namely_salary_history__c (long text area) — and populate it as a structured JSON sidecar with per-period salary, bonus, and equity entries. The customer decides which historical compensation fields to display as read-only custom fields on the Candidate layout. This is a configuration step that happens before import, not a data migration limitation.

Namely benefit elections (health, dental, vision, 401k) by plan year have no Zoho Recruit equivalent. We extract enrollment records and store them as a JSON sidecar per employee (plan name, carrier, coverage tier, election status, plan year). These records are delivered for the customer to configure as custom fields or to keep as reference documents attached to the Candidate. This follows the same approach documented for benefits migration from Namely to any non-benefits-admin platform.

Namely PTO accrual balances (current balance, accrual rate, policy type) have no Zoho Recruit equivalent. We export balances for accrual-based policies as a custom field section. Unlimited PTO policies have no balance record in Namely — we flag this in the discovery report and recommend exporting the policy document as a reference file. This mirrors the approach documented in the Namely source platform page for unlimited PTO handling.

Namely Documents export as binary files with inconsistent naming conventions (e.g., 'Smith_Joe_I9.pdf' vs 'I-9_Smith.pdf'). We normalize file names during extraction using employee_id + document_type conventions (e.g., 'EMP001_I9.pdf'). Document metadata (upload date, uploader, document category) is preserved as a JSON sidecar. We import files as attachments to the corresponding Candidate record in Zoho Recruit. Customers on Zoho Recruit's Enterprise tier benefit from larger storage limits for bulk document imports.

Namely Performance Reviews (ratings, goals, feedback, review cycles) have no Zoho Recruit ATS equivalent. We extract review data per employee — rating value, review period, reviewer name, goal text, and overall feedback — and deliver it as a structured JSON sidecar. For customers who need this data accessible to recruiters, we create a custom long-text field (namely_performance_summary__c) and populate it with the most recent review cycle summary. Full historical review data remains in the sidecar for admin reference.

Namely payroll runs (earnings, deductions, taxes, direct deposit, year-to-date figures) do not migrate to Zoho Recruit. ATS platforms do not manage payroll, and importing payroll history into candidate records would add unrelated data to the recruiting workflow. We export the payroll history as a structured CSV and JSON deliverable for the customer's finance team to retain independently. If the customer also implements Zoho Payroll or Zoho People as a separate HR layer, payroll history would be re-ingested there as part of a separate engagement.

Namely HR workflows (onboarding approval chains, PTO request flows, benefits enrollment workflows) do not migrate to Zoho Recruit. ATS workflow rules and recruiting automation (interview scheduling, candidate status triggers, email alerts) are a separate domain from HR workflow automation and cannot be cross-migrated. We deliver a written inventory of every active Namely workflow with its trigger, conditions, and actions for the customer's admin to evaluate for Zoho Recruit Blueprint or workflow rule rebuild post-migration.

Namely's org chart and manager relationships export as manager name and manager ID per employee. We map manager name to a Candidate custom field (namely_manager__c) and store the full reporting chain as a delimited custom field (namely_reporting_chain__c) for reference. Zoho Recruit's hierarchy model is candidate-centric, not org-chart-centric, so the reporting structure is preserved as metadata rather than as a native navigation feature.

Namely custom properties on employee records are discovered during discovery via API. Each custom field is evaluated for a Zoho Recruit equivalent: text fields map to single-line text, multi-select maps to multi-select picklist, date fields map to date fields, and boolean flags map to checkbox fields. Fields with no Zoho Recruit equivalent are delivered as long-text area custom fields or dropped to a JSON sidecar. Custom field schema is pre-built in Zoho Recruit before any record import so that all field mappings are resolved at migration time.