CRM migration

Migrate from Workbooks to Salesforce Sales Cloud

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 logo

Workbooks

Source

Salesforce Sales Cloud

Destination

Salesforce Sales Cloud logo

Compatibility

80%

12 of 15

objects map 1:1 between Workbooks and Salesforce Sales Cloud.

Complexity

BStandard

Timeline

4-8 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Workbooks logo

Workbooks

What's pushing teams away

  • Record save times degrade noticeably as the database grows, pushing teams with large transaction histories toward faster alternatives.
  • The UI has not kept pace with modern CRM expectations—younger sales staff find the navigation and visual design dated compared to HubSpot or Pipedrive.
  • Documentation and training materials are sparse, creating a steep onboarding curve for new users who are not power users.
  • Customisation options exist but the workflow for implementing them is non-obvious, leading to frustration when basic process changes require admin involvement.

Choosing

Salesforce Sales Cloud logo

Salesforce Sales Cloud

What's pulling them in

  • The AppExchange marketplace with 5,000+ prebuilt apps gives enterprises integrations for nearly every business workflow without custom development.
  • Native Einstein AI for lead scoring, opportunity insights, and predictive forecasting adds intelligence without a separate platform purchase.
  • Territory management, multi-currency support, and advanced forecasting satisfy the needs of complex B2B sales organizations with structured revenue teams.
  • Slack, Tableau, and CPQ are deeply integrated into the core platform, keeping the sales stack unified for teams already in the Salesforce ecosystem.
  • Organizations with a large, established Salesforce implementation choose it because switching costs — integrations, custom code, trained admins — are prohibitive.

Object mapping

How Workbooks objects map to Salesforce Sales Cloud

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

maps to

Salesforce Sales Cloud

Account

1:1
Fully supported

Workbooks 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

maps to

Salesforce Sales Cloud

Contact

1:1
Fully supported

Workbooks 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

maps to

Salesforce Sales Cloud

Lead or Contact (split required)

1:many
Fully supported

Workbooks 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

maps to

Salesforce Sales Cloud

Opportunity

1:1
Fully supported

Workbooks 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

maps to

Salesforce Sales Cloud

Opportunity Stage + Sales Process

lossy
Fully supported

Workbooks 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

maps to

Salesforce Sales Cloud

Case

1:1
Fully supported

Workbooks 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

maps to

Salesforce Sales Cloud

Quote

1:1
Fully supported

Workbooks 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

maps to

Salesforce Sales Cloud

Asset or custom Invoice object

1:1
Fully supported

Workbooks 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

maps to

Salesforce Sales Cloud

Order

1:1
Fully supported

Workbooks 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)

maps to

Salesforce Sales Cloud

Task, Event, EmailMessage

1:1
Fully supported

Workbooks 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

maps to

Salesforce Sales Cloud

Campaign

1:1
Fully supported

Workbooks 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)

maps to

Salesforce Sales Cloud

Custom Field (__c)

1:1
Fully supported

Workbooks 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)

maps to

Salesforce Sales Cloud

ContentDocument / Attachment

lossy
Fully supported

File 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

maps to

Salesforce Sales Cloud

Contract

1:1
Fully supported

Workbooks 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

maps to

Salesforce Sales Cloud

User

1:1
Fully supported

Workbooks 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.

Gotchas + challenges

What specifically takes care here

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 logo

Workbooks gotchas

High

Record save latency on large datasets

Medium

Custom Fields require manual field-level mapping

Medium

Quotation and Invoice exports require Business tier

Low

iFrame custom fields export as URL strings only

Salesforce Sales Cloud logo

Salesforce Sales Cloud gotchas

High

Workflow Rules and Process Builder are retired

High

Bulk API batch quota exhaustion during large imports

Medium

Storage overage billing is non-obvious

Medium

Account-Contact many-to-many relationship mapping

Low

Territory and team member import ordering dependencies

