CRM migration
Field-level mapping, validation, and rollback between Virtual Case Management and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.
Virtual Case Management
Source
Salesforce Sales Cloud
Destination
Compatibility
13 of 13
objects map 1:1 between Virtual Case Management and Salesforce Sales Cloud.
Complexity
BStandard
Timeline
3–5 days
Overview
Virtual Case Management (VCM) serves nonprofit and government human-service agencies with client-case records, multi-agency referral networks, service plans, and case-note timelines. Its flat data model uses Clients, Cases, Workers, Agencies, and custom fields organized around the individual service episode. Salesforce Sales Cloud uses a normalized object graph: Account (for agencies), Contact (for clients), Case (for cases), User (for workers), with a rich relationship model (Account hierarchy, CaseTeam, ContentDocumentLink) and a reporting engine that VCM lacks. FlitStack AI sequences the migration so foreign-key dependencies resolve correctly: Agencies → Accounts first, then Clients → Contacts, then Cases with their linked Notes and Files. We surface VCM's referral relationships and service plans as custom Salesforce objects, preserving the agency-to-agency referral chain that is core to VCM workflows. Workflows, assignment rules, and email templates do not migrate — we export definitions for rebuild in Salesforce Flow. We use scoped read access on VCM during the cutover window and run a 24–48h delta pickup so Salesforce reflects the final VCM state at go-live.
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 Virtual Case Management 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.
Virtual Case Management
Client
Salesforce Sales Cloud
Contact
1:1VCM clients map directly to Salesforce Contacts. We set the Contact's AccountId to the agency Account resolved by agency lookup on the VCM client record. Primary address fields and phone/email map to Contact standard fields. Unassigned clients attach to a default 'Unassigned Agency' Account.
Virtual Case Management
Case
Salesforce Sales Cloud
Case
1:1VCM cases map 1:1 to Salesforce Cases. Case number maps to Salesforce Case.CaseNumber; status (Open/Closed/On Hold) maps to Case.Status via value-mapping. Priority maps to Case.Priority. The VCM case description populates Case.Description. Parent Case relationships in VCM map to Case.ParentId in Salesforce.
Virtual Case Management
Agency
Salesforce Sales Cloud
Account
1:1VCM agencies map to Salesforce Accounts. Agency name becomes Account.Name; website and address fields map directly. Parent-agency hierarchies in VCM map to Account.ParentId. Multi-agency security is not automatic — Salesforce sharing rules must be configured post-migration to replicate VCM's cross-agency visibility model.
Virtual Case Management
Worker
Salesforce Sales Cloud
User
1:1VCM workers map to Salesforce Users by email match. Active workers in VCM become active Salesforce users; inactive workers become inactive users to preserve historical case-assignment data. Role and department from VCM populate User.Role and a custom Department__c field. We also map the worker's phone number to User.Phone for contactability.
Virtual Case Management
Case Note
Salesforce Sales Cloud
Note
1:1VCM case notes migrate as Salesforce Notes attached to the corresponding Case. Note Title uses the VCM note type (e.g., 'Progress Note', 'Intake Note'); Body contains the full note text. Original note date maps to Note.CreatedDate. Owner resolves via worker-to-user email match.
Virtual Case Management
Document / Attachment
Salesforce Sales Cloud
ContentDocument / ContentVersion
1:1VCM file attachments are re-uploaded as Salesforce Files (ContentVersion). The file name and content are preserved; ContentDocument is created automatically on upload. We link each file to the target Case via ContentDocumentLink. Files exceeding Salesforce's 25MB default limit are flagged for chunked upload.
Virtual Case Management
Referral
Salesforce Sales Cloud
Referral__c (custom)
1:1VCM's referral system (Sending Agency → Receiving Agency for a client) has no Salesforce standard equivalent. We create a custom Referral__c object with lookup fields to Contact (client), Account (sending agency), Account (receiving agency), and a Status__c pick-list (Pending, Accepted, Completed, Declined). Referral date and service type become custom fields.
Virtual Case Management
Service Plan
Salesforce Sales Cloud
Service_Plan__c (custom)
1:1VCM service and treatment plans map to a custom Service_Plan__c object linked to Case. Fields include Plan_Type__c (text), Start_Date__c, End_Date__c, Goals__c (long text), and Status__c pick-list. If VCM stores plans as documents rather than structured fields, those files migrate as Salesforce Files with a custom ContentVersion metadata field linking to the Case.
Virtual Case Management
Worker Assignment
Salesforce Sales Cloud
CaseTeamMember / CaseAssignment__c (custom)
1:1VCM worker-to-case assignments map to Salesforce CaseTeamMember for the built-in role model. If VCM uses specific assignment types (Primary Worker, Supervisor, Referral Worker), we create a custom CaseAssignment__c junction object to preserve the assignment role, since CaseTeamMember's Role field has a limited pick-list.
Virtual Case Management
Client Demographics
Salesforce Sales Cloud
Contact + Custom Fields
1:1VCM demographic fields beyond standard Contact fields (household size, income bracket, risk level, funding source) migrate to custom fields on Contact: Household_Size__c (number), Income_Bracket__c (pick-list), Risk_Level__c (pick-list), Funding_Source__c (text). We create these as Salesforce custom fields before migration runs. All fields are indexed for fast search and reporting.
Virtual Case Management
Client ID / VCM Internal ID
Salesforce Sales Cloud
Contact.Source_System_ID__c
1:1VCM's internal client ID (generated ID number that reviewers highlight as a valued feature) is preserved in Contact.Source_System_ID__c. This supports delta-run de-duplication and allows your team to cross-reference records back to the original VCM system during the transition period. It also facilitates audit trails.
Virtual Case Management
Case ID / VCM Internal Case Number
Salesforce Sales Cloud
Case.Source_System_Case_Number__c
1:1VCM case numbers are preserved in Case.Source_System_Case_Number__c so case files in Salesforce retain their original identifiers for audits and cross-referencing. This field is indexed for fast lookup. This ensures that reporting can reference original case IDs without manual lookup and supports integration with external case management systems.
Virtual Case Management
VCM Custom Objects
Salesforce Sales Cloud
Custom Object
1:1Any VCM custom objects beyond the standard set map 1:1 to Salesforce custom objects. We inspect the VCM API schema during discovery to identify all custom object definitions, then create matching Salesforce custom objects with equivalent field types before mapping data.
| Virtual Case Management | Salesforce Sales Cloud | Compatibility | |
|---|---|---|---|
| Client | Contact1:1 | Fully supported | |
| Case | Case1:1 | Fully supported | |
| Agency | Account1:1 | Fully supported | |
| Worker | User1:1 | Fully supported | |
| Case Note | Note1:1 | Fully supported | |
| Document / Attachment | ContentDocument / ContentVersion1:1 | Fully supported | |
| Referral | Referral__c (custom)1:1 | Fully supported | |
| Service Plan | Service_Plan__c (custom)1:1 | Fully supported | |
| Worker Assignment | CaseTeamMember / CaseAssignment__c (custom)1:1 | Fully supported | |
| Client Demographics | Contact + Custom Fields1:1 | Fully supported | |
| Client ID / VCM Internal ID | Contact.Source_System_ID__c1:1 | Fully supported | |
| Case ID / VCM Internal Case Number | Case.Source_System_Case_Number__c1:1 | Fully supported | |
| VCM Custom Objects | Custom Object1: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.
Virtual Case Management gotchas
No publicly documented bulk export API
Report definitions are not exportable
Database-entry interface creates training burden
Multi-agency security level mapping requires manual 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
Discovery and data profiling
FlitStack AI reads VCM's API schema and export endpoints to inventory all standard and custom objects, field types, and record counts. We profile data quality — identifying duplicate clients, missing agency assignments, and records with invalid worker references. We export VCM report definitions and referral routing rules as rebuild references for your Salesforce admin. The output is a migration plan with object-level record counts and a data-cleanse checklist.
Design Salesforce schema and custom objects
Based on the discovery output, FlitStack AI generates a Salesforce setup plan: custom objects (Referral__c, Service_Plan__c, CaseAssignment__c), custom fields on Contact and Case, sharing-rule design for multi-agency visibility, and pick-list value sets for status and priority fields. Your Salesforce admin creates these in a sandbox before the migration run. We deliver field-level mapping documentation that your admin can validate against the sandbox.
Resolve workers and agencies before case migration
Salesforce requires AccountId on Contact and OwnerId on Case. We sequence the migration: first, Agencies → Accounts with ParentId for hierarchy; then, Workers → Users by email match with inactive flags for terminated staff; then, Clients → Contacts with AccountId linking to the agency. Any worker not matched to a Salesforce user is flagged with a fallback owner so Case records remain valid on insertion.
Run sample migration with field-level diff
A representative slice of 50–200 records — spanning clients, cases, notes, documents, referrals, and service plans — migrates into a Salesforce sandbox first. We generate a field-level diff report comparing source values to destination field values so you can verify status mapping, referral lookups, service-plan linkage, and worker ownership before the full run commits. Adjustments to mapping logic happen at this stage.
Execute full migration with delta-pickup cutover
Full data migration runs against your production Salesforce org. A delta-pickup window of 24–48 hours captures any VCM records modified or created during the cutover window. All operations are logged to an audit trail (operation, record ID, source value, destination value, timestamp, operator). If reconciliation reveals missing records or incorrect mappings, one-click rollback reverts the org to its pre-migration state while we correct and re-run.
Platform deep dives
Virtual Case Management
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 Virtual Case Management 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
Virtual Case Management: Not publicly documented — confirmed during integration scoping..
Data volume sensitivity
Virtual Case Management 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 Virtual Case Management to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Virtual Case Management 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 Virtual Case Management
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.