Migrate from empeon to Zoho Recruit

Empeon Employee records map to Zoho Recruit Candidate records. The employee's first name, last name, email, phone, address, and employment status transfer as standard Candidate fields. Employment start date and job title from Empeon populate as custom fields in Zoho Recruit since the Candidate module does not natively store tenure history. We handle the ESS Hub email-must-match requirement by preserving the original employee email in a dedicated custom field and flagging any mismatches against the customer's target Zoho Recruit authentication domain before cutover.

Empeon free-text Input custom fields migrate to Zoho Recruit custom fields of the Single-line or Multi-line text type. We enumerate all active Input fields during scoping, classify each as single-line or multi-line based on content pattern analysis, and pre-create the corresponding custom fields in the Candidate module before import. Empeon Checkbox custom fields migrate to Zoho Recruit Checkbox custom fields with a direct true/false transfer.

Bank routing numbers and account numbers from Empeon Direct Deposit profiles are flagged as sensitive fields. We do not transfer these into Zoho Recruit's candidate record under any standard configuration. Instead, we generate a cryptographically signed, time-limited reference token that the customer's payroll or HR admin can use to retrieve the data from a secure vault post-migration. This prevents sensitive banking data from sitting in the ATS, which is a system-of-record for candidate activity rather than financial operations.

Benefit enrollment records (plan names, carrier codes, coverage tiers, enrollment dates) do not have a native storage location in Zoho Recruit's Candidate module. We export these as structured records during scoping, then either attach them as notes to the candidate or document them for a follow-on Zoho People migration where benefit enrollments are fully supported. Plan names and carrier codes from Empeon are preserved as-is; any mapping to Zoho People benefit plan equivalents is a post-migration configuration step.

PTO, sick leave, and accrual balance records in Empeon have no equivalent in Zoho Recruit's ATS data model. Accrual tracking is an HRMS function, not an ATS function. We flag accrual balances as out-of-scope for the Zoho Recruit migration and document the current balance snapshot per employee as a reference file for the customer's HR admin. If the customer adopts Zoho People post-migration, accrual balances are migrated in a follow-on engagement.

Clock punches, time entries, and Advanced Scheduling data in Empeon have no equivalent in Zoho Recruit. ATS platforms do not track employee time or manage scheduling grids. We export current scheduling assignments and time-off balances as a reference file for the customer's records, but this data does not migrate into Zoho Recruit. For organizations needing time and attendance post-migration, we recommend Zoho People as the complementary module within the Zoho ecosystem.

Payroll registers, pay periods, gross/net pay amounts, deduction line items, and tax withholding data in Empeon are out of scope for Zoho Recruit. ATS platforms do not store payroll records. We export a payroll summary reference file (current compensation amounts, pay frequency, last pay date) and store it as a candidate note or deliver it as a structured export for the customer's HR and finance teams. Full payroll history migration is a separate engagement scoped for Zoho People or a dedicated payroll platform.

Documents attached to Empeon employee profiles (offer letters, certifications, performance reviews) are exported as binary files during the migration window. We transfer file metadata (filename, file type, upload date) and the file binary to Zoho Recruit's attachment storage, linking each file to the corresponding candidate record. If the Empeon document management system is not accessible via the API Connector, we coordinate with the customer's admin to export documents manually and provide the file manifest for bulk attachment post-import.

Empeon department and cost center names from the Company Settings tab migrate to Zoho Recruit's Departments module. Departments are referenced by Job Openings and Candidates in Zoho Recruit, making this a foundational import that must complete before candidate records are loaded. We extract the full department hierarchy, resolve any nested cost center relationships, and flatten them into a Zoho Recruit-compatible department structure.

Empeon job titles and pay grades from Company Settings do not have a direct Zoho Recruit equivalent as standalone reference data. However, if Empeon contains active job postings (requisitions tied to job titles with open headcount), we map these to Zoho Recruit Job Openings. Job title, department assignment, employment type, and job description transfer as Job Opening fields. Closed or filled positions are migrated as archived Job Openings for historical record completeness.

Empeon Standard Reports and Live Reports contain row-level data that we export as structured CSV during scoping. The report row data (employee counts by department, accrual summaries, payroll register rows) is not imported into Zoho Recruit's ATS schema because these are HR analytics outputs, not candidate records. We deliver the exported report data as a structured reference file for the customer's finance and HR analytics teams. The Zoho Analytics integration is recommended post-migration for reporting on Zoho Recruit data.

ESS Hub access is tied to the employee email address in Empeon Workforce. We capture all employee email addresses during scoping and cross-reference them against the target Zoho Recruit accounts to flag mismatches. Zoho Recruit users must have unique email addresses; any employee with an existing separate Zoho Recruit account (as a standalone recruiter, for example) must close that account before they can be imported into the company's Zoho Recruit org, per Zoho Recruit's migration documentation. We document all flagged accounts during scoping and escalate to the customer's admin for resolution before the user migration phase.