CRM migration
Field-level mapping, validation, and rollback between Case UI and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.
Case UI
Source
Salesforce Sales Cloud
Destination
Compatibility
11 of 12
objects map 1:1 between Case UI and Salesforce Sales Cloud.
Complexity
BStandard
Timeline
48–72 hours
Overview
Case UI is a practice-management platform built for solo practitioners and small law firms, storing matters, clients, calendar events, time entries, and documents in a flat relational model optimized for legal workflows. Salesforce Sales Cloud uses a normalized object hierarchy (Account → Contact → Case) with RecordTypeId, pick-list fields scoped by page layout, and a separate Activity model for Tasks and Events. The migration carries Case UI clients into Salesforce Accounts and Contacts, matters into Cases with custom fields for practice-area and billing configuration, and documents re-uploaded as Salesforce Files. The harder problems are mapping Case UI's billing计时 (time-entry) structure to Salesforce's custom fields, translating matter status values to Case Status pick-lists, and handling the N:N client-to-matter relationship that requires junction objects or the Account Contact Role model. Workflows, templates, and billing rules built in Case UI do not transfer — we export them as reference documents for your Salesforce admin to rebuild in Flow and custom settings.
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 UI 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 UI
Client
Salesforce Sales Cloud
Account
1:1If a client already exists, we use fuzzy name and address match to avoid duplicates, logging merges for review. Additional fields like client type and billing email map to custom Account fields.
Case UI
Contact (primary attorney)
Salesforce Sales Cloud
Contact
1:1We also check for duplicate contacts by email, merging or creating new records as needed. Contact roles such as Primary Attorney or Billing Contact are stored in custom fields (Contact_Role__c) for reporting.
Case UI
Matter
Salesforce Sales Cloud
Case
1:1We preserve the matter open date in Original_Create_Date__c, map matter status to Case Status via value‑mapping, and retain court venue, statute of limitations, and billing arrangement fields as text or pick‑list fields on the Case.
Case UI
Matter Status
Salesforce Sales Cloud
Case Status (pick-list)
1:1During mapping, we also verify that each status aligns with the appropriate RecordType and business hours configuration in Salesforce, adjusting the mapping as needed to prevent validation errors.
Case UI
Time Entry
Salesforce Sales Cloud
Custom Time Entry object or custom fields on Case
1:1Each Time_Entry__c record also captures the matter ID in Source_System_ID__c. The migration validates that all linked Cases exist before inserting entries to avoid orphan records.
Case UI
Document / File
Salesforce Sales Cloud
Salesforce Files (ContentDocument / ContentVersion)
1:1During the upload, we preserve the original file name and content version metadata, and we set the appropriate ShareType and Visibility to match your org's default File sharing settings.
Case UI
Calendar / Event
Salesforce Sales Cloud
Event
1:1Each Event also records the Event Type (e.g., Deposition, Hearing) in a custom Type__c field, and the original Case UI event ID is stored in Source_System_ID__c for audit trails.
Case UI
Task
Salesforce Sales Cloud
Task
1:1If a task's assigned user does not exist in Salesforce, we assign it to a fallback admin user and flag the record for later re-assignment. Custom fields such as Task_Category__c are migrated as well.
Case UI
Note
Salesforce Sales Cloud
Note
1:1We also map the original note created date to the Salesforce Note CreatedDate field, and we preserve any attachments embedded in the note as separate Salesforce Files linked to the same Case record.
Case UI
Custom Fields
Salesforce Sales Cloud
Custom Fields (__c)
1:1Case UI custom fields for practice-area specific data (statute of limitations, court venue, opposing counsel details) migrate as Salesforce custom fields with __c suffix. Data type preserved (text, pick-list, date, checkbox) during migration. Custom fields scoped per object — Contact custom fields do not collide with Case custom fields.
Case UI
Client-Matter Association (N:N)
Salesforce Sales Cloud
Account Contact Role / Junction Object
many:1Case UI allows multiple clients per matter and multiple matters per client. Salesforce Cases support one primary Contact. We map the primary client to Case.ContactId and remaining clients to Account Contact Roles, preserving the association with role type (Plaintiff, Defendant, Insured).
Case UI
Billing Configuration
Salesforce Sales Cloud
Custom fields on Case
1:1We also preserve the billing currency and rate configurations in custom fields, and we export a mapping spreadsheet for the billing admin to reference when setting up the QuickBooks or PracticePanther connector.
| Case UI | Salesforce Sales Cloud | Compatibility | |
|---|---|---|---|
| Client | Account1:1 | Fully supported | |
| Contact (primary attorney) | Contact1:1 | Fully supported | |
| Matter | Case1:1 | Fully supported | |
| Matter Status | Case Status (pick-list)1:1 | Fully supported | |
| Time Entry | Custom Time Entry object or custom fields on Case1:1 | Fully supported | |
| Document / File | Salesforce Files (ContentDocument / ContentVersion)1:1 | Fully supported | |
| Calendar / Event | Event1:1 | Fully supported | |
| Task | Task1:1 | Fully supported | |
| Note | Note1:1 | Fully supported | |
| Custom Fields | Custom Fields (__c)1:1 | Mapping required | |
| Client-Matter Association (N:N) | Account Contact Role / Junction Objectmany:1 | Fully supported | |
| Billing Configuration | 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.
Case UI gotchas
No public API documentation found
On-Premise perpetual license has upgrade isolation risk
No verified public reviews or G2/Capterra feedback
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
Pre-migration schema inventory and Salesforce Setup plan
We audit Case UI custom fields, matter types, practice-area pick-lists, and time-entry structure. From this inventory we generate a Salesforce Setup manifest: every custom field to create with __c suffix, data type, and pick-list values. We also identify the client-primary-matter rule (most recent, alphabetically first, or by your specification) for resolving N:N associations. Your Salesforce admin creates the custom fields in a sandbox before test migration runs.
Owner and user resolution by email match
Case UI attorney and staff records are matched against Salesforce users by email address. Unmatched owners are flagged before migration — your team either invites them to Salesforce first or assigns their records to a fallback owner (e.g., the admin user). No record lands in Salesforce without a resolved OwnerId. If a Case UI user has no corresponding Salesforce profile, FlitStack creates a temporary mapping record, and you can either provision the user in Salesforce beforehand or designate a placeholder UserId to hold the data until the account is created. This ensures referential integrity across Account, Contact, and Case records.
Migration sequencing: Accounts → Contacts → Cases → Activities
Salesforce requires Account records before Contacts (via AccountId) and Contacts before Cases (via ContactId). We sequence the migration so foreign keys resolve correctly: Clients → Accounts, then Contact records linked to Accounts, then Matters → Cases with ContactId for primary client, then Time Entries → Time_Entry__c linked to Cases. Documents and Notes attach after parent records exist. During this sequence we perform field updates in a single pass to avoid circular dependencies, and any error halts the run and reports the offending record for correction.
Sample migration with field-level diff before full run
A representative slice (typically 200–500 records spanning clients, matters, time entries, and documents) migrates into a Salesforce sandbox first. We generate a field-level diff comparing source values against destination fields so you can verify practice-area mapping, billing configuration transfer, and matter status translation before the full run commits. The diff report highlights any data truncation, pick‑list mismatches, or missing required fields, enabling you to adjust field mappings or Salesforce Setup configurations before the production migration run.
Delta-pickup window and rollback readiness
Full migration runs against Salesforce. A delta-pickup window (typically 24–48 hours) captures any Case UI records modified during cutover so Salesforce reflects the final state at go-live. Audit log captures every insert, update, and error. One-click rollback is available if reconciliation fails — FlitStack reverts the org to its pre-migration state and schedules a corrected re-run. During the delta window, any newly created contacts, updated matters, or revised time entries are automatically imported, ensuring zero data loss. The rollback option uses a snapshot taken at migration start, so you can revert without manual data cleanup.
Platform deep dives
Case UI
Source
Strengths
Weaknesses
Salesforce Sales Cloud
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 3 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 UI and Salesforce Sales Cloud.
Object compatibility
3 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 UI: Not publicly documented.
Data volume sensitivity
Case UI 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 UI to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Case UI 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 UI
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.