Migrate from Jarvi to Bullhorn ATS & CRM

Jarvi Candidate records map directly to Bullhorn Candidate. Standard fields (firstName, lastName, email, phone, status, source) map cleanly. The Jarvi AI agent's candidate summary lands as a custom text field (candidateSummary) on the Bullhorn Candidate record since Bullhorn does not store AI-generated summaries as native objects. We flag any candidates with a stale LinkedIn refresh date (older than 90 days) for optional re-enrichment before or after migration.

Jarvi Contact records (clients and prospects) map to Bullhorn ClientContact. Company association in Jarvi maps to the ClientCorporation lookup in Bullhorn. Communication history (LinkedIn, email, WhatsApp, Telegram) from Jarvi's unified inbox migrates as separate Note records in Bullhorn with a channel attribute field set to the source channel (LinkedIn, Email, WhatsApp, Telegram) so the origin is preserved even without Bullhorn's native threaded inbox.

Jarvi Company records map to Bullhorn ClientCorporation (Bullhorn's Account equivalent for staffing). Firmographic data (industry, size, revenue tier) maps to corresponding Bullhorn fields. ClientCorporation is created before any ClientContact import so the lookup relationship is satisfied at the moment of contact insert.

Jarvi Job postings map to Bullhorn JobOrder records. Each Job links to pipeline stages and associated Candidates. We extract the stage schema from Jarvi alongside each record and map Jarvi stage names to Bullhorn status values or a custom status picklist configured on the JobOrder Record Type. Job-to-candidate associations migrate as JobSubmission records in Bullhorn.

Jarvi allows custom pipeline stage definitions per job or per CRM deal. Stage names, ordering, and win/loss states vary by organization. We extract the full stage schema and create corresponding Bullhorn Record Types on JobOrder with custom status picklists that whitelist the migrated stage values. Probability percentages map to StageProbability if the customer wants weighted pipeline forecasting in Bullhorn.

Jarvi stores all outreach actions (emails sent, LinkedIn messages, calls, meetings) as Activity records linked to a Contact or Candidate. We split these by type: calls become Task with TaskSubtype=Call; meetings become Event; LinkedIn InMail and WhatsApp messages become Note records with a custom channel field; standard emails become Task (SendEmail subtype) or Note depending on Bullhorn edition. Timestamps are preserved for activity timeline ordering.

Jarvi threads messages across LinkedIn InMail, email, WhatsApp, Telegram, and SMS into a unified conversation view per Contact or Candidate. Bullhorn does not have a native threaded conversation object, so we export each thread as a series of Note records with a conversationId reference and a channel field. Thread ordering within a conversation is preserved by the note creation timestamp. This is the most content-intensive part of the migration and can require chunking for accounts with long conversation histories.

Jarvi exposes a UUID-based Custom Fields API for both Candidates and Contacts supporting text, number, date, and dropdown types. We retrieve the full custom field schema before migration, map each field to a Bullhorn custom field by type (text maps to Short Text or Long Text, number to Numeric, date to Date), and configure the Bullhorn field via Admin > Field Mappings before record import. Bullhorn ATS edition limits custom fields per entity; we validate against the target edition during scoping.

Jarvi Contact custom fields map to Bullhorn ClientContact custom fields following the same type-mapping logic as candidate custom fields. If the customer's Jarvi Contacts include fields that reference Candidate-specific data (e.g., a rating applied by a recruiter), we separate those into a custom object or flag them for manual review post-migration because Bullhorn ClientContact and Candidate are distinct entities.

Resumes, cover letters, and uploaded documents attach to Jarvi Candidate profiles as file references. We export the file metadata and reference URL alongside candidate records. Bullhorn stores resumes as a dedicated Candidate Resume object and other attachments as ContentDocument with ContentDocumentLink to the parent Candidate. We map the primary resume to Bullhorn's native resume parsing field and secondary attachments to ContentDocument.

Jarvi's AI agent generates candidate summaries and evaluations stored as linked data points on the candidate record. When migrating out of Jarvi, these summaries land as custom text fields on the Bullhorn Candidate record. If Bullhorn's AI tools (Amplify or a third-party partner) are licensed post-migration, the customer can regenerate summaries in Bullhorn. We flag this as an optional post-migration step rather than treating the summaries as native data that carries over cleanly.

Jarvi Owner records map to Bullhorn User records. We resolve owners by email match against the Bullhorn destination org's User table. Any Jarvi Owner without a matching Bullhorn User goes to a reconciliation queue. The customer's Bullhorn admin provisions missing Users (active or inactive depending on whether the original Jarvi user is still active). Migration cannot proceed past record import because OwnerId references are required on most standard Bullhorn objects.