CRM migration

Migrate from RunSensible to Salesforce Sales Cloud

Field-level mapping, validation, and rollback between RunSensible and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.

RunSensible logo

RunSensible

Source

Salesforce Sales Cloud

Destination

Salesforce Sales Cloud logo

Compatibility

92%

12 of 13

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

Complexity

BStandard

Timeline

48–72 hours

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

RunSensible consolidates CRM, case management, billing, and document storage for law firms in a single platform. Its data model centers on Client records, Matter records with statute-of-limitations tracking and court-rules integration, Time Entries with billable-hour capture, Trust Accounts with IOLTA three-way reconciliation, and Documents. Salesforce Sales Cloud uses a separate Account-Contact-Lead-Opportunity model with RecordTypeId for varying page layouts per business unit, custom __c fields, and Opportunities with stage pick-list values scoped by record type. We map RunSensible clients to Salesforce Contacts attached to Accounts, RunSensible matters to Salesforce Opportunities or Cases depending on whether the firm tracks matters as sales pipeline or service cases, time entries to Tasks with billable hours preserved, and billing records to Opportunities with line-item data. RunSensible's custom legal fields (statute of limitations, court rules, practice area) migrate as Salesforce custom fields. Workflows, automations, document templates, and billing rules do not migrate — those require Salesforce-native rebuild using Flow and Salesforce Billing or a connected ERP. Our migration uses the Salesforce Bulk API for large record volumes, with owner resolution by email match to Salesforce users before data lands.

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

RunSensible logo

RunSensible

What's pushing teams away

  • Support response times frustrate firms with urgent billing or compliance questions, particularly during month-end invoice runs
  • The mid-tier plans limit API access and custom reporting, pushing growing firms toward enterprise pricing or alternative platforms
  • Users report that the calendar and scheduling features lack the granular conflict checking needed for multi-attorney practice management
  • Firms with complex multi-state compliance needs find RunSensible's court rules integration limited to specific jurisdictions rather than comprehensive
  • Some firms outgrow the platform when they require advanced analytics or custom integrations not available without a dedicated implementation

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 RunSensible objects map to Salesforce Sales Cloud

Each row shows how a RunSensible 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.

RunSensible

Client

maps to

Salesforce Sales Cloud

Contact + Account

1:1
Fully supported

RunSensible clients contain both individual contact data and organizational information. We split into a Salesforce Contact record attached to an Account record — the primary contact lands on the Account with role assignments for matter associations. RunSensible client IDs are preserved as Source_System_ID__c for delta-run deduplication.

RunSensible

Matter

maps to

Salesforce Sales Cloud

Opportunity

1:1
Fully supported

RunSensible matters map to Salesforce Opportunities when the firm uses a sales pipeline model for legal engagements. Matter name becomes Opportunity Name, matter status maps to Opportunity Stage via value mapping, and matter close date maps to CloseDate. Each matter requires a RecordType assignment based on practice area or matter type.

RunSensible

Matter

maps to

Salesforce Sales Cloud

Case

1:1
Fully supported

For firms tracking matters as service cases rather than pipeline opportunities, RunSensible matters map to Salesforce Cases. Case Origin, Case Type, and custom matter-type fields are created in Salesforce. Statute-of-limitations dates migrate as Case custom fields with deadline reminders configured in Salesforce.

RunSensible

Time Entry

maps to

Salesforce Sales Cloud

Task

1:1
Fully supported

RunSensible billable time entries are mapped to Salesforce Tasks with Type='Billable Time', preserving original duration, billable amount, and attorney owner. Administrative and non-billable time entries use Type='Admin Time'. Each Task is related to its parent Opportunity or Case via WhatId to maintain the matter association. Time entry records are processed in batch via Bulk API for performance.

RunSensible

Billing Record / Invoice

maps to

Salesforce Sales Cloud

Opportunity + Custom Invoice Object

many:1
Fully supported

RunSensible invoices contain line-item detail and payment status. The invoice header merges into the Opportunity record (Amount, Stage updated to reflect paid/unpaid). Line-item detail migrates to a custom Invoice_Line_Item__c object linked by Opportunity__c lookup. Outstanding balance and payment terms are preserved as custom fields.

RunSensible

Trust Account / IOLTA

maps to

Salesforce Sales Cloud

Custom Trust_Account__c + Journal_Entry__c

1:1
Fully supported

RunSensible's IOLTA trust accounts have no native Salesforce equivalent. We create a Trust_Account__c custom object with three-way reconciliation fields (client funds, operating account, IOLTA account), journal entry records linked as Trust_Journal_Entry__c, and a reconciliation status field. Salesforce Billing or Revenue Cloud handles future transactions post-migration.

RunSensible

Statute of Limitations

maps to

Salesforce Sales Cloud

Custom field on Case or Opportunity

1:1
Fully supported

