CRM migration
Field-level mapping, validation, and rollback between MyCase and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.
MyCase
Source
Salesforce Sales Cloud
Destination
Compatibility
10 of 12
objects map 1:1 between MyCase and Salesforce Sales Cloud.
Complexity
BStandard
Timeline
48–72 hours
Overview
MyCase is a legal-practice management platform built around contacts, companies, and matters with a case-centric workflow. Salesforce Sales Cloud is an enterprise CRM built around Accounts, Contacts, Leads, and Opportunities, requiring custom fields and record types for non-standard entity types. The migration must translate MyCase's matter-centric schema — where cases hold client relationships, tasks, billing, and documents — into Salesforce's relational model where AccountId on Contact resolves the client link, RecordTypeId on Case distinguishes matter types, and custom fields (with the __c suffix) store legal-specific properties like practice area, billing method, and responsible attorney. FlitStack AI extracts data from MyCase using its contact-and-case export spreadsheets and Full Data Backup tool, applies field-level mapping against Salesforce's Bulk API and REST API, then validates with a sample migration before committing the full dataset. Workflows, document templates, QuickBooks sync configurations, and automated text messaging do not migrate — those require manual rebuild in Salesforce's Flow Builder, Salesforce Files, and AppExchange integrations. A 24–48 hour delta-pickup window captures any matter changes made in MyCase during the cutover window.
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 MyCase 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.
MyCase
Contact
Salesforce Sales Cloud
Contact
1:1MyCase contacts map 1:1 to Salesforce Contacts. Salesforce requires an AccountId on every Contact — contacts without a primary company in MyCase are attached to a default 'Unassigned' Account record or routed to a Salesforce Lead based on a status flag.
MyCase
Contact
Salesforce Sales Cloud
Lead
1:manyMyCase contacts marked as 'Prospective Client' or designated as 'Referral Source' are routed to Salesforce Lead rather than Contact, with the referral-source designation preserved as a Lead Source pick-list value. The routing logic evaluates the contact's client_status field — only active clients and matter-linked contacts become Salesforce Contacts. All other contact types (prospective, referral, inactive) land as Leads to maintain your pipeline visibility and marketing segmentation without cluttering your Contact object with non-client records.
MyCase
Company
Salesforce Sales Cloud
Account
1:1MyCase companies map directly to Salesforce Accounts using the company name as the Account Name. Company hierarchies where a parent firm owns or branches into subsidiary organizations map to the Account.ParentId field, preserving the organizational chart structure. For contacts associated with multiple companies in MyCase, the primary company becomes the AccountId on Contact while additional affiliations are surfaced as Account Contact Relation junction records, maintaining N:N relationship fidelity across both platforms.
MyCase
Case (Matter)
Salesforce Sales Cloud
Case
1:1MyCase matters map to Salesforce Cases linked to the Account representing the client. The Case.RecordTypeId distinguishes matter type (Litigation, Transactional, Advisory). Each MyCase matter type requires a corresponding Salesforce record type so that status pick-list values, priority, and custom fields are scoped correctly per practice area.
MyCase
Case Type
Salesforce Sales Cloud
RecordTypeId + Case Type Field
1:1MyCase matter type (e.g., Family Law, Personal Injury, Real Estate) becomes a Salesforce custom pick-list field Practice_Area__c on Case, keyed by the Case RecordTypeId. Each matter type needs its own record type in Salesforce so page layouts display the correct field set.
MyCase
Task
Salesforce Sales Cloud
Task
1:1MyCase tasks map to Salesforce Tasks with the WhatId pointing to the Case (matter) record. Task priority, due date, and status map to Salesforce equivalents. Open vs. completed status is preserved; completed task completion dates are stored in the ActivityDate field.
MyCase
Time Entry
Salesforce Sales Cloud
Case Custom Fields (Billing_Hours__c, Billing_Amount__c)
many:1Individual time entries from MyCase are aggregated by matter and stored in custom Number and Currency fields on the Salesforce Case record (Total_Billable_Hours__c, Total_Billable_Amount__c). The aggregation sums all billable hours and amounts per matter to populate these rollup fields for pipeline and profitability reporting. Detailed time-entry history — including date, attorney, description, and hourly rate — is preserved as a custom Time_Entry_Log__c child object linked to Case via a lookup relationship, ensuring audit trails and billing audits remain intact after migration.
MyCase
Document
Salesforce Sales Cloud
ContentDocument / Salesforce Files
1:1MyCase Drive documents are re-uploaded as Salesforce Files attached to the corresponding Case record. File folder structure from MyCase is recreated as Salesforce Libraries or as a custom Folder_Path__c field on ContentDocument for navigation continuity. 25MB per-file Salesforce limits apply.
MyCase
Custom Field
Salesforce Sales Cloud
Custom Field (__c)
1:1Every MyCase custom field on Contact, Company, or Case becomes a Salesforce custom field with the __c API name suffix. Custom fields must be pre-created in Salesforce Setup before migration runs — we deliver a setup plan listing each field's label, API name, data type, and pick-list values so your admin creates them in advance.
MyCase
User / Attorney
Salesforce Sales Cloud
User
1:1MyCase staff members (attorneys, paralegals, admins) map to Salesforce Users resolved by email address match. Unmatched MyCase owners are flagged before migration so your team either invites them to Salesforce first or assigns their records to a fallback Salesforce user.
MyCase
Note
Salesforce Sales Cloud
Note
1:1MyCase notes attached to a matter map to Salesforce Notes (using the modern Note object, not the legacy Note) linked to the Case via the ParentId field. All rich-text formatting — including bullet points, bold/italic text, hyperlinks, and embedded tables — is preserved as HTML in the Salesforce Note Body field. The note title defaults to the first line of the MyCase note content, and the note's created date maps to the Salesforce Note CreatedDate to maintain historical chronology for matter documentation audits.
MyCase
Workflow / Automation
Salesforce Sales Cloud
Not Migrated
1:1MyCase workflow tasks, automated calendaring rules, deadline triggers, and milestone logic have no direct Salesforce equivalent and cannot be migrated automatically. All MyCase workflow task templates and automation definitions are exported as a detailed reference document listing every workflow's name, trigger conditions, task assignments, escalation rules, and deadline calculations. Your Salesforce admin uses this reference to rebuild equivalent automation logic in Flow Builder, covering triggers on Case creation, time-based deadline updates, and automated task generation based on matter type.
| MyCase | Salesforce Sales Cloud | Compatibility | |
|---|---|---|---|
| Contact | Contact1:1 | Fully supported | |
| Contact | Lead1:many | Fully supported | |
| Company | Account1:1 | Fully supported | |
| Case (Matter) | Case1:1 | Fully supported | |
| Case Type | RecordTypeId + Case Type Field1:1 | Fully supported | |
| Task | Task1:1 | Fully supported | |
| Time Entry | Case Custom Fields (Billing_Hours__c, Billing_Amount__c)many:1 | Fully supported | |
| Document | ContentDocument / Salesforce Files1:1 | Fully supported | |
| Custom Field | Custom Field (__c)1:1 | Fully supported | |
| User / Attorney | User1:1 | Fully supported | |
| Note | Note1:1 | Fully supported | |
| Workflow / Automation | Not Migrated1: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.
MyCase gotchas
QuickBooks sync is strictly one-directional
Advanced API access is tier-gated
Document migration requires offline file transfer
Bulk rate updates on historical time entries are not supported
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
Scope discovery and MyCase data extraction
FlitStack AI reviews your MyCase instance — counting contacts, companies, matters, tasks, time entries, and documents. We use MyCase's contact-and-case export spreadsheets for structured data and the Full Data Backup tool for complete exports. MyCase API extraction runs with 25 req/s throttling to avoid rate-limit hits. We deliver a data inventory report listing record counts per object, custom field inventory, matter types, and owner distribution so both teams agree on scope before mapping begins.
Design Salesforce custom fields and record types
Before any data loads, your Salesforce admin (or our team) creates the __c custom fields and Record Types required for the migration. We deliver a field-creation plan: for each MyCase custom property we specify the Salesforce field label, API name (__c suffix), data type, pick-list values, and which Salesforce object it belongs to. For every MyCase matter type we specify the Salesforce Record Type name, associated page layout, and status pick-list values. This plan is reviewed and executed before the migration validation run so the schema is ready when data arrives.
Resolve MyCase users to Salesforce users by email
MyCase staff (attorneys, paralegals, administrative users) are mapped to Salesforce Users via email address match. Any MyCase owner whose email does not correspond to an existing Salesforce User is flagged on a pre-migration exception report. Your team either provisions those users in Salesforce before the migration run or assigns their records to a designated fallback Salesforce User. No Case or Task lands without a valid OwnerId — the owner resolution step gates the migration to prevent orphaned records.
Run sample migration with field-level diff
A representative slice of 200–500 records spanning contacts, companies, matters, tasks, and documents migrates into your Salesforce sandbox first. We generate a field-level diff between the MyCase source values and the Salesforce destination values so you can verify Practice_Area__c pick-list mapping, AccountId resolution on contacts, Case.RecordTypeId assignment, and document linkage before the full run. You approve the sample results in writing before we schedule the production migration — this gates any full-load commit.
Execute full migration with delta-pickup and audit log
The full dataset loads into Salesforce Production using Bulk API 2.0 for high-volume objects and REST API for records requiring immediate validation. A 24–48 hour delta-pickup window runs in parallel, capturing any matter changes, new contacts, or updated tasks created in MyCase during the cutover period. Every operation is logged in a FlitStack AI audit trail. If reconciliation identifies discrepancies exceeding your defined tolerance threshold, one-click rollback reverts the Salesforce org to its pre-migration state so your team can re-clean source data and re-run without data loss.
Platform deep dives
MyCase
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 MyCase 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
MyCase: 25 requests per second per client.
Data volume sensitivity
MyCase 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 MyCase to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.
Walk through your MyCase 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 MyCase
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.