Migrate from Jarvis CRM to Zoho CRM

Jarvis Contact records map to Zoho CRM Leads by default if the contact has not been qualified into a business relationship. Contacts that are associated with a Jarvis Company and represent an active account map to Zoho CRM Contacts linked to an Account record. We extract both the Contact table and the Company-Contact relationship table from FileMaker to compute the split using the relational join, preserving the original contact ID as a custom field for audit traceability.

Jarvis Company records map directly to Zoho CRM Accounts. We extract the full Company table including any custom fields the deployment has added, then map Company Name to Account Name, Company Phone to Phone, and any custom address fields to the standard Zoho address compound field. Dedupe is performed on Account Name and Website domain during import.

Jarvis Opportunities map to Zoho CRM Deals. The deal stage from Jarvis maps to a Zoho CRM Stage (Prospecting, Qualification, Proposal/Price Quote, Negotiation, Closed Won, Closed Lost). We extract stage names from the live FileMaker schema during the schema audit because stage names vary per deployment. Closed-won and closed-lost timestamps from Jarvis migrate to the Zoho Closed Date field. Deal Owner maps to Zoho CRM User via email-based owner resolution.

Jarvis Projects have two migration paths depending on their use case. Projects that represent billable work or deliverables with a revenue figure map to Zoho CRM Deals with a linked Project description. Projects that represent task collections without a revenue figure map to Zoho CRM Tasks with the Project name stored in the WhatId or a custom Project field. We identify which path applies during the schema audit by checking for a linked revenue field in the FileMaker Project table.

Jarvis time entries (timecards and job-time) have no direct Zoho CRM standard equivalent. We map billable and non-billable hours to a set of custom fields on the related Deal or Task: Hours_Billable__c, Hours_Non_Billable__c, Time_Entry_Date__c, and Time_Entry_ID__c for audit. If the customer also licenses Zoho FSM or Zoho Books, we coordinate the time entry import to align with the relevant project or invoice module.

Jarvis Campaign and Contact Group records map to Zoho CRM Campaigns. Campaign metadata (name, type, start date, status) migrates directly. Contact group memberships migrate as Campaign Member records linked via the Contact email to the migrated Lead or Contact. Because Jarvis does not have a native marketing automation engine, campaign engagement data (opens, clicks) is typically absent in Jarvis; we flag this absence during scoping and document it for the customer to establish baseline tracking post-migration in Zoho Campaigns.

Jarvis ERP module vendor records and purchase orders are ERP-class data that Zoho CRM handles differently depending on the customer's Zoho license. We map vendor records to Zoho CRM Contacts with a Vendor_Type__c custom picklist field set to 'Vendor'. Purchase orders map to a custom Purchase_Order__c module with Line Items if the customer has Zoho CRM Enterprise or Ultimate. If the customer uses Zoho Books separately, we flag the Vendor and PO import for alignment with the Zoho Books chart of accounts.

Jarvis product and service catalog records map to Zoho CRM Products. We extract item name, SKU, unit price, and description from the FileMaker Products table. Product-to-Opportunity associations are preserved by exporting the linking table and reconstructing them as Deal Product records during the Deal import phase. Standard pricing for each Product2 record is created via the Price Books import.

Jarvis is built on FileMaker Pro and is fully customizable, meaning every deployment has custom fields that do not exist in a standard schema. We identify all custom properties during the mandatory schema audit, classify each by data type (text, number, date, picklist, checkbox), and pre-create matching custom fields in the relevant Zoho CRM module before any data import begins. Fields with no Zoho equivalent are flagged in the scope document with a recommendation for a Zoho custom field or a JSON blob in a notes field.

File attachments stored within the FileMaker instance can be exported, but the storage format and path vary by deployment. We identify attachment storage locations during scoping, extract files to a flat directory, and link them to the corresponding Zoho CRM record (Contact, Account, Deal) via the Zoho CRM Attachments API using the record ID and module name as the lookup key. Files without a resolvable parent record are held in a staging folder for manual review.

Jarvis User records and ACL data map to Zoho CRM Users. We extract the FileMaker user table and match by email address to Zoho CRM User records. Any Jarvis Owner without a corresponding Zoho CRM User is placed in a reconciliation queue for the customer's admin to provision before record import resumes. Owner assignments on Contacts, Accounts, and Deals are resolved via the email-to-UserId lookup during import.

FileMaker stores relationships as internal table links (Contact IDs, Company IDs, Project IDs) that are not visible in a CSV export. We export primary keys and foreign keys from all relevant tables, then reconstruct the relational structure in Zoho CRM using explicit lookup field resolution during import. For example, a Contact-to-Company link in FileMaker becomes an AccountId lookup on the Contact record in Zoho CRM. We do not use name-matching to infer relationships; all links are resolved via the exported ID keys.