HRMS migration
Field-level mapping, validation, and rollback between Greenhouse and BambooHR. We move data and schema; workflows are rebuilt natively in BambooHR.
Greenhouse
Source
BambooHR
Destination
Compatibility
3 of 10
objects map 1:1 between Greenhouse and BambooHR.
Complexity
BStandard
Timeline
1-3 weeks
Overview
Moving from Greenhouse to BambooHR is a schema simplification, not a field-for-field copy. Greenhouse separates Candidates from Applications with a one-to-many relationship; BambooHR uses a flat applicant record attached to each job opening. We split Greenhouse's relational model into BambooHR's flat structure at migration time, preserving candidate profiles, application history, job data, and compensation fields. Scorecards, interview kits, and Greenhouse's structured hiring workflows do not have a BambooHR equivalent and are delivered as a written rebuild inventory. We use Greenhouse's Harvest API v3 to extract data, transform records through the schema split, and load into BambooHR via its REST API with chunking and error reporting. Active candidates in-flight at migration cutover require a manual export step in the Greenhouse UI, which we plan and document as part of the migration schedule.
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 Greenhouse 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.
Greenhouse
Candidate
BambooHR
Applicant
1:manyGreenhouse Candidates are the person record with contact details, social URLs, tags, and custom field values. BambooHR Applicants are flat records tied to a specific job opening. We split Greenhouse's one-to-many Candidate-to-Application relationship by creating one BambooHR Applicant per Application and linking contact fields to the same underlying person record where applicable. Email deduplication across applications is handled by the customer-configured applicant matching rules in BambooHR.
Greenhouse
Application
BambooHR
Application
1:1Each Greenhouse Application (a Candidate's candidacy for a specific Job) maps directly to a BambooHR Applicant record. We preserve the application date, rejection or hire status, stage history timestamps, and source attribution. Note that BambooHR does not expose a dedicated Application object in the same way Greenhouse does; the applicant record itself carries the application state.
Greenhouse
Job
BambooHR
Job
1:1Greenhouse Jobs (requisition-level records) map to BambooHR Jobs. We preserve job title, department, office location, open/closed status, opening date, and job description. BambooHR does not support job boards, careers page hosting, or job distribution as native ATS features, so any Greenhouse-sourced job board URLs are preserved as a metadata reference list for the customer's team to re-create in BambooHR's job posting tool or external careers page.
Greenhouse
Offer
BambooHR
Custom fields on Applicant
lossyGreenhouse's dedicated Offer object stores compensation, start date, equity details, and offer status (pending, accepted, declined, retracted). BambooHR has no formal offer object; offer data must be captured as custom fields on the applicant record or managed manually after the hire is recorded. We migrate offer values as custom fields on the BambooHR Applicant and flag offer status fields that the customer must define in BambooHR's custom field builder before migration.
Greenhouse
Scorecard
BambooHR
Custom fields on Applicant
lossyGreenhouse stores structured scorecard ratings (interviewer, date, question, selected rating, optional free-text notes) as nested objects under Applications. BambooHR has no scorecard or structured evaluation feature. We extract each scorecard rating as a separate custom field on the BambooHR Applicant (scorecard_interviewer_name, scorecard_date, scorecard_rating_value) and document the full scorecard structure in the rebuild inventory. Free-text feedback and evaluation rubric metadata cannot be preserved because BambooHR has no structured notes or form builder for interview feedback.
Greenhouse
Interview Kit
BambooHR
Custom fields on Job
lossyGreenhouse Interview Kits store structured interview questions and evaluation rubrics scoped to specific jobs. BambooHR has no equivalent feature for defining structured interview questions or rating rubrics per job. We map the kit title and key question themes as custom text fields on the BambooHR Job record and document the full interview kit structure in the rebuild inventory for the customer's team to set up manually in BambooHR's job requirements or custom field builder.
Greenhouse
Custom Field
BambooHR
Custom Field
lossyGreenhouse supports custom fields across value types including short_text, long_text, yes_no, single_select, multi_select, currency, number, date, url, and user reference. We map each Greenhouse custom field to an equivalent BambooHR custom field of matching type. Multi-select fields are stored as comma-separated text in BambooHR. Currency fields use BambooHR's currency field type. User reference fields (pointing to Greenhouse users) are stored as the user's name in a text field unless a matching BambooHR employee record exists.
Greenhouse
Office and Department
BambooHR
Location and Department
lossyGreenhouse Offices and Departments (flat or tiered hierarchical structures) map to BambooHR Locations and Departments. Exact value matching is required for the integration to function. We validate that all Greenhouse department and office values exist as exact-match values in BambooHR's Location and Department fields before migration. Any values that do not match are flagged for the customer's admin to pre-create in BambooHR or remap to an existing value.
Greenhouse
Tag
BambooHR
Custom field (text)
lossyTags on Greenhouse Candidates and Applications migrate as comma-separated text values in a custom field on the BambooHR Applicant record. BambooHR does not have a native tag or label system for applicant records. We preserve the tag labels and note any tag-to-category mapping the customer has defined in Greenhouse for manual recreation in BambooHR's custom field structure.
Greenhouse
Candidate Document and Attachment
BambooHR
Employee Document
1:1Resumes, cover letters, and portfolio files attached to Greenhouse Candidates or Applications migrate as files linked to the corresponding BambooHR Applicant record. We extract files via Greenhouse's Harvest API, handle base64 encoding, and upload to BambooHR's document management via its file upload API. Resume files are associated with the applicant record using BambooHR's document folder structure. Any binary file type not supported by BambooHR's upload API is flagged in the migration report.
| Greenhouse | BambooHR | Compatibility | |
|---|---|---|---|
| Candidate | Applicant1:many | Fully supported | |
| Application | Application1:1 | Fully supported | |
| Job | Job1:1 | Fully supported | |
| Offer | Custom fields on Applicantlossy | Fully supported | |
| Scorecard | Custom fields on Applicantlossy | Fully supported | |
| Interview Kit | Custom fields on Joblossy | Fully supported | |
| Custom Field | Custom Fieldlossy | Fully supported | |
| Office and Department | Location and Departmentlossy | Fully supported | |
| Tag | Custom field (text)lossy | Fully supported | |
| Candidate Document and Attachment | Employee Document1: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.
Greenhouse gotchas
Bulk candidate import requires Plus or Pro tier
Active candidate migration is entirely manual
Historical migration takes 4–6 weeks for Greenhouse to process
Developer sandbox and audit log are Pro-only
CRM event limits in Core tier constrain activity history
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 validation
We audit the source Greenhouse account across subscription tier (Core, Plus, Pro), candidate and application record counts, job volume, custom field definitions and value types, scorecard and interview kit presence, attachment count and file size distribution, and any tier-gated objects (bulk candidate import availability, tiered office/department hierarchy). We use Greenhouse's Harvest API v3 to enumerate all records and their field schemas before designing the mapping. The discovery output is a written migration scope and a pre-migration checklist of values that must exist in BambooHR (job titles, departments, locations) before production migration begins.
BambooHR pre-configuration checklist
We work with the customer's BambooHR admin to validate and pre-create every value required for exact-match migration: all Greenhouse department values mapped to BambooHR Departments, all Greenhouse office values mapped to BambooHR Locations, all Greenhouse job titles pre-created in BambooHR under Settings > Employee Fields, and all Greenhouse custom field value types defined in BambooHR's custom field builder (text, date, currency, dropdown, multi-select). This step is a hard prerequisite for the production migration because mismatched values result in silent field skips or record rejection.
Schema design and relational-to-flat transformation
We design the migration schema to split Greenhouse's Candidate and Application objects into BambooHR's flat applicant model. The transformation includes: one BambooHR applicant record created per Greenhouse Application, contact fields mapped from the parent Greenhouse Candidate, scorecard ratings extracted as custom fields on the applicant, offer values mapped to custom fields on the applicant, and Greenhouse job linked as a reference field on the applicant record. We also define the custom field mapping table for all Greenhouse custom fields by type, noting multi-select collapse strategy and user reference conversion.
Sandbox migration and reconciliation
We run a full migration into BambooHR using a test job and test applicant records to validate the field mapping, custom field creation, document attachment upload, and error handling before any production records move. The customer's BambooHR admin reviews the test applicants, validates field content against the Greenhouse source, confirms document readability, and signs off the schema and mapping. Any mapping corrections, custom field type changes, or value mismatches are resolved here.
Production migration in dependency order
We run production migration in record order: Jobs first (required for applicant linking), then Applicants (with candidate contact fields, application history, and custom fields), then offer data and scorecard ratings (as custom fields on the applicant record), then candidate documents and attachments (parallel batched uploads with base64 encoding and chunking). Each phase emits a row-count reconciliation report showing records loaded, records skipped, and records requiring manual review. Active candidates in-flight at cutover are exported in a separate structured file for manual re-import by the customer's team.
Cutover, validation, and rebuild handoff
We freeze Greenhouse writes at cutover, migrate any records modified during the migration window as a delta pass, then enable BambooHR as the recruiting system of record. We deliver the full rebuild inventory covering: Greenhouse scorecard structure and evaluation rubrics requiring manual rebuild in BambooHR, Greenhouse interview kit themes requiring manual recreation in BambooHR job custom fields, Greenhouse pipeline stage and automation configuration outside migration scope, and a reference list of Greenhouse job board posting URLs for manual re-creation in BambooHR's job posting tool. We provide a one-week hypercare window for data discrepancy resolution.
Platform deep dives
Greenhouse
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 Greenhouse 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
Greenhouse: Not publicly documented with specific numbers; rate limits are applied separately for custom integrations and partner integrations with separate policies for each.
Data volume sensitivity
Greenhouse exposes a bulk API — large-volume migrations stream efficiently.
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 Greenhouse to BambooHR migration scoping. Not seeing yours? Book a call.
Walk through your Greenhouse 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 Greenhouse
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.