HRMS migration
Field-level mapping, validation, and rollback between Eploy and Recruit CRM & ATS. We move data and schema; workflows are rebuilt natively in Recruit CRM & ATS.
Eploy
Source
Recruit CRM & ATS
Destination
Compatibility
10 of 12
objects map 1:1 between Eploy and Recruit CRM & ATS.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Eploy to Recruit CRM is a data-model convergence project. Eploy's recruitment lifecycle includes Jobs, Candidates, Offers, Onboarding records, Workflow Stages, and Talent Pools; Recruit CRM's is built around Jobs with Kanban pipeline stages, Candidates, and a combined ATS-CRM view. Eploy's flat-rate pricing (£695/month entry) contrasts with Recruit CRM's per-seat model ($59-$159/user/month with a free trial), making the switch attractive for smaller agencies. We migrate active candidates with full application history, job requisitions with salary bands and locations, active offers, talent pool memberships, and communication history. Eploy's custom workflow stages require a customer-confirmed mapping table because stage names are organisation-defined. Onboarding records and assessment scores that live in Eploy's separate module schema migrate as CSV complements where the API returns partial schemas. Workflows, automations, and hiring manager portal permissions do not migrate as code; we deliver a written inventory for the admin to rebuild in Recruit CRM's pipeline configuration.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Eploy object lands in Recruit CRM & ATS, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Eploy
Job Requisition
Recruit CRM & ATS
Job
1:1Eploy Jobs (requisitions) map directly to Recruit CRM Jobs. We preserve job title, department, location, salary bands, and the job-to-workflow linkage. Eploy's custom job fields migrate as custom fields in Recruit CRM, with the field schema discovered during scoping. The job's workflow assignment is not a native Recruit CRM concept; we capture it as a tag or pipeline stage name for the customer to configure after migration.
Eploy
Candidate
Recruit CRM & ATS
Candidate
1:1Eploy Candidate records map to Recruit CRM Candidates with full contact details, application history, skills, and status preserved. Eploy's candidate_id becomes the dedupe key. We flag any custom properties added to the candidate schema and create corresponding custom fields in Recruit CRM before import. Candidate documents attach via Recruit CRM's file upload endpoint after the candidate record is created.
Eploy
Application
Recruit CRM & ATS
Candidate-Job association (associated fields)
1:1Eploy stores a candidate's application to a job as a separate record; Recruit CRM links candidates to jobs and exposes per-job associated fields via POST /v1/candidates/associated-field/{candidate}/{job}. We map Eploy's application status and stage to Recruit CRM's associated_fields structure, with field_id values pre-discovered from the destination schema during scoping.
Eploy
Workflow Stage
Recruit CRM & ATS
Pipeline Stage
lossyEploy workflow stages are organisation-defined and discovered by aggregating distinct stage values from active jobs during scoping. Recruit CRM uses pipeline stages on its Kanban board. We build a customer-confirmed mapping table during scoping that maps each Eploy stage name to the destination pipeline stage. Stage transition timestamps migrate as associated field values or custom fields on the candidate-job association.
Eploy
Hiring Manager Portal
Recruit CRM & ATS
User assignment
1:1Hiring manager assignments in Eploy (which user is tied to which job and stage) map to Recruit CRM User records assigned as owners or collaborators on Job and Candidate records. Role-based permissions that do not have a Recruit CRM equivalent are documented for the customer's admin to configure post-migration.
Eploy
Offer
Recruit CRM & ATS
Job (offer data)
1:1Active offer records from Eploy (salary, start date, role details, e-signature status) migrate as structured data on the associated Candidate or Job record in Recruit CRM. E-signature audit trails migrate as document attachments where the API exposes them. Recruit CRM does not have a native Offer object; we document the customer-chosen target field for this data during scoping.
Eploy
Onboarding Record
Recruit CRM & ATS
Manual export (CSV complement)
1:1Eploy's onboarding module may expose a partial schema via API. We query the onboarding endpoints explicitly during discovery. Records that return partial schemas (reference collection status, contract status, compliance documents) are flagged and recommended for manual CSV export as a complement to the API-driven migration. Recruit CRM has no native onboarding module, so onboarding data requires a post-migration process decision.
Eploy
Employee Referral
Recruit CRM & ATS
Candidate (referral source)
1:1Eploy referral records link an employee to a referred candidate with reward status. We preserve referral attribution by populating a referral source field on the Candidate record in Recruit CRM, using the referring employee name as a text field or linking to a Recruit CRM User record if the employee exists as a user.
Eploy
Talent Pool
Recruit CRM & ATS
Tag or Segment
1:1Eploy Talent Pools are saved candidate collections. We migrate pool memberships as tags on the Candidate record in Recruit CRM, preserving the pool name as the tag value. If Recruit CRM introduces segment functionality, we map pool-to-segment during scoping.
Eploy
Custom Property
Recruit CRM & ATS
Custom Field
lossyOrganisations add custom fields to Jobs, Candidates, and other objects in Eploy. We detect the full custom property schema during discovery and create corresponding custom fields in Recruit CRM before migration. For custom properties with picklist values, we replicate the picklist options in Recruit CRM's field configuration.
Eploy
Assessment
Recruit CRM & ATS
Custom Field (text or number)
1:1Eploy assessment scores and results attach to Candidate records as structured data. We migrate available assessment fields as custom fields on the Candidate record. Visual or graphic scores that do not have a structured API representation are mapped to text equivalents with the original value preserved in a notes field.
Eploy
Document/Attachment
Recruit CRM & ATS
File attachment
1:1Resumes, cover letters, and compliance documents attach to Candidates and Jobs in Eploy as download URLs. We enumerate all attachment URLs, download each file to temporary storage, then upload each to Recruit CRM's attachment endpoint linked to the corresponding Candidate record. Large volumes of attachments (common in compliance-heavy sectors) extend migration time and require storage headroom. We batch document migration after the primary record import completes.
| Eploy | Recruit CRM & ATS | Compatibility | |
|---|---|---|---|
| Job Requisition | Job1:1 | Fully supported | |
| Candidate | Candidate1:1 | Fully supported | |
| Application | Candidate-Job association (associated fields)1:1 | Fully supported | |
| Workflow Stage | Pipeline Stagelossy | Fully supported | |
| Hiring Manager Portal | User assignment1:1 | Fully supported | |
| Offer | Job (offer data)1:1 | Fully supported | |
| Onboarding Record | Manual export (CSV complement)1:1 | Fully supported | |
| Employee Referral | Candidate (referral source)1:1 | Fully supported | |
| Talent Pool | Tag or Segment1:1 | Fully supported | |
| Custom Property | Custom Fieldlossy | Fully supported | |
| Assessment | Custom Field (text or number)1:1 | Fully supported | |
| Document/Attachment | File attachment1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Eploy gotchas
API rate limits cap daily call volumes per tier
API keys are tied to individual user records
Onboarding module data may live in a separate schema
Custom workflow stages require mapping table creation
Document attachments require separate download-then-upload passes
Recruit CRM & ATS gotchas
API rate limits are license-scaled and can throttle bulk migration
Custom field schemas vary per organization and require field-level mapping
Files and email attachments require separate extraction and re-upload
Email sequences and automation logic do not transfer between platforms
Pair-specific challenges
Migration approach
Discovery and rate-limit scoping
We audit the source Eploy account across subscription tier, API rate limit cap (1,000 to 50,000 calls/day depending on tier), custom job fields, custom candidate properties, workflow stage names (aggregated from active jobs), onboarding module schema availability, talent pool names, and document attachment volume. We also verify that a dedicated Eploy service account with read permissions across all objects is active and its API key is valid. The discovery output is a written scope document and an honest assessment of what Eploy's API returns completely versus partially versus not at all.
Data mapping and workflow stage mapping table
We map every Eploy object to its Recruit CRM equivalent: Jobs to Jobs, Candidates to Candidates, Applications to associated fields on the Candidate-Job pair, Offers to custom fields on Candidate or Job, Talent Pools to tags, and Referrals to a referral source field. The workflow stage mapping table is built by aggregating distinct stage names from active jobs and pairing each with a Recruit CRM pipeline stage. This table requires customer confirmation before migration begins. Custom properties from Eploy are mapped to Recruit CRM custom fields, with picklist values replicated in the destination configuration.
Pre-migration data clean and dedupe
We run data quality analysis across the Eploy candidate database, flagging duplicate records, incomplete contact fields, and records with no email address that cannot be linked to an owner. We recommend cleaning duplicates before migration to avoid carrying the same dedupe problems into Recruit CRM. Candidates with no application history and no contact details in the past 24 months are archived rather than migrated unless the customer specifies otherwise. Onboarding module records that return partial schemas are flagged for manual CSV export as a parallel workstream.
Recruit CRM schema provisioning
We create all required custom fields in Recruit CRM before any data is written, including custom fields for offer data, assessment scores, referral attribution, and any Eploy custom properties without a standard Recruit CRM equivalent. If Recruit CRM's associated field IDs have not been pre-discovered, we query the /v1/jobs/{job}/custom-fields endpoint to retrieve field IDs for the candidate-job association mapping step.
Migration in dependency order with rate-limit handling
We run migration in dependency order: Jobs first (as parent records), then Candidates (with the dedupe key set), then application history (as associated fields via the /v1/candidates/associated-field endpoint with field IDs resolved), then Offers (as custom field writes), then Talent Pool memberships (as tags), then communication history. Eploy API rate limits are respected by throttling workers to stay within the subscribed tier's calls-per-day cap, with exponential backoff on 429 responses and checkpointing to resume from the last successful record. Document attachments migrate in a post-record phase after primary data is confirmed in Recruit CRM.
Cutover, validation, and handoff
We run a final delta migration of any records created or modified in Eploy during the migration window, then enable Recruit CRM as the system of record. We deliver a reconciliation report comparing record counts in Eploy against Recruit CRM, spot-checking 25-50 records for field-level accuracy. We deliver a written inventory of Eploy workflows, automations, and hiring manager portal permissions that cannot migrate as code, with Recruit CRM equivalents documented for the customer's admin to configure post-migration. We do not rebuild Eploy workflows in Recruit CRM's pipeline configuration as part of the standard migration scope.
Platform deep dives
Eploy
Source
Strengths
Weaknesses
Recruit CRM & ATS
Destination
Strengths
Weaknesses
Complexity grading
Standard HRMS migration. 1 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Eploy and Recruit CRM & ATS.
Object compatibility
1 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Eploy: 10 requests per second; daily tier caps of 1,000 / 5,000 / 10,000 / 50,000 depending on subscribed tier.
Data volume sensitivity
Eploy doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Eploy to Recruit CRM & ATS migration scoping. Not seeing yours? Book a call.
Walk through your Eploy to Recruit CRM & ATS migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Eploy
Other ways to arrive at Recruit CRM & ATS
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.