CRM migration

Migrate from Virtual Case Management to Salesforce Sales Cloud

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 logo

Virtual Case Management

Source

Salesforce Sales Cloud

Destination

Salesforce Sales Cloud logo

Compatibility

100%

13 of 13

objects map 1:1 between Virtual Case Management and Salesforce Sales Cloud.

Complexity

BStandard

Timeline

3–5 days

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Virtual Case Management logo

Virtual Case Management

What's pushing teams away

  • Reporting and demographic tools are severely limited, making it difficult to extract meaningful business intelligence or comply with funder data requests.
  • The platform is challenging for users unfamiliar with database-style data entry, creating adoption friction for non-technical staff.
  • Agencies outgrow the platform as they scale, needing advanced workflow automation or deeper integrations that VCM does not provide.
  • Lack of flexible export options makes it difficult to move data to other systems when switching platforms.

Choosing

Salesforce Sales Cloud logo

Salesforce Sales Cloud

What's pulling them in

  • The AppExchange marketplace with 5,000+ prebuilt apps gives enterprises integrations for nearly every business workflow without custom development.
  • Native Einstein AI for lead scoring, opportunity insights, and predictive forecasting adds intelligence without a separate platform purchase.
  • Territory management, multi-currency support, and advanced forecasting satisfy the needs of complex B2B sales organizations with structured revenue teams.
  • Slack, Tableau, and CPQ are deeply integrated into the core platform, keeping the sales stack unified for teams already in the Salesforce ecosystem.
  • Organizations with a large, established Salesforce implementation choose it because switching costs — integrations, custom code, trained admins — are prohibitive.

Object mapping

How Virtual Case Management objects map to Salesforce Sales Cloud

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

maps to

Salesforce Sales Cloud

Contact

1:1
Fully supported

VCM 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

maps to

Salesforce Sales Cloud

Case

1:1
Fully supported

VCM 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

maps to

Salesforce Sales Cloud

Account

1:1
Fully supported

VCM 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

maps to

Salesforce Sales Cloud

User

1:1
Fully supported

VCM 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

maps to

Salesforce Sales Cloud

Note

1:1
Fully supported

VCM 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

maps to

Salesforce Sales Cloud

ContentDocument / ContentVersion

1:1
Fully supported

VCM 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

maps to

Salesforce Sales Cloud

Referral__c (custom)

1:1
Fully supported

VCM'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

maps to

Salesforce Sales Cloud

Service_Plan__c (custom)

1:1
Fully supported

VCM 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

maps to

Salesforce Sales Cloud

CaseTeamMember / CaseAssignment__c (custom)

1:1
Fully supported

VCM 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

maps to

Salesforce Sales Cloud

Contact + Custom Fields

1:1
Fully supported

VCM 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

maps to

Salesforce Sales Cloud

Contact.Source_System_ID__c

1:1
Fully supported

VCM'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

maps to

Salesforce Sales Cloud

Case.Source_System_Case_Number__c

1:1
Fully supported

VCM 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

maps to

Salesforce Sales Cloud

Custom Object

1:1
Fully supported

Any 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.

Gotchas + challenges

What specifically takes care here

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 logo

Virtual Case Management gotchas

High

No publicly documented bulk export API

Medium

Report definitions are not exportable

Low

Database-entry interface creates training burden

Medium

Multi-agency security level mapping requires manual verification

Salesforce Sales Cloud logo

Salesforce Sales Cloud gotchas

High

Workflow Rules and Process Builder are retired

High

Bulk API batch quota exhaustion during large imports

Medium

Storage overage billing is non-obvious

Medium

Account-Contact many-to-many relationship mapping

Low

Territory and team member import ordering dependencies

