Migrate from Jarvi to BambooHR

Jarvi Contacts (recruiter client relationships, internal staff contacts) map to BambooHR Employee records. The mapping requires a pre-migration segmentation step: Contacts who are current or former staff members migrate as BambooHR Employees with full employee fields populated; external client contacts that are not employed by the customer's organization cannot map to BambooHR Employees (BambooHR enforces per-employee licensing). For external contacts, we export them as a CSV reference document attached to the migration handoff. Email, phone, company association, and custom Contact fields migrate to the corresponding BambooHR employee fields fetched via GET /v1/meta/fields.

Jarvi Company records (firmographic data on client organizations) do not have a direct BambooHR equivalent because BambooHR is employee-centric rather than account-centric. We map Company name and industry to custom text fields on the Employee record or to a BambooHR custom lookup table (implemented as a custom Employee field) if the customer uses BambooHR's custom field API. Location data maps to BambooHR workLocation. This is a structural limitation of the ATS-to-HRIS migration and is flagged during scoping.

Jarvi Candidates cannot migrate directly into BambooHR's core Employee object because candidates are not current employees. BambooHR offers a separate Hiring module for applicant tracking, but it is a bolt-on module with a different object model (Applicants, Job Openings, Pipeline Stages) rather than a native ATS equivalent. We export all Candidate records as a structured CSV with all standard and custom fields for the customer's BambooHR admin to manually import into the BambooHR Hiring module. AI-generated candidate summaries from Jarvi export as a custom text column in that CSV.

Jarvi Jobs (requisitions and postings) map conceptually to BambooHR Job Openings in the Hiring module, but the object schemas are not compatible for direct API-to-API migration. We export Jobs as a structured data document including job title, description, posting channels, associated pipeline stages, and candidate count per stage. The customer's BambooHR admin recreates these as Job Openings in the Hiring module. Job-to-candidate associations are preserved in the candidate export CSV so they can be re-established manually in BambooHR Hiring.

Jarvi custom pipeline stage definitions per Job do not have a direct BambooHR equivalent in the core HRIS. Stages map to BambooHR Hiring pipeline stages (Offer, Interview, Application Review) only if the customer licenses the BambooHR Hiring module. We extract the complete stage schema (names, ordering, win/loss states) as a configuration inventory for the admin to rebuild in the Hiring module. Stage-specific candidate counts are included in the Job export.

Jarvi Activity records (emails, LinkedIn messages, WhatsApp, calls, meetings linked to Contacts or Candidates) have no equivalent in BambooHR's employee-centric data model. BambooHR does not store outreach activity history as a first-class object. We export the full activity timeline as a timestamped CSV per Contact for the customer's records, but these do not migrate into BambooHR as native objects. This is a known limitation of the ATS-to-HRIS migration pattern.

Jarvi exposes custom fields via a UUID-based Custom Fields API. BambooHR requires a pre-migration schema fetch via GET /v1/meta/fields to retrieve the numeric field IDs assigned per account. Custom field values map to BambooHR custom employee fields by matching field type (text to text, number to number, date to date, dropdown to dropdown). We do not hardcode BambooHR field IDs because they vary per account. Any Jarvi custom field type without a BambooHR equivalent is flagged and exported as a CSV column in the handoff document.

Jarvi resume and cover letter attachments linked to Candidate profiles export as file references and binary blobs. These do not migrate as native BambooHR employee file attachments because BambooHR's file storage model is scoped to employee records (new hires, onboarding documents) rather than applicant resumes. We export attachments as a structured folder set (per candidate) and deliver them alongside the candidate CSV so the customer's admin can manually attach them in BambooHR Hiring if applicable.

Jarvi's unified multichannel inbox (LinkedIn InMail, email, WhatsApp, Telegram threads per Contact or Candidate) has no equivalent in BambooHR. This is a CRM-layer feature that does not exist in an HRIS data model. We export conversation thread metadata (participant, channel, timestamp, snippet) as a CSV reference for audit purposes, but the full threaded conversation history does not migrate into BambooHR.

Jarvi AI-generated candidate summaries and evaluations are stored as linked data points rather than standalone objects. When exporting candidates, these summaries land as a custom text column in the candidate CSV. If BambooHR has a custom long-text field available on the Applicant object in the Hiring module, we map the summary there; otherwise it is preserved in the exported CSV. This mirrors how we handle AI summaries in all Jarvi outbound migrations.