CRM migration
Field-level mapping, validation, and rollback between Capsule CRM and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.
Capsule CRM
Source
Salesforce Sales Cloud
Destination
Compatibility
11 of 15
objects map 1:1 between Capsule CRM and Salesforce Sales Cloud.
Complexity
BStandard
Timeline
2-4 weeks
Overview
Moving from Capsule CRM to Salesforce is a structural migration that reflects how teams outgrow Capsule's feature ceiling as they scale. Capsule's unified Party object (covering both individual contacts and organizations) splits into separate Contact and Account records in Salesforce, with the original Party type preserved as a custom field for reporting continuity. Opportunities map to Salesforce Opportunities with pipeline stages converted to Record Types and Sales Processes. Cases from Capsule migrate as Cases if the destination includes Service Cloud, or as Tasks or custom objects otherwise. Capsule's custom fields are not embedded in entity records by default — their definitions must be fetched separately from the /fields/definitions endpoint before values can be correctly typed. Activity history (calls, emails, meetings, notes) migrates via the Salesforce Bulk API 2.0 with parent-record resolution so the timeline attaches to the correct Contact, Account, and Opportunity. Capsule Workflow Automations do not migrate as code; we deliver a written inventory of each automation 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 Capsule CRM 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.
Capsule CRM
Party (person)
Salesforce Sales Cloud
Contact
1:1Capsule Party records with type=person map to Salesforce Contact. The contact's name fields map to FirstName and LastName; email maps to Email; phone maps to Phone; address fields map to MailingStreet, MailingCity, MailingState, and MailingPostalCode. The original Capsule Party ID is preserved in a custom field capsule_party_id__c for audit and cross-reference.
Capsule CRM
Party (organisation)
Salesforce Sales Cloud
Account
1:1Capsule Party records with type=organisation map to Salesforce Account. Organisation name maps to Account Name; website maps to Website; phone maps to Phone; address fields map to BillingStreet, BillingCity, BillingState, and BillingPostalCode. We create Account records before Contact records so that AccountId can be resolved on each Contact at insert time.
Capsule CRM
Party Relationship
Salesforce Sales Cloud
Contact (under Account)
1:1Capsule relationships between a person Party and an organisation Party indicate that the contact works at or is associated with the organisation. We resolve this by linking the Contact's AccountId to the mapped Account record. Secondary relationships (board member, investor, contractor) are preserved in a custom multi-select picklist on Contact.
Capsule CRM
Opportunity
Salesforce Sales Cloud
Opportunity
1:1Capsule Opportunities map to Salesforce Opportunity with name, value, currency, expected close date, owner, probability, and pipeline stage preserved. The Capsule pipeline name maps to a Salesforce Record Type or Sales Process, and the Capsule stage name maps to Salesforce StageName. Probability percentages migrate from Capsule to Salesforce StageProbability.
Capsule CRM
Opportunity Pipeline
Salesforce Sales Cloud
Opportunity Record Type + Sales Process
lossyEach Capsule pipeline becomes a Salesforce Record Type on Opportunity with a corresponding Sales Process that whitelists the relevant stage values. For accounts with multiple Capsule pipelines, we create one Record Type per pipeline so that stage values stay scoped per line of business. Stage probability percentages migrate from Capsule to Salesforce StageProbability with rounding to the nearest allowed integer.
Capsule CRM
Case
Salesforce Sales Cloud
Case (or custom object)
1:1Capsule Cases map to Salesforce Case if the destination org includes Service Cloud. Case status, priority, assignee, description, and linked Party reference migrate. If the destination does not include Service Cloud, we map Cases to a custom Case__c object with the same field structure. Conversation history from Capsule Cases migrates as Task records linked to the Case or custom object.
Capsule CRM
Project
Salesforce Sales Cloud
Task (or custom Project object)
1:manyCapsule Projects are available on Starter and above plans. We migrate project name, status, and milestones. Project milestones map to Salesforce Tasks with a custom milestone_flag__c checkbox set to true and the parent Project name in a custom project_name__c field. If the destination Salesforce org has high project management volume, we offer a custom Project__c object as the parent instead of using Tasks.
Capsule CRM
Custom Field Definition (parties, opportunities, cases)
Salesforce Sales Cloud
Custom Field (Contact, Account, Opportunity, Case)
lossyCapsule custom fields are created via Capsule's data-tag system and are not returned with entity records by default. We query /fields/definitions for each entity type before pulling record data, resolve list field options, and apply the correct type casting (text, date, numeric, list) to values. Text fields map to Salesforce Text; date fields map to Date; numeric fields map to Number; list fields map to Picklist or Multi-Select Picklist depending on whether Capsule allows multiple selections.
Capsule CRM
Tag
Salesforce Sales Cloud
Custom Label field or Topic
lossyCapsule tags are flat labels applied to Parties, Opportunities, and Cases. We map tag names to a custom Tags__c multi-select picklist on the relevant Salesforce object. Where the customer uses tags for content classification, we offer Topic and TopicAssignment as an alternative with a topic naming strategy agreed during scoping.
Capsule CRM
Activity: Email
Salesforce Sales Cloud
EmailMessage + Task
1:1Capsule email activities migrate to Salesforce EmailMessage records (the email content) linked to a Task record (the activity timeline entry). The WhoId on Task points to the Contact or Lead; the WhatId points to the related Opportunity, Account, or Case. Direction (inbound/outbound) is preserved in a custom field.
Capsule CRM
Activity: Call
Salesforce Sales Cloud
Task (TaskSubtype = Call)
1:1Capsule call activities map to Salesforce Task with TaskSubtype set to Call. Call disposition, duration (stored in seconds), and any notes migrate to custom Task fields. Activity timestamp becomes ActivityDate on the Salesforce Task.
Capsule CRM
Activity: Meeting
Salesforce Sales Cloud
Event
1:1Capsule meeting activities map to Salesforce Event with StartDateTime, EndDateTime, and Location preserved. Attendee mapping links to EventRelation records pointing at the relevant Contacts and Users. The Capsule meeting description migrates to Event Description.
Capsule CRM
Activity: Note
Salesforce Sales Cloud
Note
1:1Capsule note activities migrate to Salesforce Note records linked via ContentDocumentLink to the parent Contact, Account, Opportunity, or Case. Note body migrates as plain text. If Capsule notes contain attachments, those migrate as ContentDocument records linked to the same parent.
Capsule CRM
Task
Salesforce Sales Cloud
Task
1:1Capsule Tasks (standalone tasks not attached to an activity) map to Salesforce Task. Due date, assignee, status, and description preserve. Task assignment migrates by resolving the Capsule user reference to the Salesforce User mapping established during owner reconciliation.
Capsule CRM
User / Team Member
Salesforce Sales Cloud
User
1:1Capsule users map to Salesforce User records by email address match. Any Capsule user without a matching Salesforce User is held in a reconciliation queue for the customer's admin to provision before record import resumes. Active versus inactive status is preserved in a custom field.
| Capsule CRM | Salesforce Sales Cloud | Compatibility | |
|---|---|---|---|
| Party (person) | Contact1:1 | Fully supported | |
| Party (organisation) | Account1:1 | Fully supported | |
| Party Relationship | Contact (under Account)1:1 | Fully supported | |
| Opportunity | Opportunity1:1 | Fully supported | |
| Opportunity Pipeline | Opportunity Record Type + Sales Processlossy | Fully supported | |
| Case | Case (or custom object)1:1 | Fully supported | |
| Project | Task (or custom Project object)1:many | Fully supported | |
| Custom Field Definition (parties, opportunities, cases) | Custom Field (Contact, Account, Opportunity, Case)lossy | Fully supported | |
| Tag | Custom Label field or Topiclossy | Fully supported | |
| Activity: Email | EmailMessage + Task1:1 | Fully supported | |
| Activity: Call | Task (TaskSubtype = Call)1:1 | Fully supported | |
| Activity: Meeting | Event1:1 | Fully supported | |
| Activity: Note | Note1:1 | Fully supported | |
| Task | Task1:1 | Fully supported | |
| User / Team Member | User1: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.
Capsule CRM gotchas
Capsule API rate limit is 4,000 requests per window
Free plan caps at 250 contacts and 2 users
Custom fields require separate field-definition API calls
Deleted records require a separate endpoint and are not returned in standard lists
Projects and Workflow Automations are gated by plan tier
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 plan tier verification
We audit the Capsule account across plan tier (Free/Starter/Growth/Advanced/Ultimate), record counts for Parties, Opportunities, Cases, and Activities, custom field definitions per entity type, pipeline and stage configuration, active Workflow Automations, and any Project or Case usage. We verify the Capsule plan tier during scoping because the Free plan caps at 250 contacts and 2 users, which determines whether the account is migration-eligible at its current tier. We pair this with a Salesforce edition review: Essentials ($25/user) for small teams, Professional ($80/user) for most migrations, Enterprise ($165/user) if custom objects at scale or record-triggered Flow are required.
Field definition extraction and destination schema design
We query Capsule's /fields/definitions endpoint for parties, opportunities, and cases to capture all custom field definitions before pulling any record data. We resolve list field options and apply type casting (text, date, numeric, picklist). We then design the Salesforce destination schema in a Sandbox org: Account and Contact objects from Capsule Parties, Opportunity Record Types and Sales Processes from Capsule pipelines, Case or custom Case__c object for Capsule Cases, and all custom fields with Salesforce field types matched to the resolved Capsule types. Schema is validated in Sandbox before any production migration begins.
Owner reconciliation and User provisioning
We extract every distinct Capsule user referenced on Party, Opportunity, Case, and Task records and match by email against the Salesforce destination org's User table. Any Capsule user without a matching Salesforce User is placed in a reconciliation queue. The customer's Salesforce admin provisions the missing Users and confirms their active or inactive status. OwnerId references on Opportunity, Case, and Task require resolved User records before those objects can import. This step gates all downstream record imports.
Sandbox migration and reconciliation
We run a full migration into a Salesforce Sandbox using production-like data volume. The customer's RevOps lead reviews record counts (Accounts in, Contacts in, Opportunities in, Cases in, Activities in), spot-checks 25-50 random records against the Capsule source for field-level accuracy, and validates that related records (Contacts under Accounts, Opportunities under Accounts, Cases under Accounts) are correctly linked. Any mapping corrections are applied in Sandbox before the production migration begins. The customer signs off the Sandbox migration before we schedule the production window.
Production migration in dependency order
We run production migration in record-dependency order: Accounts (from Capsule Organisation Parties), Contacts (with AccountId resolved from the linked Organisation Party), Opportunities (with AccountId, OwnerId, and RecordTypeId resolved), Cases (with AccountId and ContactId resolved), Activity history (Tasks, Events, EmailMessages, Notes via Bulk API 2.0), and Custom Field values (appended after the base object import). Each phase emits a row-count reconciliation report before the next phase begins. We freeze Capsule writes during the production migration window.
Cutover, delta sync, and Workflow handoff
We run a final delta migration to capture any records created or modified during the production migration window. We then enable Salesforce as the system of record and deliver a Workflow and Automation Inventory document listing every Capsule Workflow Automation with its trigger, conditions, actions, and a recommended Salesforce Flow equivalent. We do not rebuild Capsule Workflow Automations as Salesforce Flow inside the migration scope; that is a separate engagement. We offer a one-week hypercare window for reconciliation issues raised by the customer's team.
Platform deep dives
Capsule CRM
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 Capsule CRM 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
Capsule CRM: 4,000 requests per rate limit window; reset time in X-RateLimit-Reset header.
Data volume sensitivity
Capsule CRM 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 Capsule CRM to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Capsule CRM 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 Capsule CRM
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.