Migrate from PrimePay to Recruit CRM & ATS

PrimePay Employee records map to Recruit CRM Candidate records. Core fields (name, email, phone, address, hire date, employment type, status) migrate 1:1. PrimePay's Position Management stores job title, salary band, security permissions, and reporting lines on a separate Position record—these fields merge into Candidate custom fields (e.g., job_title__c, salary_range__c, reports_to__c) during migration. We flag this consolidation decision during scoping because it affects the destination custom field schema design.

PrimePay's patented Position records do not have a native Recruit CRM equivalent. We extract Position fields and merge them into the Candidate record as custom fields. Job description, salary range, security role, and reporting relationship become Candidate custom fields. If the customer has multiple active Positions per employee (rare but possible in matrix organizations), we append them as serialized notes or multiple custom fields. This is a scoping decision reviewed with the customer before migration begins.

PrimePay organizational structure (departments, cost centers, hierarchical org chart) maps to Recruit CRM Client records if the organization itself is a client, or to a custom organizational tag field on Candidate and Job Order. We preserve the full hierarchy as tagged categories so that recruiter filtering by department works in the new system. Cost center codes migrate as a custom field for financial reporting integration.

PrimePay payroll history (wages, deductions, taxes, garnishments, net pay per pay period) has no target object in Recruit CRM. Recruit CRM has no payroll module. We extract a payroll summary snapshot per employee (YTD earnings, current deduction setup, garnishment configurations) and deliver it as a CSV inventory for the customer's finance team to use outside Recruit CRM or in a separate payroll tool. We explicitly flag this gap during kickoff so the customer does not expect payroll records to appear in the destination.

Benefit plan assignments, coverage tiers, and deduction amounts per pay period have no target in Recruit CRM. We extract current enrollment snapshots as a CSV for the customer's HR team to manage separately. Active benefit elections can be stored as custom Candidate fields (e.g., benefits_elected__c as a multi-select) if the customer wants a reference record inside Recruit CRM, but this is optional and scoped during discovery.

PTO accrual policies and current balance snapshots have no Recruit CRM equivalent. We extract live balance data per employee as a CSV for the customer's HR team. If the customer wants a reference record on the Candidate, we can store a note field with the balance at time of migration, but Recruit CRM does not maintain accrual calculations. This is flagged as a post-migration HR workflow that needs a separate system or manual process.

Clock-ins, shift data, and leave approvals from PrimePay's time tracking module do not map to any Recruit CRM object. We extract summary data (average weekly hours, shift patterns, leave usage) and store it as custom fields on the Candidate record (e.g., preferred_shift__c, avg_hours_per_week__c, leave_notes__c) if relevant to placement decisions. Approval-state flags do not transfer because Recruit CRM has no approval workflow engine for time entries.

Employee documents (offer letters, contracts, tax forms) migrate as file attachments to the corresponding Candidate record if accessible via the PrimePay export. Resume files migrate as primary attachments. Compliance documents (I-9, E-Verify) are extracted as PDFs and stored as Candidate attachments with a compliance_documents tag. Some document types may require manual re-upload if PrimePay's export does not include file content.

Active onboarding task checklists and I-9 records map to Candidate stage entries and task notes in Recruit CRM. Task states (completed, in-progress, pending) migrate as notes on the Candidate record. Completed-task history often cannot be fully reconstructed; we migrate the active state snapshot and flag the historical detail gap. The customer rebuilds onboarding workflows inside Recruit CRM's kanban stages post-migration.

Effective-dated job title changes and compensation adjustments stored in PrimePay's time-relational structure migrate as historical entries on the Candidate record. We extract the effective-date sequence per employee and store it as a JSON-serialized custom field or as a series of dated notes. Current salary and title overwrite the active custom fields; historical entries are preserved for audit. This handling is reviewed with the customer during scoping since the compensation history has no native timeline view in Recruit CRM.

Federal, state, and local tax withholding configurations per employee have no Recruit CRM equivalent. We extract current W-4 derived values as a CSV inventory for the customer's payroll team. Tax setup must be reconfigured in the customer's chosen payroll platform post-migration. We do not attempt to store tax jurisdiction data on the Candidate record since Recruit CRM has no tax configuration module.

WC class codes, rates, and active claims linked to employee and position records migrate as Candidate custom fields (e.g., wc_class_code__c, wc_rate__c, wc_claim_status__c) and as notes. Historical claims are documented in a CSV for compliance reference. Recruit CRM has no native WC tracking; the custom field approach provides a reference record only.