RunSensible tracks statute of limitations dates per matter. We create a Statute_of_Limitations__c custom date field on the Case object with a validation rule triggering a reminder workflow 30 days before the deadline. Firms using Opportunities for matters create the field there instead.

RunSensible

Court Rules / Jurisdiction

maps to

Salesforce Sales Cloud

Custom pick-list fields on Matter (Opportunity or Case)

1:1
Fully supported

RunSensible court-rules data including filing deadlines, jurisdictional requirements, and court rules sets are migrated as jurisdiction-specific pick-list values on a Court_Rules_Jurisdiction__c custom field. Each RunSensible court-rules value is mapped to its Salesforce pick-list equivalent, with unmapped jurisdictions flagged in a separate review list for admin resolution before final migration.

RunSensible

Lead (RunSensible intake leads)

maps to

Salesforce Sales Cloud

Lead

1:1
Fully supported

RunSensible intake form submissions transfer to Salesforce Leads using standard fields (Name, Email, Phone, Company) alongside custom fields capturing referral source, intake form identifier, and lead status. RunSensible lead source values are mapped to Salesforce LeadSource via a value-mapping table built during the discovery phase to preserve original attribution data.

RunSensible

Document / Attachment

maps to

Salesforce Sales Cloud

Salesforce Files

1:1
Fully supported

RunSensible documents and attachments on matters or clients re-upload as Salesforce Files attached to the parent Contact, Account, Opportunity, or Case. File size limits (Salesforce default 25MB per file) apply; documents exceeding this are split or linked via external URL in a custom field. E-signature metadata is preserved in a custom field.

RunSensible

Calendar / Court Date

maps to

Salesforce Sales Cloud

Event

1:1
Fully supported

RunSensible court dates and calendar events migrate as Salesforce Events with the original start and end times, subject (matter name + event type), and attorney owner preserved. Recurring events are mapped to Salesforce Series where the recurrence pattern is extractable; otherwise they become individual Events.

RunSensible

Custom Object: Practice Area

maps to

Salesforce Sales Cloud

Custom Object + pick-list on Matter

1:1
Fully supported

Firms using RunSensible custom practice-area objects map those to a custom Practice_Area__c object linked to Matter records via lookup, or as a pick-list value on Practice_Area__c custom field on the Opportunity/Case. We create whichever model the firm's Salesforce admin specifies before migration.

RunSensible

Note

maps to

Salesforce Sales Cloud

Note

1:1
Fully supported

RunSensible notes on matters or clients are migrated as Salesforce Notes (not the legacy Note object), with rich-text formatting preserved where RunSensible's export format permits. Notes attach to their parent record via WhatId for matters and Cases, or WhoId for Contacts and Leads, maintaining the original context and association within the firm's new Salesforce environment.

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.

RunSensible logo

RunSensible gotchas

High

Trust account balance migration requires three-way reconciliation

High

Invoice-to-matter linkage is required for billable entries

Medium

API access is tier-gated and not available on Essential plan

Medium

AI Forms and Execute modules are separate paid add-ons

Low

Client intake forms use conditional logic not preserved in standard export

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

  • IOLTA trust accounting has no native Salesforce equivalent

    RunSensible's built-in IOLTA three-way reconciliation tracks client funds, operating account, and IOLTA account in a single matter context. Salesforce has no native trust accounting — billing records migrate but the reconciliation logic does not. We create a Trust_Account__c custom object with client-funds, IOLTA-balance, and journal-entry child records, but the firm needs Salesforce Billing or Revenue Cloud configured post-migration for ongoing trust transactions. Firms with active trust accounts should budget for that configuration separately.

  • RunSensible matters require RecordType assignment before field mapping can validate

    RunSensible matter types (litigation, corporate, family law, personal injury) have different field sets and workflows in Salesforce depending on which RecordType is assigned. We cannot validate Opportunity Stage pick-list mapping until each matter type maps to a Salesforce RecordTypeId, and each RecordType requires its own page layout and field-level security in Salesforce. Firms with more than three matter types need Salesforce admins to pre-create RecordTypes before migration; we deliver a RecordType mapping plan as part of the discovery phase.

  • Statute of limitations tracking requires Salesforce-side workflow or validation rule

    RunSensible tracks statute of limitations dates per matter and sends automated reminders based on those dates. When these dates migrate to Salesforce custom fields on Case or Opportunity, the reminder logic does not transfer. We preserve the date as a custom field, but Salesforce Flow or a validation rule must be built to trigger attorney notifications 30 or 60 days before the deadline. We include a Flow template in the migration package, but the firm's admin must activate and customize it.

  • Custom legal properties require Salesforce custom field creation before data loads

    RunSensible supports custom fields per matter and client without requiring a schema change process. Salesforce requires custom fields to be created in the target org before data loads — the __c suffix fields cannot be auto-created during migration. Firms with more than 20 RunSensible custom properties need to prioritize which ones migrate; the rest are archived with a reference export. We deliver a custom-field creation checklist with field types, pick-list values, and validation rules so Salesforce admins can pre-build the schema before the migration window opens.

  • RunSensible automation logic does not migrate — intake forms and matter milestones need Salesforce Flow rebuild

    RunSensible's client intake forms, matter milestone automations (court date reminders, conflict-check triggers, billing generation), and notification sequences have no direct equivalent in Salesforce. These automations must be rebuilt in Salesforce Flow or replaced with AppExchange solutions. We export the RunSensible automation definitions as a structured JSON reference file documenting each trigger-action pair mapped to its Salesforce Flow equivalent, providing a rebuild guide for the firm's admin. Firms with extensive automation logic should treat this Flow rebuild as a separate implementation project scoped after data migration completes.

