Migrate from Jarvi to Recruit CRM & ATS

Jarvi Candidate records map to Recruit CRM Candidates. Standard fields (name, email, phone, current_title, current_company, location) map directly to the corresponding Recruit CRM candidate fields. Jarvi's status and stage properties map to Recruit CRM's candidate status pipeline. The candidate_skills array from Jarvi's JSON output maps to Recruit CRM's skills custom field (multi-select or text list). Jarvi's candidate rating (1-5 stars) maps to Recruit CRM's rating field. Source attribution (LinkedIn, job board, direct) is preserved in a custom field for reporting.

Jarvi CRM Contacts map to Recruit CRM Contacts. The Contact stores company association, lifecycle stage, and multichannel communication history. We preserve the original Jarvi lifecycle stage in a custom field jv_original_lifecycle__c on the Recruit CRM Contact for audit. Contact owner assignment resolves by email match against Recruit CRM users. Any Jarvi Contact without a matching owner is flagged for the customer's admin to provision before record import begins.

Jarvi Job postings and requisitions map directly to Recruit CRM Jobs. Job title, description, location, salary range, employment type, and posting status migrate. The job's associated pipeline stages and stage ordering extract from Jarvi and are mapped to Recruit CRM's pipeline configuration. Posting channel assignments (which job boards the job was published to) are preserved as a custom text field since Recruit CRM manages job board distribution separately within the Jobs module.

Jarvi's custom pipeline stage definitions per job or per CRM deal extract as a stage schema alongside each record. We map each Jarvi stage name and position to a corresponding Recruit CRM stage, preserving the win and loss state flags. If Recruit CRM lacks an equivalent stage (for example, a Jarvi-specific screening stage), we create the stage in Recruit CRM's pipeline configuration before migration begins.

Jarvi's job-to-candidate associations are first-class links stored alongside each Candidate record's job assignments. We extract the job_id and candidate_id pair, resolve the job reference in Recruit CRM (which requires the Job record to already exist), and create the association by updating the candidate record's associated_jobs field in Recruit CRM. This step requires Jobs to migrate before Candidates or requires us to create placeholder Job stubs first and reconcile after the full Job migration completes.

Jarvi Activity records (emails sent, LinkedIn messages, calls, meetings, tasks) map to Recruit CRM Activities. The activity type, timestamp, subject, body, and channel attribution migrate. We preserve the parent reference (candidate_id or contact_id) so the activity appears on the correct record in Recruit CRM. Call duration and disposition from Jarvi map to Recruit CRM's call_log custom fields. Meeting details (attendees, location, start/end time) map to Recruit CRM's meeting activity type.

Jarvi Company records map to Recruit CRM Organizations. Company name, industry, size tier, revenue tier, website, and address fields migrate directly. Company owner assignment resolves by email against Recruit CRM users. Multiple Contacts associated with the same Company in Jarvi link to the same Organization record in Recruit CRM with individual Contact records beneath it.

Jarvi exposes a UUID-based Custom Fields API for Candidates and Contacts with types including text, number, date, and dropdown. We retrieve the field schema before migration and create matching custom fields in Recruit CRM (using Recruit CRM's per-object field builder). Dropdown fields in Jarvi map to picklist fields in Recruit CRM with the same option values preserved. Text and number fields map directly. Any custom field type without a Recruit CRM equivalent (for example, a Jarvi-specific rating matrix) is stored as a custom text field with the original values preserved as JSON.

Resumes, cover letters, and uploaded documents attach to Jarvi Candidate profiles as file metadata and reference URLs. We export attachments alongside candidate records, mapping them to the Recruit CRM candidate's resume and document upload fields. File hosting URLs from Jarvi are preserved as reference links if Recruit CRM does not support direct file hosting. We flag any attachment that exceeds Recruit CRM's file size limit and offer a storage strategy during scoping.

Jarvi threads messages across LinkedIn InMail, email, WhatsApp, Telegram, and SMS into a unified conversation view. Recruit CRM does not have an equivalent unified conversation object; instead, each message type appears as a separate activity record (email_activity, call_log, sms_activity). We split the conversation thread by channel attribution stored in Jarvi's message records and import each message as an individual activity linked to the parent Candidate or Contact. Channel attribution (LinkedIn, WhatsApp, etc.) is preserved in a custom field on each activity record so the customer's team can filter by source channel.

Jarvi's AI agent produces candidate summaries, profile evaluations, and outreach suggestions as linked data points on the candidate record rather than standalone objects. When migrating to Recruit CRM, these summaries land as a custom text field (ai_summary__c) on the candidate record. If the customer's Recruit CRM plan does not include custom fields on the Candidate object, we flag the orphaned AI data and offer a post-migration re-generation step using Recruit CRM's own AI tools. The original Jarvi summary text is preserved in the custom field so no AI-generated content is lost during migration.

Jarvi Owners (recruiters and admins) map to Recruit CRM Users. We resolve owners by email match against the Recruit CRM destination user table. Any Jarvi Owner without a matching Recruit CRM User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Active and inactive status is preserved so that inactive Jarvi users do not automatically activate in Recruit CRM.