HRMS migration
Field-level mapping, validation, and rollback between Ashby and BambooHR. We move data and schema; workflows are rebuilt natively in BambooHR.
Ashby
Source
BambooHR
Destination
Compatibility
7 of 11
objects map 1:1 between Ashby and BambooHR.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Ashby to BambooHR is a platform-type migration, not a record copy. Ashby is an ATS-first system built around Candidates, Applications, Jobs, and Openings with a recruiting lifecycle model. BambooHR is an HRIS-first system built around Employees, with a separate ATS module for Job Openings and Applicants. The core migration challenge is reshaping Ashby's recruiting pipeline objects into BambooHR's employee-centric schema—Accepted Offers in Ashby become new Employee records in BambooHR, while pipeline Candidates and Applications must be handled as archived or in-progress records in BambooHR's Jobs module. We export the full Ashby data set via the candidates and applications endpoints, map compensation and start dates from Offer records into BambooHR's employee fields, and preserve candidate history as attachments or notes on the corresponding Job Application record. Workflows, interview plan automation triggers, and Ashby's analytics dashboards do not migrate; we deliver a written inventory of these for the customer's admin to rebuild in BambooHR or document as a gap.
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 BambooHR, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Ashby
Candidate
BambooHR
Employee (post-offer) or Job Application (in-pipeline)
1:manyAshby Candidates who have accepted an offer map to BambooHR Employee records with name, email, phone, start date, and compensation pulled from the corresponding Offer. Candidates in earlier pipeline stages (Sourcing through Interview) map to BambooHR Job Application records tied to a BambooHR Job Opening. We separate the migration at offer acceptance status so that the employee record in BambooHR contains the HRIS fields (department, employment status, manager) rather than recruiting fields.
Ashby
Application
BambooHR
Job Application
1:1Ashby Application records (candidates linked to specific Jobs and Openings) map to BambooHR Job Application records. The application submission date, current stage, and stage transition history migrate as metadata fields or as notes attached to the BambooHR application. BambooHR's application record does not support the full stage-history timeline that Ashby captures, so we preserve stage history as a note or attachment in the migration.
Ashby
Job
BambooHR
Job Opening
1:1Ashby Job records (top-level job postings with title, department, team, location, status) map to BambooHR Job Opening records. Job board distribution settings in Ashby are documented for manual reconfiguration in BambooHR because BambooHR manages job distribution through its own integrations. We export the job description, requirements, and hiring team assignments and map them to BambooHR's Job Opening fields.
Ashby
Opening
BambooHR
Job Opening (count)
1:1Ashby Openings (individual headcount slots within a Job) map to the headcount count on a BambooHR Job Opening. Multi-opening positions in Ashby (e.g., 3 backend engineer slots) are represented as a single BambooHR Job Opening with a headcount value of 3. We aggregate opening counts during export and set the corresponding field in BambooHR.
Ashby
Offer
BambooHR
Employee (compensation and start date)
1:1Ashby Offer records carry compensation details (salary, equity, bonus), start date, and e-signature status. These map to BambooHR Employee fields in the jobInformation table (pay rate, pay frequency, hire date). Ashby's default salary offer field maps to BambooHR's payRate. Custom offer fields supported by Ashby's BambooHR integration (jobInformation and employeeStockOptions tables) migrate as Employee custom fields if the customer is on a BambooHR tier that supports custom fields.
Ashby
User
BambooHR
Employee (as user)
1:1Ashby Users (recruiters, hiring managers, admins) with active roles map to BambooHR Employee records. We export role assignments and flag which Ashby users correspond to BambooHR system users versus passive employees. Note that Ashby's elevated seat pricing model (separate from recruiter seats) means the number of active Ashby users may differ from the BambooHR employee count; we scope the user count separately during discovery.
Ashby
Interview Plan
BambooHR
Job Opening (as configuration notes)
lossyAshby Interview Plans with stage structures, interviewer assignments, and scorecard templates export as configuration documentation. Automated activity triggers (booking links, assessment invitations) tied to stage entry are tier-gated and do not migrate. We deliver a written map of every active interview plan with its stage sequence, scorecard fields, and automation triggers for the customer's admin to rebuild in BambooHR's Job Opening configuration.
Ashby
Activity (calls, emails, notes, scorecards)
BambooHR
Employee Note or Job Application Note
1:1Ashby Activity records (calls, emails, internal notes, scorecards) attached to Candidates and Applications migrate as BambooHR Employee Notes or Job Application Notes. We export activity type, timestamp, author, and content. Note that BambooHR's note model is simpler than Ashby's engagement timeline—ordering and attribution are preserved but the rich activity stream visualization is not. We discuss with the customer whether to migrate full history or a summary.
Ashby
Custom Field (candidate, application, job)
BambooHR
Employee Custom Field or Job Opening Custom Field
lossyAshby custom fields on Candidates, Applications, and Jobs enumerate via customField.list. We export all custom field definitions and values, then map them to corresponding BambooHR custom fields. Critical constraint: BambooHR custom fields are not available on the Foundations plan. If the customer is on a BambooHR tier that restricts custom fields, we flag which Ashby custom fields need to be dropped or consolidated into standard fields.
Ashby
Department and Team
BambooHR
Department
1:1Ashby Departments and Teams map to BambooHR Department records. Department hierarchy migrates as a nested structure. Team assignments on Jobs and Users map as department associations in BambooHR. We resolve the hierarchy during export and create the matching department tree in BambooHR before migrating any records that reference it.
Ashby
Source and Tag
BambooHR
Job Application (as metadata)
lossyAshby Candidate Sources and Tags (recruiting channels, skill tags, boolean tags) migrate as text metadata on the corresponding BambooHR Job Application record. BambooHR does not have a native tagging model equivalent to Ashby's sourcing CRM, so we append tag values as comma-separated text fields or as application notes for the customer's review.
| Ashby | BambooHR | Compatibility | |
|---|---|---|---|
| Candidate | Employee (post-offer) or Job Application (in-pipeline)1:many | Fully supported | |
| Application | Job Application1:1 | Fully supported | |
| Job | Job Opening1:1 | Fully supported | |
| Opening | Job Opening (count)1:1 | Fully supported | |
| Offer | Employee (compensation and start date)1:1 | Fully supported | |
| User | Employee (as user)1:1 | Fully supported | |
| Interview Plan | Job Opening (as configuration notes)lossy | Fully supported | |
| Activity (calls, emails, notes, scorecards) | Employee Note or Job Application Note1:1 | Fully supported | |
| Custom Field (candidate, application, job) | Employee Custom Field or Job Opening Custom Fieldlossy | Fully supported | |
| Department and Team | Department1:1 | Fully supported | |
| Source and Tag | Job Application (as metadata)lossy | 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
BambooHR gotchas
Undocumented API rate limits can trigger 503 errors
Per-employee pricing model requires active record count verification
API credentials must be sent on every request to avoid extra round trips
Custom field schema varies per account and requires manual inventory
Document and attachment exports are not covered by standard report exports
Pair-specific challenges
Migration approach
Discovery and tier verification
We audit the source Ashby account across tier (Foundations/Plus/Enterprise), candidate volume, job count, open application count, offer history depth, custom field inventory, and active user count. We verify the destination BambooHR plan tier and confirm whether custom fields are supported. The discovery output is a written migration scope with record counts per object, a custom field gap analysis, and a confirmation of which Ashby data sets will migrate fully versus as summaries or documentation.
BambooHR destination preparation
We configure the BambooHR destination before any data import. This includes creating departments and teams matching Ashby's org structure, creating BambooHR Job Openings that correspond to Ashby Jobs, pre-creating file categories for resume and offer letter sync if the customer plans to use BambooHR's native file handling, and verifying that the API key has access to all required tables and fields. If the customer is on a BambooHR tier that restricts custom fields, we create a field consolidation plan and get approval before proceeding.
Sample migration and reconciliation
We run a test migration with a representative sample (typically 50-100 records per object) into the customer's BambooHR sandbox environment. The customer's HR lead reviews the mapped records, confirms that employee fields are populated correctly, spot-checks custom field values, and validates that file attachments appear in the correct categories. We correct any mapping errors before the production migration begins.
Full data migration in dependency order
We execute production migration in object dependency order: Departments and Teams first (referenced by Jobs and Users), then Job Openings, then Users, then Candidate and Application records for in-pipeline candidates (mapped to BambooHR Job Applications), then Offer records converted to Employee records for hired candidates (mapped to BambooHR Employees with compensation and start date). Activity history migrates as notes attached to the corresponding record. Each phase emits a row-count reconciliation report.
Interview plan and automation inventory delivery
We export Ashby Interview Plan configurations with their stage structures, scorecard fields, and automation triggers and deliver them as a written configuration document. We flag which automation triggers are tier-gated in Ashby and document the equivalent BambooHR Job Opening configuration. The customer's admin rebuilds interview plans and any onboarding task workflows in BambooHR using the delivered inventory.
Cutover, validation, and post-migration handoff
We freeze Ashby writes during cutover, run a final delta migration of any records modified during the migration window, then mark BambooHR as the system of record for new hires. We deliver the full migration record report with record counts, mapping summary, and a list of any records that could not migrate due to data quality issues. We support a three-day hypercare window for reconciliation issues. Workflow rebuild, interview plan recreation, and ongoing BambooHR administration are outside standard scope and can be scoped as a separate engagement.
Platform deep dives
Ashby
Source
Strengths
Weaknesses
BambooHR
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 BambooHR.
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 BambooHR migration scoping. Not seeing yours? Book a call.
Walk through your Ashby to BambooHR 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 BambooHR
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.