Migrate from BambooHR to Recruit CRM & ATS

BambooHR Applicant records map directly to Recruit CRM Candidate records. We map the applicant name, email, phone, LinkedIn URL, source, and status as custom fields where Recruit CRM's standard Candidate fields do not cover them. BambooHR's custom application fields (which vary per account) migrate to Recruit CRM custom fields on the Candidate object. We preserve the original BambooHR applicant ID in a custom field bamboohr_applicant_id__c for audit and reconciliation.

BambooHR Applications link an Applicant to a Job Posting with a status (new, phone screen, interview, offer, hired, rejected). We map Application status to Recruit CRM's pipeline stages, with a configurable stage translation table defined during scoping because BambooHR's pipeline stage names are account-specific. The job assignment date, interviewer notes, and rejection reason migrate as custom fields on the Candidate-Job association.

BambooHR Job Postings map to Recruit CRM Job records. We map job title, department, location, employment type, and job description. BambooHR's job status (open, closed, on hold) maps to Recruit CRM's job status. Active BambooHR job postings become open Recruit CRM jobs; we handle the status transition during migration so the recruiting team has an accurate open-position count at cutover.

BambooHR stores division, department, job title, employment type, and location as first-class attributes on both Employee and Applicant records. Recruit CRM does not have a native Job Information object; these map to custom fields on the Candidate record (candidate_department__c, candidate_job_title__c, candidate_location__c). We define and create these custom fields in Recruit CRM during schema setup before any data import.

BambooHR's pay rate, pay type (salary/hourly/exempt), currency, and pay frequency are native fields. Recruit CRM's Candidate object does not have native compensation fields. We map these to custom fields (expected_salary__c, pay_type__c, currency__c) as string or picklist values. Actual compensation data is often considered sensitive; we flag this during scoping and apply field-level encryption where the customer requires it.

BambooHR's heavy field-level customization means every account has a unique set of custom fields. We inventory all custom fields on Applicant and Employee records during scoping, validate their types against BambooHR's field type reference (bool, checkbox, currency, date, country, EIN), and create matching custom fields in Recruit CRM before migration. Type coercion (e.g., BambooHR multi-select text to Recruit CRM multi-select picklist) is handled in the transform layer.

BambooHR time-off requests, balances, and policies have no native equivalent in Recruit CRM, which has no HRIS or time-off management module. We do not migrate time-off data into Recruit CRM as it would create orphan records with no purpose-built display. If the customer is decommissioning BambooHR entirely, time-off balances and accrual history are flagged as a manual reconciliation step or a requirement for a separate HRIS implementation.

Benefits enrollment data in BambooHR is highly customer-specific and stored per employee. Recruit CRM does not have a benefits administration module. We do not migrate benefits data into Recruit CRM. For companies that are decommissioning BambooHR rather than running both systems in parallel, benefits data (carriers, coverage tiers, enrollment dates) is flagged as a separate HRIS selection and migration task outside the Recruit CRM scope.

If the migration scope includes employees who were hired through BambooHR's ATS as new candidates, we treat Employee records as Candidate records in Recruit CRM. The employee name, contact information, job title, department, and supervisor link map to Candidate custom fields. Employment status (active, terminated, on leave) maps to a candidate_employment_status__c custom field. Historical terminated employees are migrated as inactive Candidates with a hire date and termination date preserved in custom fields.

BambooHR document attachments (offer letters, signed contracts, onboarding forms) stored under employee or applicant records are accessible via the BambooHR API but not via the standard report export. We retrieve binary documents separately per record and attach them to the corresponding Recruit CRM Candidate record. Document retrieval is scoped as an optional add-on because API-based binary retrieval adds significant time to the migration pipeline.

BambooHR's onboarding tasks, checklists, and document requests are tied to new hires and do not map to any Recruit CRM object. Recruit CRM has no native onboarding workflow module. We do not migrate onboarding task state into Recruit CRM. We document the active onboarding checklist items per new hire in a written handoff file so the customer's admin can recreate the onboarding task list in Recruit CRM's workflow automation or as a manual checklist.