BambooHR's flat applicant model must be split into Greenhouse's relational Candidate + Application structure. The real bottlenecks: attachments (base64 encoding), Harvest v3 rate limits, and dependency-ordered loading.
There is no native migration path from BambooHR's ATS to Greenhouse. BambooHR treats applicants as flat records attached to job openings — one profile per application with statuses, ratings, and file IDs bundled together. Greenhouse separates this into distinct Candidate and Application records in a relational structure. The fundamental bottleneck is attachments: BambooHR stores resumes as file IDs requiring separate API calls to download, then each file must be base64-encoded (inflating size by ~33%) before uploading to Greenhouse's rate-limited API. Every migration requires splitting flat applicant records into Greenhouse's relational schema, dependency-ordered loading (attachments require application_id in v3), and handling the ~100 req/min BambooHR extraction limit against Greenhouse's fixed 30-second rate window.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Greenhouse Harvest API v1 and v2 will be deprecated and unavailable after August 31, 2026
Build new import pipelines against Harvest v3 (OAuth 2.0). Do not build on v1/v2 only to rewrite months later. (support.greenhouse.io)
BambooHR's star rating (1–5) has no direct Greenhouse equivalent
Greenhouse scorecards use structured attributes rated as definitely_not, no, yes, strong_yes, or no_decision. Serialize the star rating as a candidate note with a consistent format (e.g., "BambooHR Rating: 4/5") rather than forcing it into scorecard structure.
Build an error log from day one. Capture
BambooHR source ID, Greenhouse target ID (if created), HTTP status, error message, Retry-After value, and timestamp. This is your debugging lifeline when records fail at 3 AM.
It is not possible to bulk export candidates from Greenhouse to BambooHR
Each hired candidate must be exported individually from the candidate profile. Plan your post-migration workflow accordingly.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Scope candidates, pipelines and the compliance obligations that come with them.
Objective Agreed scope across candidates, applications, jobs and interview history, with legal signed up on retention.
Keep these open
-
Inventory every object in BambooHR
Count candidates, applications (a candidate can have many), jobs and requisitions, interviews, scorecards, offers, and resume files. Applications and scorecards usually outnumber candidates several times over, and resume files dominate storage.
Data Profiler Get real record counts instead of estimating from memory -
Settle retention and consent with legal
Candidate data is heavily regulated: GDPR right-to-erasure, EEOC/OFCCP record-keeping, and per-region retention windows that conflict with each other. Decide what may be migrated at all before you scope anything else — this frequently shrinks scope substantially.
Migrating candidate records whose consent has lapsed or whose retention window has expired creates a new compliance breach in the target system.
-
Map the hiring pipeline and agree the target stages
Document every job's pipeline, stage, and rejection reason, then agree the Greenhouse model with talent leadership. Stage definitions drive every funnel metric you report, so changing them silently rewrites your hiring analytics.
-
Catalogue integrations and the job-board estate
List job boards, careers-site integration, HRIS, background check, assessment platforms, calendar and email. The careers site and job boards are customer-facing, so their cutover needs its own plan and its own testing.
-
Build the business case and choose the window
Model licence delta, effort and recruiter productivity dip. Time the window against your hiring cycle: a migration during peak graduate recruitment or a hiring surge will fail on people, not technology.
Vendor Evaluator Score Greenhouse against alternatives on weighted criteria
BambooHR → Greenhouse specifics
- Outgrowing the built-in ATS
- BambooHR's ATS is designed to feed applicants into its HRIS — it optimizes for the HR manager's workflow, not the recruiter's. As hiring volume scales, teams hit limitations in pipeline customization, sourcing tooling, and reporting depth. Greenhouse was built for structured evaluation pipelines with scorecards, approval workflows, and configurable interview stages.
- Structured hiring at scale
- Greenhouse enforces consistent, auditable interview processes across departments and geographies. Its scorecard system — where interviewers rate candidates against predetermined attributes — is a core architectural feature, not a bolt-on.
- Integration ecosystem
- Greenhouse has 500+ integrations spanning job boards, assessment platforms, background check providers, and scheduling tools. BambooHR's ATS ecosystem is narrower by design — it prioritizes HRIS interoperability over recruiting tooling. Most companies keep BambooHR as HRIS, move recruiting into Greenhouse, and use the native Greenhouse-to-BambooHR integration for the hired-candidate handoff. (support.greenhouse.io)
Don't move on until
- Counts confirmed for candidates, applications, jobs and offers
- Retention and consent obligations confirmed with legal
- Hiring-stage model agreed with talent leadership
02 Data Audit Audit candidate data with compliance sitting next to you.
Objective Profiled exports with duplicates, expired records and resume files all quantified and triaged.
Keep these open
-
Export and profile candidates, applications and jobs
Profile each object separately and reconcile against API counts. Watch the candidate-to-application ratio: a mismatch usually means applications have been silently truncated by pagination.
Data Profiler Profile the BambooHR export for nulls, outliers and type drift -
Quantify duplicate candidates and agree survivorship
The same person applies repeatedly over years with different emails and name spellings. Measure the duplicate rate and agree survivorship rules — which record wins and what happens to the application history attached to the losers.
Merging candidates without agreed survivorship rules destroys application and interview history that you may be legally required to retain.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Identify records outside their retention window
Flag candidates whose consent has expired, who have exercised erasure, or who fall outside regional retention. Exclude them from scope and document the exclusion — you need to show the decision was deliberate.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Inventory resume files and attachments
Count files, total volume and MIME types, and check every attachment still resolves to a live URL. Expiring signed download URLs are the classic reason a resume migration completes with a large fraction of empty files.
Resume download URLs are often short-lived signed links. Fetch files close to load time or they will 404 mid-migration.
-
Verify relationship integrity
Confirm every application links to a live candidate and a live job, and every scorecard to a real interview. Orphaned applications produce a funnel report that does not tie to anything.
-
Clean, normalise and produce masked test data
Normalise emails, phone formats and locations, standardise timestamps to UTC, and generate a masked dataset for the sandbox. Real candidate data in a sandbox is a compliance breach in most jurisdictions.
PII Masker Generate a safe copy for sandbox and vendor testing
BambooHR → Greenhouse specifics
- Endpoints
- GET /v1/applicant_tracking/applications returns paginated application lists. GET /v1/applicant_tracking/applications/{id} returns full details including resume/cover letter file IDs. (documentation.bamboohr.com)
- Authentication
- HTTP Basic Auth — API key as username, any string as password.
- Rate limits
- BambooHR does not officially publish rate limits. Community consensus is approximately 100 requests per minute per API key. The API returns 429 Too Many Requests when exceeded. Implement exponential backoff.
- Attachments
- Resume and cover letter are returned as file IDs. Each requires a separate download request. Plan for 2–3x the API call volume if most candidates have attachments.
- Pagination
- Check for pagination keys on the applications list endpoint. Don't assume single-page responses.
Don't move on until
- Duplicate candidate rate quantified with a merge policy agreed
- Records outside retention identified and excluded
- Resume and attachment inventory complete with total volume
03 Field Mapping Map the candidate-application-job triangle before anything else.
Objective A signed mapping covering objects, stages, rejection reasons, scorecards and EEO fields.
Keep these open
-
Map the candidate, application and job model
ATS platforms differ on whether a person or an application is the primary record. Establish this first: getting it wrong means one candidate becomes five, or five applications collapse into one, and the entire field map has to be redone.
Candidate-centric and application-centric models are not interchangeable. Confirm which Greenhouse uses before mapping any field.
Schema Mapper Opens pre-loaded with the BambooHR → Greenhouse field pair -
Map pipeline stages and rejection reasons exhaustively
Enumerate every stage and rejection reason across all jobs, including retired values on historical applications, and map each explicitly. Unmapped rejection reasons are both a reporting gap and, in regulated hiring, a compliance one.
-
Decide EEO and diversity data handling
These fields are separately regulated and often legally required to be stored apart from the candidate record. Confirm with legal whether they migrate at all, and how Greenhouse isolates them.
EEO data usually cannot be migrated into ordinary custom fields without breaching the segregation rules that govern it.
-
Map interviews, scorecards and feedback
Structured scorecards rarely have a native equivalent. Decide whether to reconstruct them, flatten them into notes, or keep them only in the archive — and be explicit that flattening loses the ability to report on them.
JSON to CSV Converter Flatten nested API responses into a reviewable sheet -
Plan resume and file migration
Confirm size limits, MIME support and whether Greenhouse re-parses resumes on upload. Re-parsing can overwrite carefully curated candidate fields with worse machine-extracted values, so test it deliberately.
-
Set load order and freeze the spec
Users, then jobs, then candidates, then applications, then interviews and scorecards, then files. Keep source IDs in custom fields, then version and sign off the spec.
-
Deduplicate candidates
Group BambooHR applications by email address. Each unique email becomes one Greenhouse Candidate. For applicants without email, use phone + name as a fallback key, or assign a placeholder email for cleanup.
-
Split into Candidate + Application
For each group, create one Candidate payload and N Application payloads.
Data Format Converter Reshape the export into the format Greenhouse's importer expects -
Map statuses to stages
Build a lookup table mapping BambooHR application statuses to Greenhouse job stage IDs.
Don't move on until
- Candidate/application/job model mapped and reviewed
- Every stage and rejection reason explicitly mapped
- EEO and diversity field handling agreed with legal
04 Test Migration Pilot whole candidate journeys, not isolated records.
Objective A sandbox pilot where candidate journeys, funnel metrics and resume files all verify.
Keep these open
-
Configure the Greenhouse sandbox with the agreed pipelines
Create jobs, pipeline stages, scorecard templates, user roles and custom fields first. Loading applications before the stages exist puts every candidate in a default stage and invalidates the pilot.
-
Select complete candidate journeys as the pilot slice
Take 100-200 candidates with all their applications, interviews, scorecards and files — including repeat applicants, hires, rejections at every stage, and candidates on multiple jobs. Repeat applicants are where the model mapping actually gets tested.
-
Run the load in dependency order with logging
Jobs, candidates, applications, interviews, then files, logging each request against its source ID. Track file uploads separately: they fail for different reasons and at different rates than record writes.
-
Verify journeys and funnel metrics
Confirm each candidate sits at the right stage on the right job with their history intact, and that per-stage funnel counts match BambooHR for the pilot jobs. Funnel mismatches point straight back to stage mapping.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Open every pilot resume and check re-parsing
Actually open the files rather than trusting the upload count, and check whether re-parsing has overwritten any candidate fields. A resume that uploaded as a zero-byte file still counts as a success in most logs.
-
Put recruiters in front of the pilot data
Have recruiters work their own pilot requisitions end to end. They immediately spot missing feedback, wrong stages and unreadable history that reconciliation cannot see.
Don't move on until
- Candidate-application-job relationships intact for the pilot
- Funnel counts per stage match source for pilot jobs
- Resume files open correctly for every pilot candidate
05 Cutover Switch recruiting without dropping a live candidate.
Objective All in-scope recruiting data live in Greenhouse, careers site and boards repointed, recruiters working.
Keep these open
-
Pre-load historical candidates and closed jobs
Load closed requisitions, rejected candidates and archived applications while BambooHR stays live. Only active pipeline and the final delta need to move in the window.
-
Publish the runbook including the careers-site switch
A timed sequence with owners and abort criteria, treating the careers site and job boards as first-class steps. They are candidate-facing, so a failure there is publicly visible in a way a data defect is not.
-
Freeze BambooHR and take the final delta
Stop new applications and let recruiters finish in-flight actions, then export everything changed since the pre-load. Coordinate with anyone actively interviewing so feedback is not entered into the old system mid-freeze.
Interview feedback entered in the old ATS during the freeze is lost, and it is the data recruiters most immediately notice missing.
-
Load active pipeline and reconcile stages
Load active candidates and applications, then verify every active candidate is at the correct stage on the correct job before repointing anything. Active-stage accuracy is what recruiters check first on day one.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint careers site, job boards and integrations
Switch the careers-site integration, repost or migrate live job ads, and repoint HRIS, background check, assessment and calendar integrations. Then submit a real test application through the careers site and every major board.
Job ads left posted against the old ATS keep collecting applications that never reach the new system.
-
Go/no-go and switch recruiters over
Call the decision against the exit criteria, then move recruiters with support on hand for the first day. Keep BambooHR read-only — candidate records have retention obligations that outlast the migration.
Don't move on until
- Historical load complete and reconciled before the freeze
- Careers site and job boards posting into Greenhouse and verified
- Active candidates confirmed at the correct stage
06 Validation Prove the funnel, the files and the compliance position.
Objective Reconciled recruiting data, funnel parity with baseline, and a defensible compliance record.
Keep these open
-
Reconcile every object including files
Compare counts for candidates, applications, jobs, interviews, scorecards and files, with field-level spot checks on a sample. Count files separately — they are the object most likely to be quietly short.
Migration Validation Tool Reconcile BambooHR and Greenhouse record-for-record -
Tie funnel and time-to-hire reporting to baseline
Rebuild funnel conversion, time-to-hire, source effectiveness and offer-acceptance reporting and compare to pre-migration figures. Variances trace back to stage mapping and to how application timestamps were handled.
Time-to-hire depends on stage-transition timestamps. If those were approximated, the metric will differ even with identical records.
-
Verify file integrity at scale
Sample-open resumes across the whole load and compare file sizes against source. Zero-byte and truncated files are common and never surface in an upload success count.
-
Confirm retention, consent and EEO configuration
Verify retention rules, consent state and EEO segregation are correctly configured in Greenhouse, and that excluded records genuinely did not migrate. File this as your compliance evidence.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Test workflow, notifications and candidate-facing paths
Fire every stage automation, interview scheduling flow, rejection template and offer approval, and submit a live application through the careers site. Candidate-facing emails going out wrong is a brand problem, not just a bug.
-
Sign off and schedule decommission
Get written acceptance against the Discovery criteria, retain BambooHR read-only for the period your retention policy requires, take a final archive export, and diarise cancellation.
BambooHR → Greenhouse specifics
- Department and office values must match exactly
- between systems. Job titles must pre-exist in BambooHR.
Don't move on until
- Reconciliation complete across candidates, applications and files
- Funnel and time-to-hire reporting tie to baseline
- Retention and EEO configuration verified, acceptance signed
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
ATS Object Object
| BambooHR field | Greenhouse field | Notes |
|---|---|---|
| Applicant | Candidate | 1:1 for unique individuals. Merge duplicates by email. |
| Application | Application | Linked to Candidate + Job in Greenhouse. |
| Job Opening | Job | Map job details, department, office. |
| Application Status | Job Stage | BambooHR uses fixed + custom statuses; Greenhouse uses configurable stages per job. Build a crosswalk, not a name match. |
| Star Rating | Note | No direct scorecard equivalent. Serialize as note text. |
| Application Comment | Note | POST to activity feed notes endpoint. |
| Resume (file ID) | Attachment | Download from BambooHR, base64-encode, upload. Requires application_id in v3. |
| Cover Letter (file ID) | Attachment | Same process. Set type: "cover_letter". |
| Hiring Lead | Recruiter | Map to Greenhouse user ID. |
| Source | Source | Map to Greenhouse source if a match exists; otherwise store in a custom field or note. |
ATS Greenhouse
| BambooHR field | Greenhouse field | Notes |
|---|---|---|
| applicant.firstName | candidate.first_name | String |
| applicant.lastName | candidate.last_name | String |
| applicant.email | candidate.email_addresses [].value | Array of objects, set type: "personal" |
| applicant.phone | candidate.phone_numbers [].value | Array of objects, set type: "mobile" |
| applicant.address | candidate.addresses [].value | Array of objects, set type: "home" |
| application.jobId | application.job_id | Integer — pre-map to Greenhouse Job ID |
| application.status | Job Stage | Map status → Greenhouse stage ID |
| application.rating | Note (body text) | No direct equivalent — serialize as note |
| application.appliedDate | application.created_at | ISO 8601 datetime |
| application.resumeFileId | Attachment | Download → base64-encode → upload. Requires application_id. |
| application.coverLetterFileId | Attachment | Set type: "cover_letter". Requires application_id. |
| application.comments [] | Notes | One note per comment |
| Custom field (text) | Candidate/Application custom field | Must pre-create in Greenhouse |
| Hiring Lead | Recruiter assignment | Map to Greenhouse user ID |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Resumes/Cover Letters | high | Requires individual API download, base64 encoding, and upload — major time sink at scale |
| Star Ratings/Evaluations | high | No direct Greenhouse scorecard equivalent; must serialize as candidate notes |
| Scorecard Structure | high | Greenhouse scorecards cannot be bulk-imported via API; historical evaluations stay as notes |
| Activity Timeline | medium | Cannot recreate full activity history with original timestamps; notes can be added |
| Custom Fields | medium | Type mismatches between platforms; picklist values must be pre-created and match exactly |
| Pipeline Stage History | medium | Can set current stage but cannot bulk-import full stage progression history |
| Source Tracking | medium | Must match existing Greenhouse sources or store in custom field |
| Duplicate Candidates | medium | Same person across multiple jobs may appear as separate BambooHR records |
| Application Comments | low | Direct mapping to Greenhouse activity feed notes |
| Job Opening History | low | Historical closed jobs can be created or consolidated into a container job |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Attachment Base64 Encoding
Every resume must be downloaded from BambooHR, base64-encoded (inflating by ~33%), and uploaded to Greenhouse. A 5MB resume becomes ~6.7MB in the POST body.
Flat-to-Relational Translation
BambooHR's single applicant record must be split into a Greenhouse Candidate plus Application(s), with deduplication by email for candidates who applied to multiple jobs.
Dependency-Ordered Loading
In Harvest v3, attachments require an application_id. Applications require candidate_id and job_id. Jobs must exist first. Strict sequencing is mandatory.
Missing Email Addresses
BambooHR allows applications without email. Greenhouse strongly expects an email address on each candidate, requiring placeholder generation and manual cleanup.
Rate Limit Management
BambooHR allows approximately 100 requests per minute while Greenhouse v3 uses a fixed 30-second window. Both APIs return 429 requiring exponential backoff.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can I export candidate data from BambooHR's ATS via API?
Yes, BambooHR's ATS API provides endpoints to list and retrieve application details, including resume/cover letter file IDs. There's no true bulk export endpoint — you must paginate through applications and fetch attachments individually. Rate limits are approximately 100 requests per minute per API key based on community reports. For large datasets, supplement with a BambooHR account data export package (CSV/XML plus attachments folder).
Should I use Greenhouse Harvest v1/v2 or v3 for a new migration?
Use Harvest v3 for new work. Greenhouse says v1 and v2 will be unavailable after August 31, 2026. V3 uses OAuth 2.0 and bearer tokens, while legacy versions use Basic auth and On-Behalf-Of headers. In v3, attachments also require an application_id and are created on a separate resource.
How do I migrate resumes and attachments to Greenhouse?
BambooHR stores resumes as file IDs. Download each file via a separate API call, base64-encode the binary content, and upload to Greenhouse. In Harvest v3, attachments are posted to the /v3/attachments endpoint and require an application_id — the application must exist before you can upload files. Base64 encoding inflates file sizes by ~33%, so plan migration timelines accordingly.
Does Greenhouse have a native BambooHR integration for post-migration?
Yes, but it works in one direction: exporting hired candidates from Greenhouse to BambooHR to create employee records. It does not support importing historical candidate data into Greenhouse. Each hired candidate is exported individually — bulk export is not supported. Department and office values must match exactly between systems.
Can I use Zapier to migrate historical data from BambooHR to Greenhouse?
No. Zapier and similar middleware platforms are designed for forward-looking sync of new records, not historical bulk migration. They lack attachment transfer support and can't handle the volume or complexity of a full ATS data migration. BambooHR's webhooks are also employee-oriented, not ATS-event-driven, so ATS sync usually requires polling.