Migrate from ZenHR to Recruit CRM & ATS

ZenATS Candidate records map to Recruit CRM Candidate records preserving full name, email, phone, LinkedIn URL, source channel, and pipeline stage history. The original vacancy assignment migrates as a candidate-job association via Recruit CRM's associated-fields API. A critical gap: ZenATS does not expose SMS and email communication body content via its standard API — only metadata (timestamps, template names) is available. We flag this during scoping and recommend a manual ZenATS export of communication logs if full candidate conversation history is required. Candidate status (active, hired, rejected, withdrawn) maps to Recruit CRM's candidate stage or custom status field.

ZenATS Vacancy records map to Recruit CRM Job records. Job title, description, requirements, employment type, salary range (min/max), and location migrate as standard Job fields. Vacancy status (open, paused, closed) maps to Job status. Any vacancy-specific custom fields configured in ZenHR require pre-configuration of matching custom fields in Recruit CRM using their associated-fields API (POST /v1/candidates/associated-field/{candidate}/{job}) and then population via field ID and value pairs. Vacancy stage history (pipeline progression) migrates as a written stage-log or as notes on the Job record if the customer's recruiting process depends on historical stage attribution.

ZenHR's organizational structure — branches and company-level records — does not map directly to a single Recruit CRM object. We assess whether the ZenHR company records represent recruitment clients (external organizations the agency places into) or internal organizational units. For client records, we map to Recruit CRM Client with company name, website, industry, and address. For internal branches or divisions, we assess whether to create a Recruit CRM Company record or a Client record, depending on the customer's business model. This decision is made during scoping based on data inventory.

ZenHR Employees who were sourced through ZenATS can be migrated as Recruit CRM Candidate records, carrying their name, email, phone, and any hiring-stage data from the original ZenATS pipeline. However, the full ZenHR Employee record — personal details, financial information, payroll data, bank account, organizational assignment, emergency contacts — has no equivalent in Recruit CRM's schema. For customers exiting ZenHR entirely (not just extracting ZenATS data), we recommend a parallel engagement to select and migrate to a destination HRMS (e.g., BambooHR, Personio, Workday) that holds the HCM scope. We flag this scope gap in the initial discovery call and do not attempt to map payroll, banking, or HR-sensitive fields to Recruit CRM.

ZenHR custom fields are tenant-specific and vary across every install — there is no fixed schema. We run a field discovery phase against the source ZenHR tenant before mapping begins, enumerating every active standard and custom field, their data types, and mandatory/optional flags. We then design the Recruit CRM equivalent: standard fields take priority, and remaining custom fields are mapped to Recruit CRM's associated-fields structure using field IDs and typed values. ZenHR multi-select or checkbox custom fields map to Recruit CRM multi-value associated fields. This configuration phase happens before any production migration and is validated in a test import before full cutover.

ZenHR Document records attach to Employee objects (contracts, IDs, certifications, offer letters) and carry metadata including document type, expiry date, upload timestamp, and e-signature status. We migrate document metadata alongside the owning Employee record. Binary file transfer is scoped separately — we can transfer files via ZenHR's document storage API where accessible and map them as attachments to the corresponding Recruit CRM Candidate or Client record. Documents without a migratable owning record (e.g., HR letter templates with no associated candidate) are noted as requiring manual re-upload post-migration.

ZenHR Timeoff records — including leave balances, accrual transactions, request history, and pending requests — have no equivalent data model in Recruit CRM. Recruit CRM has no leave management, absence tracking, or balance-calculation module. We flag this as an out-of-scope object and advise that customers migrating away from ZenHR entirely should select a dedicated HRMS as the destination for timeoff data. If the customer is running ZenHR alongside a separate HRMS, we document the timeoff field mapping as a separate migration scope. Pending leave requests at cutover are flagged for manual resolution by the customer's HR admin before migration freeze.

ZenHR Payroll runs and off-cycle financial transactions (salary payments, deductions, social insurance contributions, tax withholdings) are out of scope for Recruit CRM migration. Recruit CRM is an ATS and candidate CRM with no payroll module and no financial transaction data model. We document the payroll field structure during discovery as a written schema map for the customer's finance and HR team to use when selecting a payroll destination platform. Customers exiting ZenHR for payroll replacement should evaluate platforms such as Deel, Remote, Rippling, or a region-appropriate payroll provider.

Employee Loans (principal, remaining balance, repayment schedules tied to payroll deductions) and Overtime records (hours, types, rates) are ZenHR HCM objects with no Recruit CRM equivalent. These migrate as written schema inventories for the customer's HR admin to reconstruct in a destination payroll or HRMS. The loan and overtime data is flagged as historical financial records requiring separate payroll system migration scope.

Branch Employee Shifts and Attendance Details (clock-in/clock-out events) generate high-volume granular records that ZenHR's API paginates via cursor-based iteration. Recruit CRM has no attendance tracking module. We scope attendance data as out of scope and recommend migrating only active shift assignment metadata (current branch, current shift schedule) as reference notes on the Employee record if a separate HRMS is the destination. Historical attendance summaries migrate as a written report rather than transactional records if the customer's replacement payroll system recalculates attendance from scratch.

ZenHR Users are distinct from Employees — a person can have system login access without being a full Employee record. We extract all ZenHR User accounts with their assigned roles and email addresses. Recruit CRM User provisioning is separate from Candidate records; we provide a written user-role matrix mapping ZenHR roles to Recruit CRM role configurations (Teams and Custom Roles are available on the Business tier). The customer's Recruit CRM admin provisions users directly using the provided matrix. We do not create Recruit CRM user accounts via API without explicit admin credentials and permission.