CRM migration
Field-level mapping, validation, and rollback between Case.one and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.
Case.one
Source
Salesforce Sales Cloud
Destination
Compatibility
12 of 12
objects map 1:1 between Case.one and Salesforce Sales Cloud.
Complexity
BStandard
Timeline
48–72 hours
Overview
Case.one structures its data around Matters (cases), Clients, Bills, Time Entries, and Documents — a legal practice-management model that predates CRM conventions. Salesforce Sales Cloud uses Accounts, Contacts, Opportunities, Cases (service-focused), Tasks, Events, and Notes with a different relationship model: Contacts belong to Accounts, Activities are polymorphic Task/Event objects, and time tracking requires custom fields or app-level solutions rather than a native object. We map Case.one Clients to Salesforce Contacts with AccountId links (using a default Account or a pre-created Legal Clients Account), Matters to Salesforce Cases for matter tracking or Opportunities for deal-cycle visibility, Bills to a custom Invoice__c object, and Time Entries to Tasks with a custom Duration__c field capturing billable hours. Documents migrate as Salesforce Files with parent-id links to the target object. What does not migrate: Case.one billing automation, matter workflows, custom legal templates, and third-party integrations — those require Salesforce-side rebuilds using Flow, Apex, or AppExchange apps post-migration. Our migration runs via Case.one REST API export followed by Salesforce Bulk API 2.0 ingestion, with a staged sequence so foreign-key dependencies resolve in the right order (Accounts → Contacts → Cases → Activities → Files). A 24–48 hour delta-pickup window captures any changes made during the final cutover before you go live in Salesforce.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Case.one object lands in Salesforce Sales Cloud, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Case.one
Client
Salesforce Sales Cloud
Contact + Account
1:1Case.one Clients map to Salesforce Contacts with an AccountId lookup. If the client is an individual without a company, we create a default Account record (e.g., 'Individual Clients') and link all solo contacts there. Multi-matter clients get a single Contact record with all related matters linked via the Case object's AccountId.
Case.one
Matter
Salesforce Sales Cloud
Case
1:1Case.one Matters translate directly to Salesforce Cases. The Matter Number becomes Case.CaseNumber for traceability. Case.Type and Case.Reason map to matter-type and practice-area pick-lists from Case.one's schema. If your firm tracks matters as sales-cycle opportunities, we offer an Opportunity mapping instead — your admin chooses before migration.
Case.one
Matter (alternative)
Salesforce Sales Cloud
Opportunity
1:1Firms that track matter revenue as a pipeline use Opportunity instead of Case. Matter name becomes Opportunity.Name; billable amount maps to Opportunity.Amount; matter stage maps to Opportunity.StageName. This requires your admin to confirm the use-case and pre-create the Opportunity record type for legal matters.
Case.one
Bill
Salesforce Sales Cloud
Invoice__c (custom object)
1:1Case.one Bills have no Salesforce native equivalent. We create a custom Invoice__c object with fields for Invoice_Number__c, Invoice_Date__c, Total_Amount__c, Status__c, and a lookup to the Case (matter). Line items are stored in a custom Invoice_Line_Item__c junction object with Description__c, Hours__c, Rate__c, and Amount__c.
Case.one
Time Entry
Salesforce Sales Cloud
Task
1:1Case.one Time Entries map to Salesforce Tasks with Type='Time Entry'. Custom fields Duration__c (decimal hours), Billable__c (checkbox), and Rate__c (currency) preserve billing detail. Task.Subject is constructed from the matter name + 'Time Entry' + date. OwnerId resolves via email match to the Salesforce user who logged the time.
Case.one
Document
Salesforce Sales Cloud
ContentDocument / ContentVersion
1:1Case.one documents attached to matters migrate as Salesforce Files (ContentVersion + ContentDocumentLink). Each file is downloaded from Case.one and re-uploaded to Salesforce with the target Case or Contact as the parent. File size limits (25MB per file) apply; files over 25MB are flagged for manual handling or chunked upload.
Case.one
Calendar Event
Salesforce Sales Cloud
Event
1:1Case.one calendar events (depositions, hearings, client meetings) migrate as Salesforce Events with original start/end times, location, and attendees preserved. Event WhoId links to the Contact; Event WhatId links to the related Case (matter). Recurring events are expanded to individual Event records.
Case.one
Custom Matter Field
Salesforce Sales Cloud
Custom Field (__c) on Case
1:1Case.one custom fields on Matters (e.g., Practice_Area__c, Court_Date__c, Insurance_Claim_Number__c) are created as custom fields on the Salesforce Case object. Field type is preserved: pick-lists become global value sets, date fields become Date fields, currency fields become Currency fields. Your admin reviews and approves the custom field plan before creation.
Case.one
Staff / User
Salesforce Sales Cloud
User
1:1Case.one staff records resolve to Salesforce Users by email address match. Unmatched staff are flagged before migration — your team either creates Salesforce User accounts first or assigns their matters to a fallback owner. Inactive Case.one staff map to inactive Salesforce users; active matters are reassigned per your rule.
Case.one
Billing Automation / Matter Workflow
Salesforce Sales Cloud
No equivalent
1:1Case.one billing rules, auto-invoicing workflows, and matter-phase automation do not export. These are destination-side constructs that must be rebuilt in Salesforce using Flow (for workflow automation), Apex triggers (for complex billing logic), or an AppExchange billing app post-migration. We provide an export of your Case.one workflow definitions as a rebuild reference.
Case.one
Client Contact Association
Salesforce Sales Cloud
AccountContactRelation
1:1Case.one allows multiple staff contacts per matter and multiple matters per client contact. In Salesforce, the AccountContactRelation object handles multi-relationship links between a Contact and an Account. We create one AccountContactRelation per unique client-contact-to-account link, with Roles populated from Case.one's contact-role field.
Case.one
Matter Note
Salesforce Sales Cloud
Note
1:1Case.one notes on matters migrate as Salesforce Notes (not the legacy Note object). The Note.Body field preserves rich-text formatting including bold, bullet points, and embedded links from the original matter note. Note.ParentId links each note to its target Case record. To maintain accurate historical reporting, the original creation timestamp from Case.one is stored in a custom Original_Create_Date__c field, since Salesforce's native CreatedDate will reflect the migration execution time rather than the source record's actual creation date.
| Case.one | Salesforce Sales Cloud | Compatibility | |
|---|---|---|---|
| Client | Contact + Account1:1 | Fully supported | |
| Matter | Case1:1 | Fully supported | |
| Matter (alternative) | Opportunity1:1 | Fully supported | |
| Bill | Invoice__c (custom object)1:1 | Fully supported | |
| Time Entry | Task1:1 | Fully supported | |
| Document | ContentDocument / ContentVersion1:1 | Fully supported | |
| Calendar Event | Event1:1 | Fully supported | |
| Custom Matter Field | Custom Field (__c) on Case1:1 | Fully supported | |
| Staff / User | User1:1 | Fully supported | |
| Billing Automation / Matter Workflow | No equivalent1:1 | Fully supported | |
| Client Contact Association | AccountContactRelation1:1 | Fully supported | |
| Matter Note | Note1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Case.one gotchas
Trust account balance migration requires financial reconciliation
Per-active-case pricing means closed matters do not count toward billing
Custom field schemas are firm-specific and require enumeration
Large document repositories may require chunked export with integrity verification
Salesforce Sales Cloud gotchas
Workflow Rules and Process Builder are retired
Bulk API batch quota exhaustion during large imports
Storage overage billing is non-obvious
Account-Contact many-to-many relationship mapping
Territory and team member import ordering dependencies
Pair-specific challenges
Migration approach
Audit Case.one schema and matter lifecycle
FlitStack AI exports your full Case.one schema — all matter fields, custom fields, client properties, bill structure, and time-entry schema — via the Case.one API. We compare this against the Salesforce target org's available standard fields and flag every custom field that needs a __c property. Your team confirms the Case vs. Opportunity decision for matters at this stage. We deliver a field-mapping spreadsheet and Salesforce custom-field creation plan (with field types, pick-list values, and help text) for your admin to approve before any custom fields are created.
Create Salesforce custom objects and fields
Your Salesforce admin (or FlitStack's team acting with your org credentials) creates the custom objects and fields from the approved plan: Invoice__c, Invoice_Line_Item__c, and any custom fields on Contact, Case, Task, and Event (Practice_Area__c, Duration__c, Billable__c, Rate__c, Original_Create_Date__c, Source_System_ID__c, etc.). Standard pick-list value sets are created globally so they can be reused across objects. This step runs in a Salesforce sandbox if your org has one; otherwise it runs in production with a rollback plan. No data moves until this step is complete and validated.
Resolve users and contacts by email before data loads
Salesforce requires every Contact to have an AccountId and every Case/Task/Event to have a resolved OwnerId. We match Case.one client emails to existing Salesforce Contacts, create Account records for companies, and match Case.one staff emails to Salesforce Users. Unmatched records are flagged with a resolution report: either create the missing Salesforce user/contact or assign a fallback owner/contact before the migration run commits. No record lands in Salesforce without a resolved foreign key — this prevents orphaned Cases and Tasks that would break reports.
Run sample migration with field-level diff
A representative slice migrates first — typically 200–500 records spanning clients, matters, time entries, and documents. We generate a field-level diff showing source value vs. destination value for every mapped field so your team can verify that matter numbers, client names, time-entry hours, and document links resolve correctly. The diff report is reviewed in a sandbox or read-only Salesforce view; no records are committed to production. Your team signs off before the full run proceeds.
Execute full migration with delta-pickup cutover
The full migration runs in migration-clock order: Accounts (for company names), Contacts (with AccountId links), Cases (with ContactId and OwnerId), Tasks and Events (with WhatId linking to Cases), Invoices (with Case__c links), and ContentDocuments (with ContentDocumentLinks). A 24–48 hour delta-pickup window runs after the main pass completes, capturing any Case.one records modified during the cutover window. The audit log records every insert, update, and skip. One-click rollback reverts all migrated records if reconciliation fails. Post-migration, we deliver a reconciliation report comparing record counts and key field values between Case.one export and Salesforce insert.
Platform deep dives
Case.one
Source
Strengths
Weaknesses
Salesforce Sales Cloud
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Case.one and Salesforce Sales Cloud.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Case.one: Not publicly documented.
Data volume sensitivity
Case.one doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Case.one to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Case.one to Salesforce Sales Cloud migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Case.one
Other ways to arrive at Salesforce Sales Cloud
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.