Pair-specific challenges

  • Multi-agency case sharing requires Salesforce sharing-rule configuration post-migration

    VCM enforces multi-agency security levels that let agencies see only cases where they are the sending or receiving provider. Salesforce has no native multi-agency visibility model — Account sharing rules, Account teams, or manual sharing must be configured after data lands. We deliver a sharing-model design document as part of the migration plan so your Salesforce admin can configure cross-agency visibility before go-live. Without this step, an agency may see zero cases after migration.

  • VCM referral system has no direct Salesforce equivalent — requires custom Referral__c object

    VCM's referral system tracks cases sent between agencies with status and service-type metadata. Salesforce has no standard referral object — we create a custom Referral__c junction object with lookups to Contact (client) and Account (sending/receiving agency). If your referral data includes complex routing rules or waiting-list logic, those must be captured as Salesforce Flow automations post-migration. We export the full referral data schema during discovery so nothing is lost in the gap.

  • Service plans stored as unstructured documents require metadata mapping to Salesforce Files

    If VCM stores service and treatment plans as document uploads rather than structured fields, those files migrate as Salesforce Files. We link them to the Case via ContentDocumentLink, but the structured plan data (goals, dates, outcomes) does not automatically parse. For reporting on plan status, you need either a custom Service_Plan__c object (we create this) or a metadata-enriched ContentVersion with custom fields. We advise during discovery which approach fits your reporting needs.

  • Worker-to-case assignments require a custom junction model for role fidelity

    VCM assigns workers to cases with specific roles (Primary Worker, Supervisor, Referral Worker). Salesforce's built-in CaseTeamMember object has a Role field with a limited pick-list that may not cover all VCM role types. For full fidelity, we create a custom CaseAssignment__c junction object between Case and User with an Assignment_Type__c pick-list matching VCM's role vocabulary. Your admin decides whether to use the built-in CaseTeamMember, the custom object, or both. Both options can coexist; however, using the custom object also enables tracking assignment start dates and notes for audit trails.

  • VCM reports and dashboards do not migrate — definitions must be exported for rebuild

    G2 reviewers consistently cite VCM's limited reporting as a pain point. Ironically, the reports you have built in VCM also will not transfer to Salesforce. We export VCM report definitions and query results during the discovery phase so your Salesforce admin has a reference data set to build equivalent Salesforce reports and Einstein Analytics dashboards. Report rebuilding is a post-migration step scoped separately. Plan for at least one to two weeks of admin time to design and validate the new reports before full rollout.

Migration approach

Six steps for a successful Virtual Case Management to Salesforce Sales Cloud data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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

Context on both ends of the pair

Virtual Case Management logo

Virtual Case Management

Source

Strengths

  • Purpose-built for nonprofit and human services case management rather than adapted from a general CRM.
  • Referral system natively links client records across the VCM agency network without manual re-entry.
  • Multi-security-level architecture addresses inter-agency confidentiality requirements out of the box.
  • Responsive support team helps users resolve questions without extensive documentation.
  • Client auto-ID generation provides immediate record organization for new agencies.

Weaknesses

  • Reporting and analytics tools are shallow and do not meet typical funder or management reporting requirements.
  • No publicly documented bulk export or API, making data portability a significant hurdle.
  • Steep learning curve for users without database or structured data entry experience.
  • Limited customization compared to modern CRM platforms, restricting workflow adaptation as agencies grow.
  • No clear path to advanced automation or deep third-party integrations.
Salesforce Sales Cloud logo

Salesforce Sales Cloud

Destination

Strengths

  • Largest enterprise app ecosystem in CRM with 5,000+ AppExchange integrations covering nearly every vertical workflow.
  • Native Einstein AI delivers lead scoring, opportunity insights, and predictive forecasting without a third-party layer.
  • Advanced territory management, multi-currency, and flexible forecasting satisfy complex B2B revenue structures.
  • Deep platform extensibility: Custom Objects, Apex, Flow, and the Metadata API allow full schema customization.
  • Well-documented REST API, Bulk API, and Composite API with published rate limits for programmatic migration.

Weaknesses

  • Pricing model is layered and opaque in practice: per-seat fees plus storage overages, add-on subscriptions, and annual uplifts compound to 30–40% above sticker price.
  • Workflow Rules and Process Builder are deprecated, forcing all orgs onto Salesforce Flow — a migration task that catches many teams by surprise.
  • Steep administrative complexity: meaningful configuration requires a dedicated Salesforce admin or consultant.
  • API rate limits are edition-gated (100k/day base for Enterprise) and easily exhausted by large historical imports without throttling.
  • Data export is exportable via Data Loader but preserving relationship integrity across 30+ objects requires careful ETL sequencing.

Complexity grading

How hard is this migration?

Standard CRM migration. 2 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Virtual Case Management and Salesforce Sales Cloud.

  • Object compatibility

    B

    2 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Virtual Case Management: Not publicly documented — confirmed during integration scoping..

  • Data volume sensitivity

    B

    Virtual Case Management doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Virtual Case Management to Salesforce Sales Cloud migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Virtual Case Management to Salesforce Sales Cloud data migrations

Answers to the questions buyers ask most during Virtual Case Management to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

For VCM setups with under 25,000 records — clients, cases, notes, and documents — the migration typically completes in 3–5 days of clock time after Salesforce schema is ready. Complex VCM deployments with referral networks, service-plan objects, and multi-agency sharing models extend to 4–6 weeks when discovery, sandbox testing, and sharing-rule configuration are included. The longest planning step is designing the Referral__c and Service_Plan__c custom objects and getting multi-agency sharing rules validated by your Salesforce admin.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Virtual Case Management.
Land in Salesforce Sales Cloud, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day