Migrate from BambooHR to Crelate

BambooHR Employee records map to Crelate Person records. Core fields (first name, last name, email, phone, address) migrate directly. The BambooHR employee ID is preserved in a custom field (e.g., bamboohr_id__c) for reconciliation. Employment status (active, inactive, terminated) from BambooHR maps to a custom status field in Crelate; terminated employees can be archived rather than deleted so the recruiting history is retained. Hire date and termination date migrate as Person custom fields since Crelate does not have a native employment-status field.

BambooHR Applicant records map to Crelate Person records at the individual level, with one Crelate Application record created per BambooHR application-to-job-link. BambooHR's applicant status (applied, rejected, hired, etc.) maps to Crelate's pipeline stage values after a stage-name mapping exercise during scoping. Source attribution (where the candidate came from: Indeed, referral, LinkedIn, etc.) migrates to the Crelate Application's source field.

BambooHR job postings from the ATS module map to Crelate Job Orders. The job title, job description, location, and employment type (full-time, part-time, contract) migrate directly. BambooHR job status (open, closed, on hold) maps to Crelate Job Order status. Each BambooHR job opening becomes a Crelate Job Order that can have multiple Applications attached to it.

BambooHR's pipeline stage names (e.g., Applied, Phone Screen, Interview, Offer, Hired) are account-specific and must be mapped manually to Crelate's customizable pipeline stages. During scoping, we inventory all BambooHR stage values used across all job openings and create a Crelate pipeline template that covers all of them. Closed pipeline stages in BambooHR become archived or inactive stages in Crelate to preserve historical data without cluttering the active recruiting workflow.

BambooHR allows custom fields on applications (e.g., interview score, background check status, referral source detail). We inventory these during scoping, validate their field types against BambooHR's API field type reference, and create equivalent custom fields in Crelate under the Application record. Multi-select, date, and text field types translate directly; checkbox and currency fields require type mapping to Crelate's supported custom field types (Text, Integer, Decimal, Money, Date, etc.).

BambooHR applicant notes (the notes attached directly to an applicant record) migrate to Crelate Activity records linked to the Person or Application. The note body, author, and timestamp are preserved. If the note contains formatted content, we strip to plain text or migrate as-is depending on Crelate's activity field capacity. We flag any notes that exceed Crelate's field length limits during scoping so they can be handled as multi-record notes.

BambooHR email engagements linked to applicants migrate to Crelate Email Activity records attached to the Person. The email subject, body, sender, recipient, and timestamp migrate. Email threading (which emails are replies to which) is preserved by matching In-Reply-To or References headers where available in the BambooHR export. If BambooHR email history is stored as a plain-text thread dump rather than individual records, we split by timestamp and author to reconstruct individual email entries.

BambooHR scheduled activities on applicants (interviews, calls, assessments) migrate to Crelate Activity records with the activity type set to the corresponding Crelate activity type (Interview, Call, etc.). Scheduled date and time migrate to the Activity scheduled date. Interviewer names are resolved to Crelate User records by email match where possible; unresolved interviewers are stored as text in a custom field.

BambooHR stores job title, division, department, employment type, and location as first-class attributes on the Employee record. For recruiting data migration (applicants rather than employees), we map these as custom fields on the Crelate Job Order. Department and division map to Crelate Job Order tags or custom fields depending on whether the customer wants these as filterable tags or structured fields.

BambooHR stores supervisor relationships as a link from Employee to another Employee. When migrating recruiting data (not full HR records), the supervisor relationship is less critical. If the customer wants it preserved, we map the supervisor Employee to a custom Person field (supervisor__c) referencing another Person record, or store the supervisor name as a text field. We resolve by email match against the Person records already migrated.

BambooHR onboarding tasks and checklists are tied to new hires but are not exposed as standalone objects in the standard API export. We reconstruct the onboarding state as a written inventory: which new hires had which checklist items completed or pending, based on the employee export and BambooHR's onboarding report. This inventory is delivered as a document for the customer's admin to rebuild in Crelate or a separate onboarding tool. We do not migrate onboarding workflows as code.

BambooHR time-off requests, balances, and policies have no equivalent in Crelate's recruiting data model. Crelate does not store HR-benefit data or accrual balances. If the customer needs time-off data preserved for audit purposes, we export it as a CSV and deliver it as a separate data artifact. We do not attempt to load it into Crelate. This gap is documented in the migration scope before work begins.

BambooHR compensation fields (pay rate, pay type, currency, pay frequency) can migrate to Crelate Person custom fields if the customer wants to carry salary expectations or current compensation into the recruiting record. However, Crelate is not an HRIS and does not use compensation fields in its standard workflows; we treat these as optional migration items scoped explicitly during discovery. If included, we create Crelate custom fields of type Money or Decimal and flag that they are informational only.

BambooHR benefits enrollment data is highly customer-specific and stored as a structured export per employee. Crelate does not have a benefits administration module. Benefits enrollment data (carriers, coverage tiers, dependents, election dates) does not migrate. We export it as a structured CSV and deliver it as a separate artifact for the customer's HR team to retain for compliance or audit purposes.

Binary document attachments from BambooHR (offer letters, signed I-9s, employment contracts) are accessible via the BambooHR API and can be attached to the corresponding Crelate Person record. We migrate these as file uploads to the Person record or Application record, maintaining the document filename and MIME type. PDF-based documents are preserved as binary; text-based documents are preserved as-is. Document migration is scoped as a separate line item because it requires per-record API retrieval and file handling beyond standard CSV-based migration.