Migrate from Jarvis CRM to Microsoft Dynamics 365 Sales

Jarvis Contact records map to either Salesforce Lead or Contact depending on qualification status. We resolve the split using Jarvis relationship fields: contacts linked directly to Opportunities map to Contact attached to an Account (qualified); contacts with no Opportunity link map to Lead. The original Jarvis contact ID and any custom contact fields migrate as reference fields for audit. If the customer's deployment uses a custom qualification flag, we honor that field during the split rule design.

Jarvis Company records map directly to Dynamics 365 Account. The primary key from FileMaker (typically a numeric or UUID CompanyID) migrates as a custom field source_company_id__c for reconciliation. Account Address fields (AddressLine1, City, State, PostalCode, Country) map from the corresponding FileMaker address fields. If the deployment stores multiple addresses per Company, we map the primary address to Account and flag additional addresses for multi-address configuration post-migration.

Jarvis Opportunity records map to Dynamics 365 Opportunity with AccountId resolved from the Company lookup. Pipeline stage names from FileMaker become Dynamics stage values, which we configure as a Sales Process before migration. Deal value migrates to Amount, close date to EstimatedCloseDate, and owner assignment to OwnerId via email-matched User lookup. Closed-won and closed-lost reasons from custom Jarvis fields map to custom Opportunity fields.

Jarvis Project records have no direct Dynamics 365 Sales equivalent; the sales module does not include project management natively. We migrate Projects as a custom object (custom_project__c) with fields for Project Name, StartDate, EndDate, Status, and Assignee. If the customer licenses Project Service Automation, we map to msdyn_workorder instead. Gantt layout data and task dependencies are preserved as structured metadata in custom fields; raw task hierarchy migrates as a related custom object (custom_project_task__c). The customer configures the project app or custom object post-migration.

Jarvis task flows and activity records map to Dynamics 365 Task (for follow-up tasks) and Event (for scheduled meetings). ActivityType from Jarvis (Call, Email, Meeting, Note) maps to Task.TaskType or Event. ActivityDate and timestamps preserve. Linked contacts or deals from Jarvis attach via WhoId and WhatId on the Dynamics record. The exact activity schema depends on how the FileMaker deployment structured these records, which we identify during the schema audit.

Jarvis time tracking (billable and non-billable hours linked to Projects, Contacts, or Vendors) has no native Dynamics 365 Sales equivalent. We map Time Entries to a custom object (time_entry__c) with fields for Hours, Date, Billable flag, and lookups to the custom project and contact records. If the customer licenses Field Service or Project Service Automation, Time Entries map to msdyn_timeentry instead. Audit trail IDs from Jarvis preserve in a custom source_time_entry_id__c field.

Jarvis Campaign and Contact Group records map to Dynamics 365 Campaign. Group membership (contacts assigned to a group) maps to CampaignMember records linked to the Campaign and the corresponding Contact or Lead. Campaign status, type, and budget fields migrate from the corresponding FileMaker fields. Because Jarvis does not include native marketing automation, campaign data is typically basic metadata; we migrate what exists and flag any advanced campaign tracking fields for manual review.

Jarvis Product and Service catalog records map to Dynamics 365 Product2. Item Name, Description, Price, and SKU migrate directly. ProductCode maps from the Jarvis item ID or SKU field. Standard Pricebook entries are created during migration so that Line Items can reference them. If the customer's deployment uses custom product fields, we map them to custom Product2 fields.

Jarvis Vendor and Purchase Order records are part of the ERP module and have no native Dynamics 365 Sales equivalent. We map Vendors to a custom object (vendor__c) and Purchase Orders to a custom object (purchase_order__c) with lookup to Vendor. If the customer licenses Dynamics 365 Finance or Business Central, we map to msdyn_vendor and the corresponding PO entity instead. Vendor payment terms and addresses migrate as custom fields.

Jarvis is built on FileMaker Pro and every deployment has custom fields unique to that instance. We identify all custom properties during the schema audit, map them to equivalent Dynamics 365 custom fields on the target object, and flag any with no clear mapping as requiring manual entry or a custom object. Custom field type mapping follows Dataverse conventions: text fields become nvarchar, numbers become decimal or integer, dates become datetime, and multi-select values become choice fields.

File attachments stored within the FileMaker instance are identified during scoping and mapped to Dynamics 365 Annotation records (notes with file attachments) or to SharePoint/OneDrive document locations if the customer enables document management. Attachment format and storage path vary per deployment; we identify the storage location during schema audit and include it in the migration plan. We do not migrate FileMaker container fields with embedded binary data without explicit customer approval due to size constraints.

Jarvis user records and owner assignments on Contacts, Companies, Opportunities, and Projects are extracted from FileMaker ACL and record-level ownership fields. We map Jarvis users to Dynamics 365 Users by email match. Owners without a matching User record go to a reconciliation queue for the customer's admin to provision before record import resumes. OwnerId references on Opportunities and custom objects cannot be inserted until all Users exist in the destination org.