Pair-specific challenges

  • Quotation and Invoice objects require Workbooks Business tier

    Workbooks Quotations, Invoices, and Sales Orders are available only on the Business and Business Pro tiers. CRM and CRM Pro tier subscriptions do not expose these objects in the export, and the migration team will not find them in the source data. We confirm the source account tier during scoping and flag the absence of these objects as a migration scope item before work begins. If the customer expects invoice history in Salesforce but is on the CRM tier, the gap is documented and the customer decides whether to upgrade Workbooks first or accept the scope limitation.

  • Custom field enumeration requires read-only Workbooks access

    Workbooks does not publish a unified schema export listing every custom field across all record types. Each deployment varies in which custom fields exist, their data types, and their labels. We request read-only access to the source Workbooks account during scoping and enumerate custom fields per record type manually. This step is required before writing the migration spec; failing to enumerate custom fields silently drops bespoke data during export.

  • Salesforce storage limits require data volume assessment

    Salesforce calculates data storage based on total record count and file attachments. A Workbooks migration with large historical activity logs, invoice archives, and case histories can quickly consume gigabytes of Salesforce data storage. Reddit discussions on Salesforce data migration highlight that organisations frequently underestimate storage requirements during migration planning. We provide a storage impact estimate before migration and flag when the destination org's storage allocation may need to be expanded.

  • Salesforce validation rules and field-level security block imports

    Salesforce orgs commonly enforce validation rules such as required field formats, conditional required fields, and picklist value whitelists. Field-level security on the migration user's profile can also restrict writes to certain fields. These settings do not appear during standard CSV import and cause partial record rejections (5-30 percent on first attempt). We coordinate with the customer's Salesforce admin to temporarily disable blocking validation rules or grant the migration user Modify All Data access during the load window, then re-enable them after migration.

  • iFrame custom fields export as URL strings only

    Workbooks iFrame fields store a URL reference to an external page rendered inside the record. The embedded content does not export. We export the URL string so it can be preserved as a text field in Salesforce, but the rendered page content will not migrate automatically. If the embedded content is critical, the customer's admin must manually recreate the link or embed the external page using a Salesforce Visualforce page or Experience Cloud component after migration.

Migration approach

Six steps for a successful Workbooks to Salesforce Sales Cloud data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Context on both ends of the pair

Workbooks logo

Workbooks

Source

Strengths

  • Native quotation, order, and invoice handling eliminates the need for a separate CPQ or accounting tool on mid-market deals.
  • Lead aggregation and data enrichment features pull firmographic data automatically, reducing manual prospecting work.
  • Multilingual interface and multi-currency support accommodate UK and European teams without a costly upgrade.
  • Integrated case management with pipeline visibility gives support and sales a shared view of account health.
  • Sandbox environment available on all tiers for testing configuration changes before applying them to live data.

Weaknesses

  • Record save latency increases significantly as the database grows beyond ~50,000 active records.
  • UI and interaction patterns feel dated compared to newer CRM entrants, affecting user adoption among younger sales staff.
  • Sparse documentation and limited training resources create a steep learning curve for non-technical administrators.
  • The platform does not publish a public API reference for rate limits or bulk endpoints, making programmatic extraction harder to plan.
Salesforce Sales Cloud logo

Salesforce Sales Cloud

Destination

Strengths

  • Largest enterprise app ecosystem in CRM with 5,000+ AppExchange integrations covering nearly every vertical workflow.
  • Native Einstein AI delivers lead scoring, opportunity insights, and predictive forecasting without a third-party layer.
  • Advanced territory management, multi-currency, and flexible forecasting satisfy complex B2B revenue structures.
  • Deep platform extensibility: Custom Objects, Apex, Flow, and the Metadata API allow full schema customization.
  • Well-documented REST API, Bulk API, and Composite API with published rate limits for programmatic migration.

Weaknesses

  • Pricing model is layered and opaque in practice: per-seat fees plus storage overages, add-on subscriptions, and annual uplifts compound to 30–40% above sticker price.
  • Workflow Rules and Process Builder are deprecated, forcing all orgs onto Salesforce Flow — a migration task that catches many teams by surprise.
  • Steep administrative complexity: meaningful configuration requires a dedicated Salesforce admin or consultant.
  • API rate limits are edition-gated (100k/day base for Enterprise) and easily exhausted by large historical imports without throttling.
  • Data export is exportable via Data Loader but preserving relationship integrity across 30+ objects requires careful ETL sequencing.

Complexity grading

How hard is this migration?

Standard CRM migration. 3 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Workbooks and Salesforce Sales Cloud.

  • Object compatibility

    B

    3 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    C

    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

    A

    Workbooks exposes a bulk API — large-volume migrations stream efficiently.

Estimator

Estimate your Workbooks to Salesforce Sales Cloud migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Workbooks to Salesforce Sales Cloud data migrations

Answers to the questions buyers ask most during Workbooks to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most Workbooks migrations land between four and eight weeks for accounts under 10,000 Organisations, 20,000 People, and 5,000 Opportunities with no custom objects and clean standard field structures. Migrations with custom objects, large engagement histories (over 200,000 activity records), quotation and invoice exports requiring Business-tier verification, or custom object lookups to standard objects move to ten to sixteen weeks because of API pagination, field-level custom field enumeration, Bulk API chunking, and Order-to-Quote linkage resolution.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Workbooks.
Land in Salesforce Sales Cloud, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day