CRM migration
Field-level mapping, validation, and rollback between SoulCRM and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.
SoulCRM
Source
Salesforce Sales Cloud
Destination
Compatibility
9 of 12
objects map 1:1 between SoulCRM and Salesforce Sales Cloud.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from SoulCRM to Salesforce Sales Cloud requires a CSV-first migration strategy because SoulCRM does not publish public API documentation and no programmatic export mechanism was found during research. We extract Leads, Contacts, Companies, Deals, and Activities from SoulCRM via CSV, normalize the field headers against SoulCRM's module schemas, and ingest into Salesforce using the Bulk API 2.0 with batch chunking and OwnerId lookup resolution. SoulCRM's India-specific data model (GST identifiers, regional segments, INR pricing fields) requires explicit custom field mapping because these patterns have no native Salesforce equivalent. We sequence the migration as Companies first, then Contacts, then Deals, then Activity history last to satisfy Salesforce's foreign-key requirements. Workflows, automations, and marketing campaign memberships do not migrate as code; we deliver a written inventory of these for the customer's admin to rebuild in Salesforce Flow.
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 SoulCRM 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.
SoulCRM
Company
Salesforce Sales Cloud
Account
1:1SoulCRM Company records map directly to Salesforce Account. SoulCRM's company_name becomes Account Name; phone and email fields map to standard Account fields. Regional segment data from SoulCRM custom fields (state, city, territory) become Salesforce custom fields on Account. Company is imported first because Contacts and Deals both reference it as a foreign key. SoulCRM does not distinguish between business Accounts and individual consumers, so no Person Account split is required unless the customer's data includes consumer records.
SoulCRM
Contact
Salesforce Sales Cloud
Contact
1:1SoulCRM Contact records map to Salesforce Contact with AccountId resolved to the migrated Account. SoulCRM's contact status (Active/Inactive) maps to a custom Contact field rather than the deprecated isDeleted pattern. GST-related contact fields (business GSTIN if applicable) migrate to a custom field on Contact. We deduplicate by email during import to avoid creating duplicate Contact records for customers who appear in multiple SoulCRM modules.
SoulCRM
Lead
Salesforce Sales Cloud
Lead
1:1SoulCRM Lead records map to Salesforce Lead. Lead status from SoulCRM (New, Contacted, Qualified, Converted) maps to Salesforce Lead Status with a custom field soulcrm_original_status__c preserving the source value. Source attribution fields (Lead Source, Campaign Reference) migrate to standard Salesforce LeadSource and a custom campaign reference field.
SoulCRM
Deal
Salesforce Sales Cloud
Opportunity
1:1SoulCRM Deal records map to Salesforce Opportunity with AccountId and OwnerId resolved at migration time. Deal stage names map to Salesforce StageName values; stage probabilities are mapped explicitly per stage using a configuration table. Deal amount migrates to Amount; expected close date migrates to CloseDate. SoulCRM's custom deal fields (product line, deal type, regional segment) map to custom Opportunity fields.
SoulCRM
Deal Stage
Salesforce Sales Cloud
Opportunity Stage
lossyEach SoulCRM pipeline stage becomes a Salesforce StageName entry in a new Sales Process. We configure StageProbability values to match SoulCRM's probability percentages rounded to integers. The Sales Process is assigned to the Opportunity Record Type during migration. Any custom stage fields (stage_changed_date, stage_notes) migrate to custom Opportunity fields.
SoulCRM
Activity: Email
Salesforce Sales Cloud
EmailMessage + Task
1:1SoulCRM email activities migrate to Salesforce EmailMessage records (body content) linked to an Activity Task record. The WhoId points to the migrated Lead or Contact; WhatId points to the related Account or Opportunity. Email direction (Sent/Received) is preserved in a custom field. Email body content may require HTML normalization depending on the original encoding in SoulCRM exports.
SoulCRM
Activity: Call
Salesforce Sales Cloud
Task (TaskSubtype = Call)
1:1SoulCRM call logs migrate to Salesforce Task with TaskSubtype = Call. Call duration, disposition, and outcome fields from SoulCRM map to custom Task fields. ActivityDate is set to the original SoulCRM call timestamp to preserve timeline ordering. Call recording URLs (if stored as external links in SoulCRM) migrate to a custom field on the Task record.
SoulCRM
Activity: Task
Salesforce Sales Cloud
Task
1:1SoulCRM task activities map to Salesforce Task with Status, Priority, Subject, and ActivityDate preserved. Task assignment migrates by resolving SoulCRM owner references to Salesforce OwnerId via the User email lookup. Completed tasks retain their completion timestamp as ActivityDate.
SoulCRM
Attachment
Salesforce Sales Cloud
ContentDocument (via ContentVersion)
1:1SoulCRM file attachments linked to Contacts, Companies, or Deals migrate as Salesforce ContentVersion blobs uploaded to the destination org. Each file gets a ContentDocumentLink junction record pointing to the migrated parent record (Contact, Account, or Opportunity). Folder hierarchy from SoulCRM is not preserved; all files land in the destination record's file list without nested folders.
SoulCRM
Custom Field: GST Number
Salesforce Sales Cloud
Custom Field on Account/Contact
lossySoulCRM custom fields capturing India-specific GST identifiers require pre-creation of custom fields in Salesforce before migration begins. GSTIN format (15-character alphanumeric with state code, PAN, entity number, and checksum) can be validated using a Salesforce custom validation rule with a REGEX pattern. We recommend creating soulcrm_gstin__c on Account as a Text(15) field with the validation rule active after migration.
SoulCRM
Custom Field: Regional Segment
Salesforce Sales Cloud
Custom Field on Account/Opportunity
lossySoulCRM regional segment fields (state, city, sales territory, zone) map to Salesforce custom fields on Account or Opportunity. We recommend a Picklist or Multi-Select Picklist for territory and zone fields to enable reporting by region. If SoulCRM uses a hierarchical regional structure, we flatten it to a text or picklist field in Salesforce based on the customer's reporting requirements.
SoulCRM
Marketing Campaign
Salesforce Sales Cloud
Campaign
1:1SoulCRM Marketing Campaign records (name, type, start/end dates, budget) map to Salesforce Campaign. Campaign membership links (which Contacts or Leads were members of which campaigns) migrate as CampaignMember records. We resolve Contact and Lead references by email during the CampaignMember import phase. CampaignMember Status values (Sent, Responded, Converted) map from SoulCRM membership status fields.
| SoulCRM | Salesforce Sales Cloud | Compatibility | |
|---|---|---|---|
| Company | Account1:1 | Fully supported | |
| Contact | Contact1:1 | Fully supported | |
| Lead | Lead1:1 | Fully supported | |
| Deal | Opportunity1:1 | Fully supported | |
| Deal Stage | Opportunity Stagelossy | Fully supported | |
| Activity: Email | EmailMessage + Task1:1 | Fully supported | |
| Activity: Call | Task (TaskSubtype = Call)1:1 | Fully supported | |
| Activity: Task | Task1:1 | Fully supported | |
| Attachment | ContentDocument (via ContentVersion)1:1 | Fully supported | |
| Custom Field: GST Number | Custom Field on Account/Contactlossy | Fully supported | |
| Custom Field: Regional Segment | Custom Field on Account/Opportunitylossy | Fully supported | |
| Marketing Campaign | Campaign1: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.
SoulCRM gotchas
No public API documentation discovered in research
Minimum user requirements on paid tiers affect per-seat pricing
Absence from G2, Capterra, and TrustRadius review platforms
Limited documented integrations with third-party tools
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 CSV export preparation
We audit the SoulCRM account across all modules (Leads, Contacts, Companies, Deals, Activities, Campaigns, Attachments) and document the custom field inventory for each module. We identify all India-specific custom fields (GST numbers, regional segments, INR pricing fields) and confirm them with the customer. We request CSV exports from SoulCRM for each module, validate the field headers against the standard SoulCRM module schema, and flag any non-standard fields for customer confirmation. We also identify any SoulCRM integrations with external tools (telephony, email, website capture) that require re-establishment in Salesforce.
Schema design and Salesforce sandbox
We design the Salesforce destination schema in a Sandbox org. This includes provisioning custom fields (__c) for all SoulCRM custom fields including GSTIN validation rules and regional segment picklists, Record Types and Sales Processes for each SoulCRM pipeline, and Page Layouts per Record Type. We create a migration user with the required permissions (Modify All Data, API Enabled, Bulk API) and coordinate with the customer to identify which validation rules to disable during the migration window. Schema is deployed via change set or metadata API after customer sign-off.
CSV normalization and deduplication
We normalize CSV exports from SoulCRM before ingestion. This includes standardizing date formats to ISO 8601, normalizing phone numbers to E.164 format, encoding GSTIN values as plain text, splitting multi-value fields (regional segments) into delimited strings for Salesforce multi-select picklists, and deduplicating by email for Contact and Lead records. Any malformed records are flagged in a pre-flight report for customer correction before import begins.
Sandbox migration and reconciliation
We run a full migration into a Salesforce Sandbox (Full Copy or Partial Copy) using production-like data volume from the CSV exports. The customer reconciles record counts (Companies in, Contacts in, Deals in, Activities in), spot-checks 25-50 random records against the source CSV, and signs off the schema and mapping before production migration begins. Any mapping corrections, validation rule adjustments, or custom field additions happen in the Sandbox phase.
Production migration in dependency order
We run production migration in record-dependency order: Accounts (from SoulCRM Companies first), Contacts (with AccountId resolved), Leads (with the original SoulCRM status preserved), Opportunities (with AccountId, OwnerId, and RecordTypeId resolved), Activity history (Tasks, Events, EmailMessages via Bulk API 2.0), Campaign membership records (CampaignMembers after Leads and Contacts are resolved), Attachments (ContentVersion and ContentDocumentLink last). Each phase emits a row-count reconciliation report before the next phase begins. We freeze SoulCRM writes during the cutover window to prevent sync drift.
Cutover, validation, and automation inventory handoff
We run a final delta migration for any records modified in SoulCRM during the cutover window, then enable Salesforce as the system of record. We deliver a written inventory of SoulCRM workflows, automations, and campaign memberships that require rebuild in Salesforce Flow or Salesforce Campaign. We support a one-week hypercare window where we resolve any reconciliation issues raised by the customer's team. We do not rebuild SoulCRM automations as Salesforce Flow inside the migration scope; that is a separate engagement or an internal admin task.
Platform deep dives
SoulCRM
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 SoulCRM 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
SoulCRM: Not publicly documented.
Data volume sensitivity
SoulCRM 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 SoulCRM to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.
Walk through your SoulCRM 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 SoulCRM
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.