CRM migration
Field-level mapping, validation, and rollback between Exsalerate and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.
Exsalerate
Source
Salesforce Sales Cloud
Destination
Compatibility
8 of 12
objects map 1:1 between Exsalerate and Salesforce Sales Cloud.
Complexity
BStandard
Timeline
4-6 weeks
Overview
Moving from Exsalerate to Salesforce Sales Cloud is a structural migration that resolves a fundamentally different data philosophy. Exsalerate uses a flat, account-centric model with Opportunities tied directly to pipeline stages; Salesforce separates Leads from Contacts, Accounts from Opportunities, and Stages from Record Types. We resolve those relationships during scoping, preserving the WorkflowMax quote cross-reference that Exsalerate creates when importing WorkflowMax quotes as Opportunities. Exsalerate has no documented public API, so our extraction path relies on CSV exports and, where available, direct database access. We transform and normalise all data before loading into Salesforce via the Bulk API 2.0. WorkflowMax and Xero integration configurations, Exsalerate automations, and custom dashboard layouts do not migrate; we deliver a written inventory of these for the customer's admin to rebuild in Salesforce.
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 Exsalerate 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.
Exsalerate
Account
Salesforce Sales Cloud
Account
1:1Exsalerate Account records map directly to Salesforce Account. Account Name, Billing Address, Phone, Website, Industry, and custom fields migrate as field-to-field mappings. Exsalerate's account-centric model means Account is created before any Contact or Opportunity import so that the lookup relationship is satisfied at the moment of child record insert. We use Account Name as the dedupe key during import.
Exsalerate
Contact
Salesforce Sales Cloud
Contact
1:1Exsalerate Contact records map to Salesforce Contact with AccountId resolved from the parent Account lookup. We preserve FirstName, LastName, Email, Phone, Title, and custom fields. Duplicate detection runs on Email as the primary key before insert. If a Contact in Exsalerate has no associated Account, we create a placeholder Account or flag for the customer's admin to resolve before migration.
Exsalerate
Pipeline
Salesforce Sales Cloud
Record Type + Sales Process
lossyEach Exsalerate Pipeline becomes a Salesforce Record Type on Opportunity plus a corresponding Sales Process. Pipeline name becomes the Record Type label, and the pipeline's stage sequence becomes the Sales Process stage order. We configure these in Salesforce metadata before data import so that Opportunities land in the correct pipeline context immediately on insert.
Exsalerate
Pipeline Stage
Salesforce Sales Cloud
Opportunity Stage
lossyExsalerate stage labels (for example, 'Qualified', 'Proposal Sent', 'Negotiation', 'Closed Won') migrate to Salesforce Opportunity Stage picklist values. Stage order and colour-coding metadata from Exsalerate are preserved in a custom field exsalerate_stage_colour__c on Opportunity. We add the stages to the relevant Sales Process whitelist during pre-migration configuration.
Exsalerate
Opportunity
Salesforce Sales Cloud
Opportunity
1:1Exsalerate Opportunity records map to Salesforce Opportunity with AccountId, OwnerId, and RecordTypeId resolved at migration time. Opportunity Name, Amount, CloseDate, StageName, Description, and custom fields migrate directly. If the Opportunity originated as a WorkflowMax quote import, we detect the WorkflowMax cross-reference field and populate the custom exsalerate_workflowmax_ref__c field on the Salesforce Opportunity.
Exsalerate
To-Do Item (Activity Tile)
Salesforce Sales Cloud
Task
1:1Exsalerate to-do items map to Salesforce Task. Due date, status (Open, Completed), subject, and body migrate as standard fields. The Exsalerate tile colour value (used for urgency and context encoding) migrates to a custom picklist field exsalerate_tile_colour__c on Task. We verify that the destination Salesforce org has custom field access on Task during scoping since not all editions expose Task custom fields at no extra cost.
Exsalerate
Email Activity
Salesforce Sales Cloud
EmailMessage + Task
1:1Exsalerate email history associated to Accounts and Contacts migrates to Salesforce EmailMessage records (the email content and headers) linked to an Activity Task record (the timeline entry). Subject, Body, FromAddress, ToAddress, and MessageDate transfer directly. The WhoId on Task points to the related Contact or Lead; WhatId points to the related Account or Opportunity. Attachments migrate as ContentDocument records linked via ContentDocumentLink.
Exsalerate
User / Owner
Salesforce Sales Cloud
User
1:1Exsalerate user accounts map to Salesforce User records by email address match. We build a user mapping table during scoping. Inactive Exsalerate users are flagged in the mapping table and assigned to a placeholder Salesforce User (the customer's admin or a system integration user) during migration. Any Exsalerate user without an email match in Salesforce goes to a reconciliation queue for admin provisioning before production migration.
Exsalerate
Custom Fields
Salesforce Sales Cloud
Custom Fields
lossyCustom fields on Exsalerate Accounts, Contacts, and Opportunities migrate to Salesforce custom fields with type-aware mapping: picklist values become Salesforce picklists, dates normalise to YYYY-MM-DD, numeric precision is preserved. We pre-create the Salesforce custom field schema (with __c API names) before any data import. Any Exsalerate custom field that has no Salesforce equivalent (rare, given Salesforce's flexible schema) is documented and either dropped or mapped to a text area field with an annotation in the migration log.
Exsalerate
WorkflowMax Quote (Opportunity import)
Salesforce Sales Cloud
Custom Field on Opportunity
1:1Exsalerate supports importing WorkflowMax quotes as Opportunities, creating a cross-reference that is stored as a custom attribute on the Opportunity rather than a standard lookup field. We detect this attribute during extraction by inspecting all Opportunity records for WorkflowMax identifiers. The reference value migrates to a custom text field exsalerate_workflowmax_ref__c on the Salesforce Opportunity, and we flag the field in the handoff document so the customer's admin can re-establish the WorkflowMax connection manually in Salesforce if needed.
Exsalerate
Xero Integration (contact reference)
Salesforce Sales Cloud
Custom Field
lossyExsalerate's Xero integration stores contact and account cross-references that may exist as custom fields or notes within Exsalerate. We extract any Xero identifiers found in custom fields or note bodies and store them in a custom field exsalerate_xero_ref__c on the relevant Salesforce record. The customer's admin rebuilds the Xero-Salesforce connection using the Salesforce Xero AppExchange connector post-migration.
Exsalerate
Activity History (combined)
Salesforce Sales Cloud
Task + Event + EmailMessage
1:1Exsalerate email activities, meetings (if captured), and to-do completions are loaded into Salesforce as Task, Event, and EmailMessage records in dependency order: Accounts first, then Contacts, then Activities linked to the resolved parent records. Activity timestamps are preserved by setting ActivityDate on Task and StartDateTime/EndDateTime on Event to the original Exsalerate values. Large activity histories (over 50,000 records) use Salesforce Bulk API 2.0 with chunking and exponential backoff on rate limit responses.
| Exsalerate | Salesforce Sales Cloud | Compatibility | |
|---|---|---|---|
| Account | Account1:1 | Fully supported | |
| Contact | Contact1:1 | Fully supported | |
| Pipeline | Record Type + Sales Processlossy | Fully supported | |
| Pipeline Stage | Opportunity Stagelossy | Fully supported | |
| Opportunity | Opportunity1:1 | Fully supported | |
| To-Do Item (Activity Tile) | Task1:1 | Fully supported | |
| Email Activity | EmailMessage + Task1:1 | Fully supported | |
| User / Owner | User1:1 | Fully supported | |
| Custom Fields | Custom Fieldslossy | Mapping required | |
| WorkflowMax Quote (Opportunity import) | Custom Field on Opportunity1:1 | Fully supported | |
| Xero Integration (contact reference) | Custom Fieldlossy | Fully supported | |
| Activity History (combined) | Task + Event + EmailMessage1: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.
Exsalerate gotchas
WorkflowMax quote-to-opportunity linkage is not a standard CRM field
Exsalerate has no publicly documented bulk export or API endpoint
Colour-coded to-do tiles do not map to standard CRM task priorities
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 export method confirmation
We audit the source Exsalerate deployment across all tiers (Starter, Professional, Enterprise), identifying object availability (Accounts, Contacts, Pipelines, Stages, Opportunities, To-Do Items, Email Activities), custom field definitions, and WorkflowMax quote imports. The critical step is confirming the available export mechanism: CSV export from the Professional/Enterprise UI, or direct database access if the customer hosts Exsalerate on their own infrastructure. If neither mechanism is available, we flag the migration as blocked and recommend the customer contact Exsalerate support for a data export request before scoping proceeds.
Salesforce schema design and Record Type configuration
We design the destination Salesforce schema based on the Exsalerate data model audit. This includes provisioning custom fields on Account, Contact, and Opportunity (with __c API names matched to Exsalerate field labels where possible), configuring Record Types and Sales Processes for each Exsalerate Pipeline, adding stage values to the Opportunity Stage picklist with colour metadata preserved in the exsalerate_stage_colour__c field, and creating the exsalerate_workflowmax_ref__c and exsalerate_xero_ref__c custom fields for cross-reference preservation. Schema deploys to a Salesforce Sandbox first for validation before any data loads.
CSV extraction, reconciliation, and transformation
We extract all available Exsalerate objects via CSV export or direct database query. Multi-file exports are reconciled by matching cross-object identifiers (for example, linking Contacts to Accounts via the Exsalerate account_id foreign key embedded in the Contact export). We transform data types: Exsalerate date formats normalise to YYYY-MM-DD, picklist values are validated against the destination Salesforce picklist, and numeric precision is preserved. Any Exsalerate custom field without a Salesforce equivalent is documented with a transformation note. The extraction output is a set of clean CSV files ready for Salesforce Bulk API ingestion.
Sandbox migration and reconciliation
We run a full migration into a Salesforce Sandbox (Full Copy or Developer Pro) using production-equivalent data volume. The customer's RevOps lead reviews a reconciliation report comparing Exsalerate source record counts against Salesforce destination record counts for each object, spot-checks 25-50 records for field-level accuracy, and validates the Opportunity Record Type and stage assignments. Any mapping corrections are documented and applied to the production migration plan. Sign-off from the RevOps lead is required before we proceed to production.
Owner reconciliation and User provisioning
We extract every distinct Exsalerate user referenced on Account, Contact, Opportunity, and Activity records and match by email against the Salesforce destination org's User table. Users without a matching Salesforce User go to a reconciliation queue. The customer's Salesforce admin provisions missing Users and confirms whether inactive Exsalerate users (former employees) should be mapped to an inactive Salesforce User or excluded from migration. This step is a blocker for production migration because OwnerId is a required field on most standard objects.
Production migration in dependency order
We run production migration in record-dependency order: Accounts first, Contacts second (with AccountId resolved), Users (validated by admin), Opportunities third (with AccountId, OwnerId, RecordTypeId, and WorkflowMax reference fields resolved), Tasks and EmailMessage records fourth (with Bulk API 2.0 for histories over 50,000 records), and Custom Object data last. Each phase emits a row-count reconciliation report before the next phase begins. Exsalerate write access is suspended during the production migration window.
Cutover, validation, and integration rebuild handoff
We run a final delta migration for any records modified during the cutover window, then enable Salesforce as the system of record. We deliver the Integration Rebuild Handoff document covering the Xero-Salesforce connector installation steps and the WorkflowMax-Salesforce reconnection procedure, plus a written inventory of Exsalerate automations and pipeline dashboard layouts for the customer's admin to rebuild in Salesforce Flow and Reports. We support a one-week hypercare window for reconciliation issues. We do not rebuild Exsalerate automations as Salesforce Flow within the migration scope; that work is documented separately for the customer's admin or a Salesforce partner.
Platform deep dives
Exsalerate
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 Exsalerate 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
Exsalerate: Not publicly documented..
Data volume sensitivity
Exsalerate 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 Exsalerate to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Exsalerate 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 Exsalerate
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.