HRMS migration
Field-level mapping, validation, and rollback between Eddy and Recruit CRM & ATS. We move data and schema; workflows are rebuilt natively in Recruit CRM & ATS.
Eddy
Source
Recruit CRM & ATS
Destination
Compatibility
9 of 10
objects map 1:1 between Eddy and Recruit CRM & ATS.
Complexity
BStandard
Timeline
2-4 weeks
Overview
Migrating from Eddy to Recruit CRM is a domain shift from an HRMS platform to an applicant tracking and recruitment CRM. Eddy is built for small businesses to manage onboarding, PTO, payroll, and employee documents; Recruit CRM is purpose-built for recruitment agencies to manage candidates, jobs, clients, and placements. The migration maps Eddy employee records to Recruit CRM candidate profiles, with work history and contact details preserved, company directory entries mapped to Recruit CRM client records, and employee documents transferred as attachments. Eddy's HRMS-specific objects including PTO balances, training records, payroll data, onboarding workflows, and company settings have no native Recruit CRM equivalents. We extract and deliver these as structured exports for manual entry or third-party HR tools post-migration. Workflows, automations, and HR-specific policies do not migrate; we deliver a written inventory for the customer's admin to rebuild.
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 Eddy 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.
Eddy
Employee
Recruit CRM & ATS
Candidate
1:1Eddy employee records map to Recruit CRM candidate profiles. We extract first name, last name, email, phone, job title, department, hire date, employment status, and work location as standard candidate fields. Eddy's employee directory hierarchy transfers as Recruit CRM candidate tagging by department. Employment status (active, on leave, terminated) migrates as a custom candidate field and is noted for admin review since it carries different meaning in a recruitment context.
Eddy
Company Settings / Organization
Recruit CRM & ATS
Client
1:1Eddy's company-level settings including business name and locations map to Recruit CRM client records. The company name becomes the client organization name, and primary location becomes the client address. This is a structural simplification since Recruit CRM does not have an org-level settings object—company data lives as client records. We flag which fields require admin review after import.
Eddy
Department
Recruit CRM & ATS
Tag or Custom Field
lossyEddy departments have no direct Recruit CRM equivalent. We map department names to Recruit CRM tags on candidate and client records. During scoping, the customer selects whether departments map to candidate skills tags, client industry tags, or a dedicated custom picklist field. This is a configuration decision confirmed before production import.
Eddy
Documents
Recruit CRM & ATS
Candidate Attachment
1:1Eddy employee documents (offer letters, contracts, signed agreements, certifications) migrate as Recruit CRM candidate attachments. We extract file blobs with original filenames and preserve upload timestamps. Document type classification from Eddy (offer letter, NDA, benefits form) is noted in the filename or a custom field since Recruit CRM attachments do not have a native type taxonomy.
Eddy
Onboarding Workflows
Recruit CRM & ATS
Candidate Note or Checklist
1:1Eddy onboarding step checklists and task assignments have no native Recruit CRM equivalent. We extract active onboarding tasks and completed steps as candidate notes with a timestamp and assignee, preserving what was done but not the workflow structure itself. The customer receives a written inventory of onboarding tasks requiring rebuild as Recruit CRM checklist items or a separate HR onboarding tool.
Eddy
Employee Status / Employment History
Recruit CRM & ATS
Candidate Note
1:1Eddy employment status changes, termination dates, and status change reasons migrate as candidate notes. We extract the status history timeline and attach it as a chronological note block on the candidate record so the full employment trajectory is visible to recruiters in Recruit CRM.
Eddy
PTO Policy
Recruit CRM & ATS
(no equivalent)
1:1Eddy PTO policies, accrual rates, and carry-forward rules have no Recruit CRM equivalent. Recruit CRM is an ATS and does not include HR time-off tracking. We export PTO policy configurations as a structured CSV deliverable for the customer's HR team to enter into their chosen HRMS or payroll tool post-migration.
Eddy
Training Record
Recruit CRM & ATS
(no equivalent)
1:1Eddy training completion records and certifications tied to employees have no Recruit CRM equivalent. Recruit CRM does not include training or certification tracking. We export training history as a structured CSV including employee name, training name, completion date, and expiration date for manual entry into the destination HR or compliance tool.
Eddy
Payroll Data
Recruit CRM & ATS
(no equivalent)
1:1Eddy payroll data including pay run history, compensation amounts, and payroll integration records are not fully exportable via API. Reviewers consistently note incomplete integration between Eddy's HR and payroll modules. We extract any available payroll records via CSV export where accessible and flag which records require manual extraction or reconciliation before migration finalization.
Eddy
Company Settings
Recruit CRM & ATS
Client Record
1:1Eddy company settings including locations, policy configurations, and org-level preferences have no dedicated Recruit CRM object. We map location data to Recruit CRM client address fields and deliver a written inventory of policy settings requiring manual reconfiguration in Recruit CRM or a companion HR tool.
| Eddy | Recruit CRM & ATS | Compatibility | |
|---|---|---|---|
| Employee | Candidate1:1 | Fully supported | |
| Company Settings / Organization | Client1:1 | Fully supported | |
| Department | Tag or Custom Fieldlossy | Fully supported | |
| Documents | Candidate Attachment1:1 | Fully supported | |
| Onboarding Workflows | Candidate Note or Checklist1:1 | Mapping required | |
| Employee Status / Employment History | Candidate Note1:1 | Fully supported | |
| PTO Policy | (no equivalent)1:1 | Fully supported | |
| Training Record | (no equivalent)1:1 | Fully supported | |
| Payroll Data | (no equivalent)1:1 | Mapping required | |
| Company Settings | Client Record1:1 | Mapping required |
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.
Eddy gotchas
Contract data cannot be exported via API
Reporting limitations require workarounds
Payroll and HR integration is incomplete
Per-employee pricing counts all employees including inactive
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 Eddy export scoping
We audit all migratable Eddy objects including employee records, company directory, departments, documents, and any available payroll CSV exports. We identify which records should migrate (active employees as candidates, terminated employees as archival notes), which require manual export (contracts, payroll data), and which have no Recruit CRM equivalent (PTO policies, training records, onboarding workflows). The discovery output is a written scope confirming object counts, document volumes, and a field-level mapping plan for each migratable object.
Field mapping and tagging strategy
We design the field-to-field mapping from Eddy employee properties to Recruit CRM candidate fields, confirming which Eddy properties (job title, department, location, hire date, employment status) map directly and which require transformation. We also confirm the department tagging strategy—departments as candidate skills tags, client industry tags, or a custom picklist field—before any data moves. Document field names and attachment types are aligned to Recruit CRM's supported formats.
Staging migration and reconciliation
We run a full migration into Recruit CRM's test environment using production data volumes. The customer reconciles record counts, spot-checks candidate profiles against source employee records, confirms that document attachments are present and readable, and validates the tagging and custom field structure. Any field mapping corrections happen at this stage before production import begins.
Production migration in dependency order
We run production migration in record-dependency order: client records first (from Eddy company settings), then candidate records (from Eddy employees) with department tags resolved, then document attachments linked to the correct candidate record. Each phase emits a row-count reconciliation report. We extract any available payroll and PTO data via CSV export for separate delivery and flag any records that required manual export from Eddy.
Cutover, validation, and HRMS handoff
We freeze writes in Eddy during cutover, run a final delta migration of records modified during the migration window, then enable Recruit CRM as the system of record for candidate and client data. We deliver the structured CSV exports for PTO, training records, and payroll data for manual entry into the customer's chosen HR or payroll tool, along with a written inventory of onboarding workflows and automations requiring rebuild. We support a brief hypercare window to resolve reconciliation issues reported in the first week of live use.
Platform deep dives
Eddy
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 Eddy 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
Eddy: Not publicly documented..
Data volume sensitivity
Eddy 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 Eddy to Recruit CRM & ATS migration scoping. Not seeing yours? Book a call.
Walk through your Eddy 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 Eddy
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.