Migration approach

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

  1. RunSensible API discovery and schema audit

    We connect to the RunSensible API using scoped read access to enumerate all objects — Clients, Matters, Time Entries, Billing Records, Trust Accounts, Documents, Calendar Events, and any custom objects. We produce a schema map showing every field, data type, and record count per object. This discovery run also identifies empty fields, pick-list values that have no mapping candidates, and records with missing required relationships (e.g., matters without an assigned client).

  2. Salesforce custom field and RecordType provisioning

    Before any data moves, we deliver a field creation checklist: every RunSensible custom property mapped to a Salesforce __c field with its type, pick-list values, and any validation rules needed. Firms also receive a RecordType mapping plan — each RunSensible matter type mapped to a Salesforce RecordType so Opportunity Stage pick-lists can be scoped correctly. The Salesforce admin creates these fields and RecordTypes in a sandbox first; we validate the schema matches the mapping plan before promoting to production.

  3. Owner and user resolution by email

    RunSensible attorney and staff users are resolved to Salesforce users by email match. Unmatched RunSensible owners are flagged with their record count so the firm can either invite them to Salesforce first or assign their records to a designated fallback owner. No Opportunity, Case, or Task lands in Salesforce without an OwnerId — this is validated before the migration run commits any records.

  4. Sample migration with field-level diff

    We run a representative slice — typically 200–500 records spanning clients, matters, time entries, billing records, and trust accounts — into the firm's Salesforce sandbox. We generate a field-level diff showing source value, mapped destination value, and any transformation applied. The firm's admin reviews the diff to verify matter-type RecordType assignments, statute-of-limitations date mapping, IOLTA trust-account structure, and billing status updates. We iterate on the mapping until the diff passes before the full migration window opens.

  5. Full migration with delta-pickup window

    The full migration runs in production during a scheduled window. Salesforce Bulk API handles high-volume object loads (Contacts, Opportunities, Tasks) while standard API handles lower-volume records. A delta-pickup window of 24–48 hours after the initial load captures any records created or modified in RunSensible during cutover. An audit log records every operation — record count per object, failed records with error reasons, and owner resolution status. One-click rollback reverts the Salesforce org to pre-migration state if reconciliation fails.

Platform deep dives

Context on both ends of the pair

RunSensible logo

RunSensible

Source

Strengths

  • Combines CRM, matter management, trust accounting, and client portal in one platform without requiring third-party integrations
  • AI-powered form library with 54,000+ court documents for U.S. and Canadian jurisdictions reduces manual drafting
  • IOLTA-compliant three-way reconciliation built into trust accounting satisfies bar association audit requirements
  • Competitive per-seat pricing starting at $39/user/month with transparent annual billing and a 60-day money-back guarantee
  • Workflow automation and email templates streamline client onboarding and reduce repetitive administrative tasks

Weaknesses

  • API access and custom reporting are gated behind higher pricing tiers, limiting data portability for mid-market firms
  • Calendar and scheduling conflict checking is basic, requiring manual oversight in multi-attorney practices
  • Court rules integration covers limited jurisdictions, creating gaps for firms operating across multiple states or provinces
  • Support response times during critical periods such as month-end billing receive mixed reviews from users
  • Enterprise pricing requires a custom quote with implementation costs of $10,000+, making total cost opaque until late in the sales cycle
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 RunSensible 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

    B

    RunSensible: Not publicly documented.

  • Data volume sensitivity

    B

    RunSensible doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your RunSensible 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 RunSensible to Salesforce Sales Cloud data migrations

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

Can't find your answer?

Walk through your RunSensible to Salesforce Sales Cloud migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most RunSensible to Salesforce migrations complete in 48–72 hours of clock time for firms with under 25,000 records. Firms with over 100,000 records, multiple matter types requiring separate RecordTypes, or active IOLTA trust accounts extend to 7–10 days. The longest phase is custom field and RecordType provisioning in Salesforce before data can load — Salesforce admins should allocate 3–5 business days for that setup.

Adjacent paths

Related migrations to explore

Ready when you are

Move from RunSensible.
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