Migrate from BeyondPay to Recruit CRM & ATS

BeyondPay Employee records with biographical and employment data (name, address, date of birth, hire date, termination date, job title, department, employment status) map to Recruit CRM Candidate records. The mapping preserves BeyondPay's employment status and job title as Candidate custom fields. Hire date and department map to Recruit CRM's built-in WorkExperience or custom fields. We request the complete employee roster from BeyondPay's implementation team during discovery and cross-reference against any active recruiting pipeline in Recruit CRM to avoid duplicating records for employees who are also active candidates.

Year-to-date wage totals, pay period earnings, and current compensation figures from BeyondPay's payroll history migrate as read-only custom fields on the corresponding Recruit CRM Candidate record. Historical payroll detail (per-pay-period breakdowns, deduction line items, tax withholdings) does not have a home in Recruit CRM's candidate schema and is excluded from the migration load. We document each excluded payroll record as a written inventory item for the customer's finance team to reconcile against their year-end reporting requirements.

Employee bank routing and account numbers for direct deposit migrate as encrypted custom fields on the Candidate record in Recruit CRM, noting that Recruit CRM is a recruiting and ATS platform rather than a payroll system. If the customer intends to use Recruit CRM as the system of record for candidate banking information for payroll purposes, we flag this as a non-standard use case requiring explicit confirmation from Recruit CRM's data handling policies. Employees with split deposit configurations are flagged individually for manual verification before activation.

Current health, dental, vision, and retirement benefit elections migrate as a structured snapshot in a Candidate custom field or attached document reference. Recruit CRM does not have a native benefits administration object, so we preserve the election data as a formatted summary that the customer's HR team can reference. Historical benefit election changes and effective-dated transitions are excluded from the migration scope as Recruit CRM does not support the temporal schema required for benefit history tracking.

Active court-ordered garnishments and voluntary deductions migrate as structured notes on the Candidate record with effective dates and deduction amounts. Inactive garnishments are excluded. Recruit CRM does not have a payroll deduction management object, so garnishments are preserved as reference data rather than as an active payroll process. The customer's HR or payroll team is responsible for re-establishing garnishments in their new payroll system after migration.

WC class codes, rates, and carrier information from BeyondPay's workers compensation configuration migrate as custom fields on Recruit CRM Client or Job records if the staffing agency manages temp or contract placements. Class code tables are verified against the destination system's values, and any mismatches are flagged for manual correction. Recruit CRM does not have a native workers compensation object, so WC settings are preserved as reference data.

Federal, state, and local tax codes and filing statuses configured in BeyondPay migrate as read-only custom fields on Candidate records in Recruit CRM. NJ and PA-specific codes are mapped explicitly. Recruit CRM does not process payroll tax calculations, so tax configuration data serves as a reference for the customer's new payroll system admin to re-enter during implementation.

Hourly employee time entries, overtime calculations, and accrual balance snapshots migrate as Activity records in Recruit CRM if the staffing agency uses Recruit CRM to track time against placements. We verify whether BeyondPay tracks PTO and leave accruals separately, as Recruit CRM's PTO tracking is limited compared to dedicated HRIS platforms. If accrual data cannot map cleanly to Recruit CRM's Activity schema, it is documented in the written inventory for the customer's HR team.

BeyondPay allows custom fields configured per client with no public schema documentation. We request a complete field inventory from the BeyondPay implementation team during discovery and map each to a corresponding custom field in Recruit CRM. Any custom fields without a clear destination equivalent are flagged for manual review; the customer chooses to map them to a custom Candidate field, store them as a document attachment, or exclude them from the migration scope.

BeyondPay does not expose a documented report export or template API. Custom report definitions, scheduled reports, and saved report configurations are not migratable and must be rebuilt in Recruit CRM's native reporting dashboard. We deliver a written inventory of every BeyondPay report the customer references regularly, with the equivalent Recruit CRM report or dashboard widget identified, so the customer's admin can rebuild them post-migration.