CRM migration
Field-level mapping, validation, and rollback between The Case File and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.
The Case File
Source
Salesforce Sales Cloud
Destination
Compatibility
10 of 10
objects map 1:1 between The Case File and Salesforce Sales Cloud.
Complexity
BStandard
Timeline
48–72 hours
Overview
The Case File models legal matters as self-contained records with nested contacts, documents, and time entries. Salesforce Sales Cloud uses a relational object model — Accounts, Contacts, Cases, Tasks, Events, and Opportunities — that requires careful mapping of matter structures to preserve client relationships and billing history. The migration carries everything The Case File stores natively: clients, opposing counsel, matters, documents, time entries, calendar events, and custom matter types. The harder problems are mapping matter statuses to Salesforce Case statuses, preserving the hierarchical relationship between clients and their associated contacts, handling document attachments at scale (particularly large discovery files), and rebuilding The Case File's billing and invoicing logic using Salesforce Opportunities and custom invoice objects. We run migrations via The Case File's REST API and load into Salesforce using Bulk API 2.0 with batch sizes tuned to your Salesforce edition's rate limits. Before committing to a full run, we execute a sample migration against a representative slice of matters so you can verify field-level accuracy.
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 The Case File 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.
The Case File
Client / Contact
Salesforce Sales Cloud
Contact + Account
1:1The Case File stores clients as matter-centric contact records. We split these into Salesforce Contacts linked to an Account (representing the client organization). Individual clients without a firm affiliation become Contacts linked to a default 'Individual Client' Account record. All Contact fields—name, email, phone, mailing address—are mapped to their Salesforce counterparts, and the original matter-client relationship is preserved via the Case_Contact_Role__c junction object.
The Case File
Matter
Salesforce Sales Cloud
Case
1:1The Case File matters map directly to Salesforce Cases. Matter number becomes Case CaseNumber; matter title becomes Subject. We preserve the original matter open date in a custom field since Salesforce's CreatedDate reflects migration time. Matter status maps to Case Status via value mapping per status set.
The Case File
Matter Type / Practice Area
Salesforce Sales Cloud
Case Type + Custom Picklist
1:1The Case File practice area labels (Litigation, Transactional, IP, etc.) map to Salesforce Case Type values. If your firm uses sub-practice areas, we create a custom Practice_Area__c pick-list field on Case and map values one-by-one. This preserves granular practice-area distinctions for reporting and routing while maintaining compatibility with Salesforce Flow automations that trigger based on Case Type.
The Case File
Opposing Counsel / Adversary
Salesforce Sales Cloud
Account + Contact
1:1Opposing parties and their counsel are stored as Account records with a contact role indicator. We create Account records for law firms and opposing parties, then create Contact records for individual attorneys with a custom Role__c field set to 'Opposing Counsel' or 'Adverse Party'.
The Case File
Document / Attachment
Salesforce Sales Cloud
ContentDocument + ContentDocumentLink
1:1The Case File documents re-upload to Salesforce Files. Each document becomes a ContentVersion record linked to the parent Case via ContentDocumentLink. Files exceeding 25MB are flagged for chunked upload or external storage (SharePoint) integration. Version history is preserved as ContentVersion metadata.
The Case File
Time Entry
Salesforce Sales Cloud
Task + Custom Fields
1:1Billable time entries map to Salesforce Tasks with custom fields: Hours__c, Rate__c, Billable__c, and Invoice_Reference__c. We preserve the original entry date, attorney name, matter association, and description. Time entries are linked to the Case via WhatId. Billed entries are flagged as non-editable in Salesforce.
The Case File
Calendar / Event
Salesforce Sales Cloud
Event
1:1The Case File court dates, deadlines, and appointments migrate as Salesforce Events. Original start/end times and reminders are preserved. Events are linked to the associated Case via WhatId. All-day events map with IsAllDayEvent=true. Recurring events are expanded into individual Event records, and event descriptions are preserved in the Subject or Description fields for calendaring accuracy.
The Case File
Note
Salesforce Sales Cloud
Note
1:1Matter notes migrate as Salesforce Notes (the enhanced Notes object, not legacy Note). Body text, author, and creation date are preserved. Notes are linked to the parent Case via ParentId. Rich-text formatting is maintained where The Case File supports it.
The Case File
Billing / Invoice
Salesforce Sales Cloud
Custom Invoice Object + Opportunity
1:1The Case File invoices do not map to any native Salesforce object. We create a custom Invoice__c object with fields for invoice number, amount, status, date, and line items linked to time entries. The related Opportunity represents the matter's financial pipeline for reporting. Invoice PDFs are stored as Salesforce Files linked to Invoice__c records.
The Case File
Custom Matter Fields
Salesforce Sales Cloud
Custom Fields on Case
1:1Any custom fields defined in The Case File for specific matter types (e.g., Case Code, Court Jurisdiction, Jury Trial Flag) are created as custom fields on the Case object in Salesforce with the __c suffix. Field types are matched: pick-list to pick-list, date to date, text to text. Multi-select fields require custom handling via a text field with delimiter or a custom junction object.
| The Case File | Salesforce Sales Cloud | Compatibility | |
|---|---|---|---|
| Client / Contact | Contact + Account1:1 | Fully supported | |
| Matter | Case1:1 | Fully supported | |
| Matter Type / Practice Area | Case Type + Custom Picklist1:1 | Fully supported | |
| Opposing Counsel / Adversary | Account + Contact1:1 | Fully supported | |
| Document / Attachment | ContentDocument + ContentDocumentLink1:1 | Fully supported | |
| Time Entry | Task + Custom Fields1:1 | Fully supported | |
| Calendar / Event | Event1:1 | Fully supported | |
| Note | Note1:1 | Fully supported | |
| Billing / Invoice | Custom Invoice Object + Opportunity1:1 | Fully supported | |
| Custom Matter Fields | Custom Fields on Case1: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.
The Case File gotchas
No publicly documented API for programmatic data extraction
Trust account ledger balances require manual verification
Custom fields lack a documented export schema
Document folder structure does not export flatly
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
Provision Salesforce custom objects and fields
Before data moves, your Salesforce admin (or our team) creates the custom objects and fields required for the migration: Invoice__c, Case_Contact_Role__c, and any custom fields on Case, Contact, Task, and Event referenced in the field mapping. We deliver a schema setup manifest listing every custom field by object, type, and pick-list value set so Salesforce-side configuration completes before validation runs.
Export The Case File data via REST API
We authenticate against The Case File API using your admin credentials, enumerate all matter types, and pull records in parallel streams: matters, contacts, documents, time entries, events, notes, and invoices. Documents are downloaded to a staging S3 bucket with their parent matter ID embedded in the file metadata. We run a source-side data quality check that flags duplicate contacts, missing required fields, and records with invalid dates before transformation begins.
Transform and validate data against Salesforce schema
Source records are transformed per the field mapping: date formats normalized to Salesforce ISO 8601, pick-list values validated against Salesforce allowed values, and Salesforce ID lookups resolved. We run a Salesforce-side pre-validation step using the Salesforce Tooling API to confirm every record will pass validation rules before it enters a Bulk API batch. Records failing validation are routed to a correction queue with specific error messages returned by the Salesforce API.
Execute sample migration with field-level diff
A representative slice of 100–500 records migrates first: a mix of active matters, closed matters, matters with large document sets, and matters with complex contact role structures. We generate a field-level diff comparing source values to Salesforce field values for every migrated record. You verify that matter status mapping, time-entry totals, document counts, and contact role assignments meet your expectations before the full run commits.
Run full migration with delta-pickup window
The full data migration runs against Salesforce using Bulk API 2.0. A delta-pickup window (typically 24–48 hours) captures any matters, time entries, or documents created or modified in The Case File during the cutover. All operations are logged to an audit trail with source record ID, destination Salesforce ID, operation type, and timestamp. One-click rollback reverts all Salesforce records to their pre-migration state if reconciliation fails. Post-migration, we deliver a reconciliation report showing record counts by object, total billable hours, and total billing amounts matched between source and destination.
Platform deep dives
The Case File
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 The Case File 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
The Case File: Not publicly documented.
Data volume sensitivity
The Case File 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 The Case File to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.
Walk through your The Case File 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 The Case File
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.