CRM migration
Field-level mapping, validation, and rollback between Workbooks and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.
Workbooks
Source
Salesforce Sales Cloud
Destination
Compatibility
12 of 15
objects map 1:1 between Workbooks and Salesforce Sales Cloud.
Complexity
BStandard
Timeline
4-8 weeks
Overview
Moving from Workbooks to Salesforce is a structural migration that separates Workbooks' combined Organisation-Person model into Salesforce's Account-Contact hierarchy and splits the Workbooks Lead record type across Salesforce's Lead and Contact objects. Workbooks' native quotation and invoice handling maps to Salesforce Quote and Order, though these objects require the Workbooks Business tier on the source side. We extract via the Workbooks API and MS Excel export layer, resolve all Organisation-to-Account and Person-to-Contact lookups before insert, and use the Salesforce Bulk API 2.0 for large activity histories. Workbooks Workflows and Automation rules do not migrate as code; we deliver a written inventory for the customer's admin to rebuild in Salesforce Flow. Sandbox validation, cutover delta syncing, and a one-week post-go-live hypercare window are standard scope.
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 Workbooks 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.
Workbooks
Organisation
Salesforce Sales Cloud
Account
1:1Workbooks Organisation records map to Salesforce Account. Organisation name becomes Account Name, address fields map to BillingAddress, industry classification maps to Industry, and any custom fields defined on Organisation map to equivalent custom Account fields. We use Organisation name and domain as a dedupe key during Account insert to prevent duplicate accounts from repeated exports. Account is the parent record; it must exist before any Contact import so that AccountId lookup is satisfied on insert.
Workbooks
Person
Salesforce Sales Cloud
Contact
1:1Workbooks Person records map to Salesforce Contact. The Organisation lookup field on Person resolves to the AccountId on the Contact during migration, preserving the company-contact link. Person name fields (first name, last name, title, phone, email) map to their Salesforce Contact equivalents. If the Person has no linked Organisation, the Contact is created without an AccountId and placed in a reconciliation queue for the customer's admin to assign after migration.
Workbooks
Lead
Salesforce Sales Cloud
Lead or Contact (split required)
1:manyWorkbooks Lead records hold pre-conversion prospect data with lead source, status, rating, and owner. We evaluate each Lead against the customer's criteria: Leads with clear buyer intent or existing Opportunity association map to Salesforce Contact attached to the relevant Account; unqualified Leads remain as Salesforce Lead records with lead source and rating preserved in custom fields. The split rule is defined during scoping based on the customer's Workbooks pipeline configuration. Original Workbooks Lead status is preserved in a custom field wb_original_lead_status__c on the destination record.
Workbooks
Opportunity
Salesforce Sales Cloud
Opportunity
1:1Workbooks Opportunities map to Salesforce Opportunity. Stage, probability, value, expected close date, owner, and related Organisation all migrate. We resolve the Organisation-to-AccountId reference during the Opportunity phase (Accounts must load first). Closed-Won and Closed-Lost reason fields from Workbooks custom properties map to Salesforce Loss Reason and Win Reason custom fields. Opportunity is the child of Account; AccountId must be resolved before Opportunity insert.
Workbooks
Opportunity Stage
Salesforce Sales Cloud
Opportunity Stage + Sales Process
lossyWorkbooks pipeline stages map to Salesforce Stage values on the Opportunity object. We pre-create a Sales Process in Salesforce that whitelists the relevant stage values for each Workbooks pipeline, and assign a Record Type per pipeline to scope page layouts and stage sets to specific lines of business. Stage probability percentages migrate from Workbooks to Salesforce StageProbability, rounded to the nearest integer allowed by Salesforce.
Workbooks
Case
Salesforce Sales Cloud
Case
1:1Workbooks Cases map to Salesforce Case if the destination Salesforce org includes Service Cloud or if the customer adds Service Cloud during migration. Case status, priority, description, assigned user, and related Organisation map to their Salesforce equivalents. Open cases and resolved cases both migrate; status mapping is configured during scoping against the customer's Workbooks case status values. Case activities (comments and internal notes) migrate as CaseComment records.
Workbooks
Quotation
Salesforce Sales Cloud
Quote
1:1Workbooks Quotations are only available on the CRM and CRM Pro tiers and above (Business tier required for full quoting). We verify the source subscription tier before including Quotations in the migration scope. Quotation headers (related Organisation, owner, validity date) map to Salesforce Quote fields. Line items (product, quantity, unit price, discount) map to QuoteLineItem records linked to the Quote. If the destination Salesforce org does not have Quotes enabled, quotation data migrates as Opportunity Product records instead.
Workbooks
Invoice
Salesforce Sales Cloud
Asset or custom Invoice object
1:1Workbooks Invoices are available only on the Business and Business Pro tiers. If the source subscription is on CRM or CRM Pro, Invoices do not exist in the export and are flagged as out-of-scope during scoping. When available, invoice headers, line items, payment status, and related Organisation map to Salesforce Asset records or a custom Invoice__c object depending on whether the destination org uses Salesforce Financial Services Cloud or a custom invoice schema.
Workbooks
Sales Order / Purchase Order
Salesforce Sales Cloud
Order
1:1Workbooks Sales Orders and Purchase Orders map to Salesforce Order records. Orders are tied to an Organisation and quotation. We extract order headers, line items, and status. If the destination Salesforce org does not have the Order object enabled, order data migrates as custom Order__c records with a note flagging the gap for the customer's admin. Order-to-invoice linkage is preserved as a reference field on the record.
Workbooks
Activity (calls, emails, meetings, tasks)
Salesforce Sales Cloud
Task, Event, EmailMessage
1:1Workbooks Activities represent logged calls, emails, meetings, and tasks linked to an Organisation or Person. We map call activities to Task with TaskSubtype=Call and CallDurationInSeconds in a custom field. Meeting activities map to Event with StartDateTime, EndDateTime, and Location preserved. Email activities map to Salesforce EmailMessage records linked to a Task for the activity timeline. All Activity records carry the original Workbooks timestamp to preserve timeline ordering. We use the Salesforce Bulk API 2.0 for large activity histories to avoid the silent record drops that CSV loaders produce at volume.
Workbooks
Campaign
Salesforce Sales Cloud
Campaign
1:1Workbooks Campaigns track marketing initiatives and associated leads. We extract campaign name, status, start and end dates, and associated lead memberships. Campaign Member data migrates as CampaignMember records linked to the relevant Salesforce Leads or Contacts. Campaign response data migrates as custom fields on Campaign to preserve historical response metrics without rebuilding the reporting model.
Workbooks
Custom Field (text, number, date, dropdown, checkbox)
Salesforce Sales Cloud
Custom Field (__c)
1:1Workbooks custom fields on Organisation, Person, Opportunity, Case, Quotation, Invoice, and Order objects map to Salesforce custom fields. Workbooks deployments vary significantly in which custom fields exist and what they are called; there is no unified schema export listing all custom fields across record types. We request read-only access to the source Workbooks account and enumerate custom fields per record type before writing the migration spec. Dropdown fields in Workbooks map to Salesforce picklist fields with the relevant values pre-populated in the destination schema.
Workbooks
Custom Field (file upload)
Salesforce Sales Cloud
ContentDocument / Attachment
lossyFile upload fields in Workbooks store attachments against a record. Binary files (PDFs, images, documents) are downloaded separately from the Workbooks export and re-attached to the destination record in Salesforce via the ContentDocumentLink object. We preserve the original file name and upload date. The customer confirms whether attachments are in scope during scoping, as large binary sets add extraction and upload time to the project.
Workbooks
Contract
Salesforce Sales Cloud
Contract
1:1Workbooks Contract records hold agreement details, related Organisation, start and end dates, and renewal terms on the CRM or Business tier. We extract contract metadata and any attached documents. Renewal reminder configuration is not a data field and does not migrate; we document the renewal terms and renewal reminder settings so the customer's Salesforce admin can configure Salesforce Contracts or a custom renewal reminder flow post-migration.
Workbooks
User / Owner
Salesforce Sales Cloud
User
1:1Workbooks Owners referenced on Organisation, Person, Opportunity, Case, Quotation, and Activity records map to Salesforce User by email address. We extract all distinct Owner references, match against the destination org's User table, and hold any unmatched owners in a reconciliation queue. The customer's Salesforce admin provisions missing Users before production migration begins, because OwnerId is a required reference on most standard objects.
| Workbooks | Salesforce Sales Cloud | Compatibility | |
|---|---|---|---|
| Organisation | Account1:1 | Fully supported | |
| Person | Contact1:1 | Fully supported | |
| Lead | Lead or Contact (split required)1:many | Fully supported | |
| Opportunity | Opportunity1:1 | Fully supported | |
| Opportunity Stage | Opportunity Stage + Sales Processlossy | Fully supported | |
| Case | Case1:1 | Fully supported | |
| Quotation | Quote1:1 | Fully supported | |
| Invoice | Asset or custom Invoice object1:1 | Fully supported | |
| Sales Order / Purchase Order | Order1:1 | Fully supported | |
| Activity (calls, emails, meetings, tasks) | Task, Event, EmailMessage1:1 | Fully supported | |
| Campaign | Campaign1:1 | Fully supported | |
| Custom Field (text, number, date, dropdown, checkbox) | Custom Field (__c)1:1 | Fully supported | |
| Custom Field (file upload) | ContentDocument / Attachmentlossy | Fully supported | |
| Contract | Contract1:1 | Fully supported | |
| User / Owner | 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.
Workbooks gotchas
Record save latency on large datasets
Custom Fields require manual field-level mapping
Quotation and Invoice exports require Business tier
iFrame custom fields export as URL strings only
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 scoping
We audit the source Workbooks account across tier (CRM/CRM Pro/Business/Business Pro), custom fields per record type, pipeline and stage configuration, active quotation and invoice records, case volume, activity history size, and any attached binary files. We verify the Workbooks subscription tier to confirm whether Quotations, Invoices, and Orders are in scope. We pair this with a Salesforce edition decision: Professional ($80/user) covers standard migrations without complex custom objects; Enterprise ($165/user) is required if the customer needs advanced Flow at scale, custom fiscal periods, or territory management; Unlimited ($330/user) only if 24x7 support and unlimited custom apps are required. The discovery output is a written migration scope document listing all objects in scope, out of scope, and requiring tier verification.
Schema design and Salesforce sandbox setup
We design the destination schema in Salesforce. This includes creating all custom fields (with Salesforce field types matched to Workbooks data types), picklist values migrated from Workbooks dropdown fields, Record Types and Sales Processes scoped to each Workbooks pipeline, and the Lead-Contact split rule defined against the customer's Workbooks Lead status matrix. For Workbooks custom objects, we pre-create equivalent Salesforce custom objects with __c API names matched to the source naming convention. Schema is deployed via Salesforce metadata API or change set into a Salesforce Sandbox first for validation before any production load begins.
Sandbox migration and customer reconciliation
We run a full migration into a Salesforce Sandbox (Full Copy or Partial Copy) using production-like data volume. The customer's RevOps or Salesforce admin reconciles record counts across all object types, spot-checks 25-50 random records against the Workbooks source data, and signs off the schema and mapping before production migration begins. Any field-level mapping corrections, picklist value gaps, and lookup resolution failures surface here. This step prevents corrections from happening in production, which would require a second data load.
Owner reconciliation and User provisioning
We extract every distinct Workbooks Owner referenced on Organisation, Person, Opportunity, Case, Quotation, and Activity records and match by email against the destination Salesforce org's User table. Owners without a matching Salesforce User are placed in a reconciliation queue. The customer's Salesforce admin provisions any missing Users (active or inactive depending on whether the original Workbooks user is still with the organisation). Migration cannot proceed past this step because OwnerId is a required reference on most standard Salesforce objects.
Production migration in dependency order
We run production migration in record-dependency order: Users (validated manually), Accounts (from Workbooks Organisations), Contacts (with AccountId resolved), Leads and the Lead-Contact split applied, Opportunities (with AccountId, OwnerId, and RecordTypeId resolved), Cases, Products and Pricebook entries (if migrating quoting), Quotes and QuoteLineItems, Orders, Activity history (Tasks, Events, EmailMessages via Bulk API 2.0), Custom Objects (last, because they may have lookups to standard objects). Each phase emits a row-count reconciliation report and a sample record validation before the next phase begins.
Cutover, validation, and Workflow handoff
We freeze Workbooks write access during the cutover window, run a final delta migration of any records created or modified during the migration window, then enable Salesforce as the system of record. We deliver the Workbooks Workflow and Automation inventory document listing every rule with its trigger, conditions, actions, and a recommended Salesforce Flow equivalent. We do not rebuild Workbooks Workflows as Salesforce Flow inside the migration scope. We support a one-week hypercare window where we resolve any record linkage issues, lookup gaps, or data quality flags raised by the customer's sales and operations teams during their first week in Salesforce.
Platform deep dives
Workbooks
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 Workbooks 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
Workbooks: Workbooks imposes rate limits and result-set size caps. Excessive calls are throttled by being delayed or redirected via a delaying URL; clients are expected to follow these redirects as normal operation. Specific request-per-minute thresholds are not publicly published..
Data volume sensitivity
Workbooks exposes a bulk API — large-volume migrations stream efficiently.
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 Workbooks to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Workbooks 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 Workbooks
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.