HRMS migration
Field-level mapping, validation, and rollback between Ashby and Recruit CRM & ATS. We move data and schema; workflows are rebuilt natively in Recruit CRM & ATS.
Ashby
Source
Recruit CRM & ATS
Destination
Compatibility
10 of 12
objects map 1:1 between Ashby and Recruit CRM & ATS.
Complexity
BStandard
Timeline
2-3 weeks
Overview
Moving from Ashby to Recruit CRM is a migration from an in-house-focused ATS+CRM built for scaling tech companies to a recruitment-agency-focused platform serving over 100 countries. Ashby's Candidate-Application-Job-Opening-Offer hierarchy maps to Recruit CRM's simpler Candidate-Job structure; multi-opening positions in Ashby become multiple Jobs in Recruit CRM. Ashby's RPC-style API with its 15 req/min rate limit on report endpoints shapes our chunking strategy, and the elevated seat pricing model that surprises teams at renewal is a key driver for the switch. We do not migrate Ashby Interview Plans, Sequences, or automations as code; we deliver a written inventory of these for the customer's admin to rebuild in Recruit CRM.
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 Ashby 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.
Ashby
Candidate
Recruit CRM & ATS
Candidate
1:1Ashby Candidate records map directly to Recruit CRM Candidates. We preserve contact info, source attribution, status, and activity history. Ashby's employee-type custom fields (introduced December 2025, linking candidates to internal employees) require pre-creation of equivalent custom fields in Recruit CRM before migration. Activity history (calls, emails, notes) is extracted via separate API calls and merged into the candidate timeline rather than relying on file-based import which omits lifecycle history.
Ashby
Application
Recruit CRM & ATS
Application
1:1Ashby Application records linking a Candidate to a Job map to Recruit CRM Applications. We preserve submission date, current stage, and all stage transitions. Application history is reconstructed from Ashby's application endpoints and mapped to Recruit CRM's application record with stage history maintained as status-change timestamps.
Ashby
Job
Recruit CRM & ATS
Job
1:1Ashby Job records map to Recruit CRM Job postings. Job title, department, location, status, and description transfer directly. Ashby's job board distribution settings are noted for manual reconfiguration in Recruit CRM's job distribution panel.
Ashby
Opening
Recruit CRM & ATS
Job (split)
1:manyAshby's Openings (individual headcount slots within a Job) have no direct Recruit CRM equivalent. Each Ashby Opening maps to a separate Recruit CRM Job posting with a naming convention referencing the original Job and opening number (e.g., 'Senior Engineer - Opening 1 of 3'). We preserve the opening count and headcount allocation as custom fields on each split Job record.
Ashby
Offer
Recruit CRM & ATS
Offer
1:1Ashby Offer records including compensation details, start dates, and e-signature status map to Recruit CRM Offers. Offer history and status transitions preserve for compliance and audit purposes. We map Ashby's offer status to Recruit CRM's offer status enum during import.
Ashby
User
Recruit CRM & ATS
User
1:1Ashby Users (recruiters, hiring managers, admins) map to Recruit CRM Users. We resolve by email match. Elevated-seat Ashby users who are hiring managers are mapped to standard Recruit CRM users without a tier distinction, which is part of the cost-reduction appeal of the migration. Role and permission structures are mapped to Recruit CRM's user role hierarchy.
Ashby
Interview Plan
Recruit CRM & ATS
Pipeline Stage (documentation)
1:1Ashby Interview Plans with their stage definitions and activity triggers do not migrate as code. We export the plan structure (stage names, stage order, activity definitions) to a written inventory document for the customer's admin to configure as pipeline stages and stage-specific tasks in Recruit CRM. Automated activity triggers (booking links, assessment invitations) are documented with their tier requirements; Plus/Enterprise-gated triggers are flagged for manual recreation.
Ashby
Sequence
Recruit CRM & ATS
Email Template (documentation)
1:1Ashby email sequence templates export with their body content, stage definitions, and step cadence. The sequence itself does not migrate as an active cadence. We deliver a written inventory of every Ashby sequence with template content, step count, and recommended Recruit CRM template or automation replacement. The customer's admin rebuilds the cadence in Recruit CRM's email workflow tools.
Ashby
Custom Field
Recruit CRM & ATS
Custom Field
lossyAshby custom fields on Candidates, Applications, and Jobs are enumerated via customField.list. We export all custom field definitions and values, pre-create matching custom fields in Recruit CRM (text, number, date, picklist, checkbox types), and map values during migration. Ashby's Employee-type custom fields require particular attention: the linked employee record must exist in Recruit CRM or be resolved as a text field if no equivalent Employee object exists.
Ashby
Activity (calls, emails, notes, scorecards)
Recruit CRM & ATS
Activity
1:1Ashby activity records export per candidate and application via the candidates and applications endpoints. We perform a two-step extraction: file-based export for core candidate records plus separate API calls for activity history, then stitch records together before Recruit CRM import. This avoids the lifecycle-history loss that occurs with file-only migration. Customer approval of the two-step approach is required before migration begins.
Ashby
Department and Team
Recruit CRM & ATS
Department
1:1Ashby Department and Team records map to Recruit CRM Departments. Department hierarchy and department-level permissions are preserved in the migration. Team assignments on Jobs are mapped to department associations in Recruit CRM.
Ashby
Assessment (HackerRank, CoderPad)
Recruit CRM & ATS
Activity attachment (documentation)
1:1Assessments from Ashby integrations (HackerRank, CoderPad, Checkr) link to Ashby as third-party records. We export assessment results attached to applications and map the association as an activity note in Recruit CRM referencing the original assessment tool and result. The assessment tool account and integration must be reconnected independently in Recruit CRM's settings.
| Ashby | Recruit CRM & ATS | Compatibility | |
|---|---|---|---|
| Candidate | Candidate1:1 | Fully supported | |
| Application | Application1:1 | Fully supported | |
| Job | Job1:1 | Fully supported | |
| Opening | Job (split)1:many | Fully supported | |
| Offer | Offer1:1 | Fully supported | |
| User | User1:1 | Fully supported | |
| Interview Plan | Pipeline Stage (documentation)1:1 | Fully supported | |
| Sequence | Email Template (documentation)1:1 | Fully supported | |
| Custom Field | Custom Fieldlossy | Fully supported | |
| Activity (calls, emails, notes, scorecards) | Activity1:1 | Fully supported | |
| Department and Team | Department1:1 | Fully supported | |
| Assessment (HackerRank, CoderPad) | Activity attachment (documentation)1: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.
Ashby gotchas
Report API rate limits throttle large-scale migrations
File-based migrations omit candidate lifecycle history
Elevated seat pricing not visible at initial pricing discussion
Automation triggers are tier-gated and may not migrate
Dashboard layouts do not export via API
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 scoping
We audit Ashby across all object types: candidate volume, application count, job and opening structures, offer records, user count, custom field inventory, interview plan definitions, sequence templates, and activity volume. We identify which Ashby tier the customer is on (Foundations, Plus, Enterprise) because automation triggers and activity automations are gated at Plus and above. The discovery output is a written migration scope that includes the opening-to-job split rule, the two-step activity extraction approach, and an explicit list of what will not migrate as code (Interview Plans, Sequences, automations, dashboard layouts).
Schema design and Recruit CRM configuration
We pre-configure Recruit CRM to receive the Ashby data. This includes creating custom fields that match Ashby custom field types (text, number, date, picklist, checkbox), defining pipeline stages that correspond to Ashby application stages, setting up departments and teams to match Ashby's org structure, and configuring the opening-split naming convention for Jobs. We verify that any Ashby Employee-type custom fields have a valid resolution path in Recruit CRM before migration begins. All schema work happens in Recruit CRM's admin panel before any data is loaded.
Data cleaning and deduplication
We clean and deduplicate Ashby candidate records before export. Duplicate candidates (same email address, conflicting names) are flagged in a reconciliation report for the customer's admin to resolve. Custom field values are standardized to match Recruit CRM's expected formats. Any malformed data (incorrect date formats, missing required fields) is corrected or documented for manual resolution. Data quality issues identified here are resolved before extraction to prevent import errors in Recruit CRM.
Rate-limited extraction and record stitching
We extract Ashby data using the RPC API with the 15 req/min rate limit handled through time-window chunking and the 3-concurrent-operation cap respected throughout. Core records (candidates, applications, jobs, offers, users) are exported via file endpoints. Activity history (calls, emails, notes, scorecards) is extracted separately via the candidates and applications API endpoints and stitched to the candidate records before Recruit CRM import. We scope total record counts before extraction so the migration timeline is predictable even under rate limiting.
Recruit CRM import in dependency order
We load data into Recruit CRM in dependency order: Departments and Teams first, then Users, then Jobs (with opening-split records created), then Candidates, then Applications linked to the correct Jobs and Candidates, then Offers, then Activities via bulk import. Each phase emits a row-count reconciliation report against the Ashby source before the next phase begins. Any records that fail import (required field missing, custom field type mismatch) are logged to a remediation queue for resolution before re-import.
Cutover, validation, and handoff documentation
We freeze Ashby writes during cutover, run a final delta migration of any records created or modified during the migration window, then enable Recruit CRM as the system of record. We validate record counts across all object types and spot-check 25-50 records against the Ashby source. We deliver the Interview Plan inventory document, the Sequence template inventory, and the dashboard rebuild checklist to the customer's admin team. We support a one-week hypercare window for reconciliation issues. We do not rebuild Ashby Interview Plans, Sequences, or automations as Recruit CRM workflows; that is a separate engagement.
Platform deep dives
Ashby
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 Ashby 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
Ashby: 15 requests per minute per org; max 3 concurrent report operations (shared between report.generate and report.synchronous).
Data volume sensitivity
Ashby 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 Ashby to Recruit CRM & ATS migration scoping. Not seeing yours? Book a call.
Walk through your Ashby 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 Ashby
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.