CRM migration
Field-level mapping, validation, and rollback between Results and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.
Results
Source
Salesforce Sales Cloud
Destination
Compatibility
13 of 18
objects map 1:1 between Results and Salesforce Sales Cloud.
Complexity
BStandard
Timeline
4-6 weeks
Overview
Moving from Results to Salesforce Sales Cloud is a platform migration with limited publicly documented schema on the source side, requiring direct verification of export capabilities during scoping. Results supports Contacts, Companies, Deals, Pipelines, Activities, Custom Fields, and Attachments as core objects, but its API surface, rate limits, and field types must be confirmed against the customer's specific instance before field-level mapping is locked. We extract via the Results API or supported export format, transform data to Salesforce's typed schema, and load through the Bulk API 2.0 with parent-record lookup resolution for Activities. Workflows, automation rules, and custom-built integrations do not migrate as code; we deliver a written inventory for the customer's admin to rebuild in Salesforce Flow. We flag any Results-specific data (legacy calculated fields, restricted exports, or non-standard attachments) during scoping and resolve them before production migration begins.
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 Results 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.
Results
Contact
Salesforce Sales Cloud
Lead or Contact (split required)
1:manyResults Contacts without a Company association or in a pre-qualification stage map to Salesforce Lead. Results Contacts attached to a Company and marked as active buyers map to Salesforce Contact tied to an Account. We compute the split during scoping based on the customer's Results instance configuration, apply it as the first transform during migration, and preserve the original Results contact status in a custom field results_contact_status__c on both Lead and Contact for audit trail integrity.
Results
Company
Salesforce Sales Cloud
Account
1:1Results Company records map directly to Salesforce Account. The Company domain or website field becomes the Account's Website field and is used as the dedupe key during import. Account is created before any Contact import so that the AccountId Lookup relationship is satisfied at the moment of Contact insert.
Results
Deal
Salesforce Sales Cloud
Opportunity
1:1Results Deals map to Salesforce Opportunity. The Results deal stage maps to Salesforce StageName, and the pipeline assignment maps to a Salesforce Sales Process or Record Type that we configure before migration. Deal value, close date, and owner migrate directly. Any Results custom deal fields map to custom Opportunity fields created in the destination org.
Results
Deal Stage
Salesforce Sales Cloud
Opportunity Stage
lossyEach Results pipeline becomes a Salesforce Record Type with a corresponding Sales Process that whitelists the relevant stage values. Stage probability percentages migrate from Results to Salesforce StageProbability, rounded to the nearest integer allowed by the platform.
Results
Pipeline
Salesforce Sales Cloud
Record Type + Sales Process
lossyResults pipelines map to Salesforce Record Types on Opportunity. Each Record Type gets its own Page Layout and Sales Process so that stage values remain scoped per line of business. If Results supports multiple pipelines, each maps to a separate Record Type.
Results
Product
Salesforce Sales Cloud
Product2
1:1Results Products map to Salesforce Product2 records with Standard Price Book entries created during import. Product code or SKU migrates to ProductCode on Product2.
Results
Line Item
Salesforce Sales Cloud
OpportunityLineItem
1:1Results Line Items map to Salesforce OpportunityLineItem. We resolve the Pricebook2 reference, the Product2 reference, and the parent Opportunity at migration time. Quantity, UnitPrice, and TotalPrice migrate directly. If Results supports bundle or sub-line structures, we flatten them per the customer's preferred Salesforce data model.
Results
Owner
Salesforce Sales Cloud
User
1:1Results Owners map to Salesforce User records by email match. Any Results Owner without a matching Salesforce User is held in a reconciliation queue for the customer's admin to provision before record import resumes. Inactive owners receive an inactive User with the correct email to preserve historical assignment.
Results
Engagement: Email
Salesforce Sales Cloud
EmailMessage + Task
1:1Results email engagements migrate to Salesforce EmailMessage records (email content) linked to an Activity Task record (activity timeline entry). The WhoId on Task points to the Lead or Contact; WhatId points to the related Opportunity or Account. Email body and headers preserve with original timestamp.
Results
Engagement: Call
Salesforce Sales Cloud
Task (TaskSubtype = Call)
1:1Results call engagements map to Salesforce Task with TaskSubtype = Call. Call disposition, duration, and any recording URL transfer to custom Task fields. Activity timeline ordering is preserved by setting ActivityDate to the original Results timestamp.
Results
Engagement: Meeting
Salesforce Sales Cloud
Event
1:1Results meeting engagements map to Salesforce Event. StartDateTime, EndDateTime, and Location preserve. Attendee mapping links to EventRelation records pointing at the related Leads, Contacts, and Users. If Results stores meeting notes, those migrate as Task records linked to the Event.
Results
Engagement: Note
Salesforce Sales Cloud
Note
1:1Results Notes migrate to Salesforce Note records linked via ContentDocumentLink to the parent record (Lead, Contact, Account, Opportunity). Note body migrates as rich text. Any embedded images in Results notes are extracted and stored as separate ContentDocument records.
Results
Engagement: Task
Salesforce Sales Cloud
Task
1:1Results Task engagements map to Salesforce Task with Status, Priority, and ActivityDate preserved. Task assignment migrates by resolving the Results owner reference to Salesforce OwnerId via the User mapping. Open/closed status maps directly to Salesforce Task Status values.
Results
Ticket
Salesforce Sales Cloud
Case
1:1Results Tickets migrate to Salesforce Case if the destination org includes Service Cloud or if the customer enables Cases on their Sales Cloud org. Ticket pipeline becomes Case Record Type, ticket stages become Case Status values, and ticket comments migrate as CaseComments linked to the Case.
Results
Custom Field
Salesforce Sales Cloud
Custom Field
lossyResults custom fields map to Salesforce custom fields with equivalent data types. We verify field type compatibility during scoping (text vs. textarea, number vs. currency, date vs. datetime, single-select vs. picklist). Multi-select picklist values from Results become Salesforce multi-select picklists. Required field constraints on Results custom fields map to either required Salesforce fields or validation rules depending on the customer's preference.
Results
Custom Object
Salesforce Sales Cloud
Custom Object
1:1Results custom objects migrate to Salesforce custom objects of equivalent API name. We pre-create the destination schema in Salesforce before any data import, including all custom fields, lookup relationships to standard objects (Account, Contact, Opportunity), and validation rules. Custom object naming follows Salesforce __c suffix convention matched to the Results object API name.
Results
Attachment
Salesforce Sales Cloud
ContentDocument
1:1Results Attachments migrate to Salesforce ContentDocument records linked via ContentDocumentLink to the parent record (Contact, Account, Opportunity). We extract binary file content and metadata (filename, content type, size) and reconstruct them in Salesforce. If Results stores attachments inline within notes or activities, we extract and promote them to standalone ContentDocument records.
Results
Tag
Salesforce Sales Cloud
Multi-Select Picklist or Topic
lossyResults tags stored as multi-checkbox properties migrate to Salesforce multi-select picklist fields on the target object. Tags used for content classification migrate to Salesforce Topics with TopicAssignment records linked to the relevant object. The customer chooses the tag strategy during scoping based on reporting needs.
| Results | Salesforce Sales Cloud | Compatibility | |
|---|---|---|---|
| Contact | Lead or Contact (split required)1:many | Fully supported | |
| Company | Account1:1 | Fully supported | |
| Deal | Opportunity1:1 | Fully supported | |
| Deal Stage | Opportunity Stagelossy | Fully supported | |
| Pipeline | Record Type + Sales Processlossy | Fully supported | |
| Product | Product21:1 | Fully supported | |
| Line Item | OpportunityLineItem1:1 | Fully supported | |
| Owner | User1:1 | Fully supported | |
| Engagement: Email | EmailMessage + Task1:1 | Fully supported | |
| Engagement: Call | Task (TaskSubtype = Call)1:1 | Fully supported | |
| Engagement: Meeting | Event1:1 | Fully supported | |
| Engagement: Note | Note1:1 | Fully supported | |
| Engagement: Task | Task1:1 | Fully supported | |
| Ticket | Case1:1 | Fully supported | |
| Custom Field | Custom Fieldlossy | Fully supported | |
| Custom Object | Custom Object1:1 | Fully supported | |
| Attachment | ContentDocument1:1 | Fully supported | |
| Tag | Multi-Select Picklist or Topiclossy | 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.
Results gotchas
QuickBooks-linked records have dual sources of truth
Suite is not architected to scale beyond ~15 users / 15K contacts
No documented public REST API
Field Service photos and signatures require separate binary extraction
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 API verification
We audit the source Results instance across standard objects (Contacts, Companies, Deals, Pipelines, Activities), custom fields, custom objects, and any known integrations or restricted data. Because Results has limited public API documentation, we run a direct API probe against the customer's instance to confirm export endpoints, pagination behavior, field accessibility, and rate limits. The discovery output is a written migration scope with confirmed exportable objects, field-level mapping, and any fields requiring manual extraction workaround.
Schema design in Salesforce Sandbox
We design the destination schema in a Salesforce Sandbox. This includes provisioning custom objects (with __c API names matched to Results object names where applicable), custom fields (with Salesforce field types mapped from Results field types), Record Types (one per Results pipeline), Sales Processes (stage whitelist per Record Type), Page Layouts, and the Lead-Contact split rule based on the customer's Results contact model. Schema is deployed via metadata API or change set into the Sandbox first for validation before any data moves.
Sandbox migration pilot and reconciliation
We run a full migration into the Salesforce Sandbox using production-like data volume extracted from Results. The customer's RevOps or admin lead reconciles record counts (Contacts in, Leads in, Accounts in, Opportunities in, Activities in), spot-checks 25-50 random records against the Results source, and signs off the schema and mapping before production migration begins. Any mapping corrections happen in the Sandbox, not in production.
Owner reconciliation and User provisioning
We extract every distinct Results Owner referenced on Contact, Company, Deal, and Engagement records and match by email against the Salesforce destination org's User table. Owners without a matching User go to a reconciliation queue. The customer's Salesforce admin provisions any missing Users (active or inactive depending on whether the original Results user is still active). Migration cannot proceed past this step because OwnerId references are required on most standard objects.
Production migration in dependency order
We run production migration in record-dependency order: Users (manual provisioning, validated), Accounts (from Results Companies), Contacts (with AccountId resolved and Lead-Contact split applied), Opportunities (with AccountId, OwnerId, and RecordTypeId resolved), Products and Pricebook entries, Line Items, Activity history (Tasks, Events, EmailMessages via Bulk API 2.0), Notes, Attachments (via ContentVersion), Custom Objects (last, because they often have lookups to standard objects), and finally Tags (as multi-select picklists or Topics). Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, validation, and automation handoff
We freeze Results writes during cutover, run a final delta migration of any records modified during the migration window, then enable Salesforce as the system of record. We deliver the Results automation inventory document to the customer's admin team. We support a one-week hypercare window where we resolve any reconciliation issues raised by the customer's team. Automation rebuild in Salesforce Flow, workflow reconstruction, and post-migration admin training are outside standard scope and are handled as separate engagements.
Platform deep dives
Results
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 Results 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
Results: Not publicly documented.
Data volume sensitivity
Results 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 Results to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Results 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 Results
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.