CRM migration
Field-level mapping, validation, and rollback between RunSensible and Freshsales. We move data and schema; workflows are rebuilt natively in Freshsales.
RunSensible
Source
Freshsales
Destination
Compatibility
11 of 12
objects map 1:1 between RunSensible and Freshsales.
Complexity
BStandard
Timeline
3–5 days
Overview
RunSensible and Freshsales serve different primary functions. RunSensible is a legal practice management platform built around matters, trust accounting, document automation, and statute-of-limitations tracking — its CRM layer is secondary. Freshsales is a sales-focused CRM that organizes data around Leads, Contacts, Accounts, and Deals, with a Custom Objects API for extending the schema. The migration challenge is reconciling RunSensible's matter-centric data model — where a matter bundles client info, billing, tasks, documents, and court deadlines — into Freshsales' entity-relationship model. We map RunSensible contacts to Freshsales Contacts (and split unconverted leads to Freshsales Leads), RunSensible companies to Freshsales Accounts, and RunSensible matters to Freshsales Deals or a custom Matter module depending on your firm's pipeline structure. Legal-specific fields like statute_of_limitation_date, iolta_balance, and court_rules require Freshsales custom fields created before data lands. Trust account balances, client portal links, and custom matter identifiers migrate as reference fields. Billing records do not map to a native Freshsales object — they require a separate accounting integration or manual reconciliation post-migration. Workflows, automations, and document automation templates do not migrate. We extract RunSensible data via the API with scoped read access so your team keeps working throughout the process, and we capture any in-flight changes during a 24–48 hour delta window.
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 RunSensible object lands in Freshsales, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
RunSensible
Contact
Freshsales
Contact
1:1RunSensible contacts migrate to Freshsales Contacts with standard fields (firstname, lastname, email, phone, address) mapped directly. Social URLs and RunSensible‑specific profile links become custom text fields. Owner resolution relies on email matching against Freshsales users; contacts without email fall back to name‑and‑company matching, and any duplicates are flagged for admin review before final import.
RunSensible
Contact (unconverted lead)
Freshsales
Lead
1:manyRunSensible contacts that have not converted to a matter route to Freshsales Leads. RunSensible's contact status field determines the split: contacts linked to a matter become Freshsales Contacts; contacts without matter associations become Freshsales Leads with lead_status and source populated from RunSensible's intake fields.
RunSensible
Company
Freshsales
Account
1:1RunSensible companies map directly to Freshsales Accounts, preserving the company name, domain (used as website), industry pick‑list values, employee count, and annual revenue. Parent‑child hierarchies translate to Freshsales Parent Account relationships, and any unmapped industry values default to 'Other' and are logged for admin adjustment. Custom fields on the company object are created in Freshsales under Admin Settings before the migration run.
RunSensible
Matter
Freshsales
Deal
1:1RunSensible matters are the primary unit of legal work. They map to Freshsales Deals with matter_type, case_number, and practice_area carried as custom fields. Matter status (active, pending, closed) maps to Freshsales Deal stage with a value-mapping table. The deal owner in Freshsales maps from RunSensible matter's assigned attorney.
RunSensible
Matter (complex billing structure)
Freshsales
Custom Object: Matter Billing
1:1Firms with Advanced-tier RunSensible that use billing records per matter create a Freshsales Custom Object called Matter Billing to store invoice_id, billing_date, amount, status, and iolta_balance snapshot. This separates financial records from the Deal record to avoid schema complexity on the standard Deal object.
RunSensible
Task
Freshsales
Task
1:1RunSensible tasks (deadlines, court filings, client follow-ups) map to Freshsales Tasks with subject, due_date, priority, status, and owner preserved. Task descriptions are carried into Freshsales Task comments. Tasks linked to a specific matter associate to the corresponding Freshsales Deal via the lookup field.
RunSensible
Document
Freshsales
Files
1:1RunSensible documents and court forms are stored as files. They are downloaded from RunSensible storage and re-uploaded to Freshsales Files attached to the corresponding Contact, Account, or Deal. RunSensible Forms auto-fill logic cannot be preserved — document templates must be rebuilt in Freshsales or a third-party document automation tool.
RunSensible
Statute of Limitation Date
Freshsales
Custom field on Deal
1:1RunSensible's statute_of_limitation_date field is a legal-critical date that tracks filing deadlines. Freshsales has no native equivalent. We create a custom datetime field (Statute_of_Limitation_Date__c) on the Deal object and populate it from RunSensible during migration. Freshsales workflow rules can be configured to send reminders from this date.
RunSensible
Trust Account Balance
Freshsales
Custom field on Deal or Custom Object
1:1RunSensible IOLTA trust account balance (iolta_balance) has no Freshsales equivalent. We migrate the last-known balance as a custom currency field. For firms with frequent trust transactions, we recommend a separate Custom Object (Matter Billing) rather than storing balance history on the Deal, since Freshsales does not support ledger-style double-entry accounting.
RunSensible
Custom Matter Field
Freshsales
Custom field on Deal
1:1RunSensible practice-area fields (e.g., court_venue, opposing_counsel, judicial_district, immigration_visa_type) migrate as Freshsales custom fields on Deal. We create each custom field in Freshsales under Admin Settings > Deal Custom Fields and map the values during migration. Pick-list values are created with identical labels to preserve reporting continuity.
RunSensible
User / Attorney
Freshsales
User
1:1RunSensible users and attorneys resolve to Freshsales users by email match. Unmatched users are flagged before migration — your team either invites them to Freshsales first or assigns records to a fallback user. RunSensible role names (partner, associate, paralegal) map to Freshsales Custom fields on User if role visibility is required in reporting.
RunSensible
Client Portal Link
Freshsales
Custom field on Contact/Account
1:1RunSensible's client_portal_url field is a per-matter portal access link. Freshsales has no native client portal. The URL migrates as a custom text field (Client_Portal_Reference__c) on the Contact record. Your admin can configure Freshsales Freshdesk or a third-party client portal integration to replace this functionality.
| RunSensible | Freshsales | Compatibility | |
|---|---|---|---|
| Contact | Contact1:1 | Fully supported | |
| Contact (unconverted lead) | Lead1:many | Fully supported | |
| Company | Account1:1 | Fully supported | |
| Matter | Deal1:1 | Fully supported | |
| Matter (complex billing structure) | Custom Object: Matter Billing1:1 | Fully supported | |
| Task | Task1:1 | Fully supported | |
| Document | Files1:1 | Fully supported | |
| Statute of Limitation Date | Custom field on Deal1:1 | Fully supported | |
| Trust Account Balance | Custom field on Deal or Custom Object1:1 | Fully supported | |
| Custom Matter Field | Custom field on Deal1:1 | Fully supported | |
| User / Attorney | User1:1 | Fully supported | |
| Client Portal Link | Custom field on Contact/Account1: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.
RunSensible gotchas
Trust account balance migration requires three-way reconciliation
Invoice-to-matter linkage is required for billable entries
API access is tier-gated and not available on Essential plan
AI Forms and Execute modules are separate paid add-ons
Client intake forms use conditional logic not preserved in standard export
Freshsales gotchas
Freddy AI is Pro-tier only despite heavy marketing
Post-migration emails and sequences are disabled
Bot session credits are a one-time 500-session allocation
Phone credits charged per minute with no cap
File storage limits scale with plan tier
Pair-specific challenges
Migration approach
Audit RunSensible data model and schema
We connect to RunSensible via scoped read access and inventory every standard object (contacts, companies, matters, tasks), every custom field, and every active workflow and automation definition. We capture matter_type values, practice_area pick-lists, trust accounting field usage, and document attachment counts. This audit generates a schema delta report showing exactly which Freshsales custom fields and custom objects need to be created before migration — delivered as a pre-flight checklist your admin can action in Freshsales Admin Settings.
Create Freshsales schema: custom fields, custom objects, and user mapping
We deliver a structured schema setup plan: custom fields on Deal for statute_of_limitation_date, court_venue, opposing_counsel, judicial_district, and iolta_balance; a Matter Billing custom object for Advanced-tier billing records; and value-mapping tables for matter_status-to-stage and practice_area-to-deal_type. We also resolve RunSensible user email addresses against Freshsales user accounts — unmatched owners are flagged so your team can invite them or assign fallback ownership before migration runs.
Export and transform RunSensible data with field-level mapping
We extract RunSensible data via the API using scoped read access — your team continues working in RunSensible throughout. Each record is transformed according to the mapping plan: contacts split to Leads vs Contacts based on matter association, matters translate to Deals with legal custom fields populated, documents download for re-upload, and billing records stage for the Matter Billing custom object. Original create timestamps and owner IDs are preserved in custom datetime and user reference fields.
Run sample migration with field-level diff
A representative slice — typically 100–500 records spanning contacts, companies, matters, tasks, and at least one document — migrates to Freshsales in a test environment. We generate a field-level diff comparing source values against destination field contents, verifying statute dates, iolta_balance snapshots, matter_type pick-list mapping, and owner resolution. You review the diff and approve before the full run commits. Any mapping errors surface here, not at go-live.
Full migration with delta pickup and rollback
Full data migration runs against your live Freshsales account. Documents re-upload to Freshsales Files attached to the corresponding Contact, Account, or Deal. A delta-pickup window of 24–48 hours captures any RunSensible records created or modified during the cutover. An audit log records every insert, update, and skip operation. If reconciliation fails, one-click rollback reverts the Freshsales account to its pre-migration state. After rollback window closes, we deliver a final reconciliation report confirming record counts by object and field.
Platform deep dives
RunSensible
Source
Strengths
Weaknesses
Freshsales
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 RunSensible and Freshsales.
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
RunSensible: Not publicly documented.
Data volume sensitivity
RunSensible 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 RunSensible to Freshsales migration scoping. Not seeing yours? Book a call.
Walk through your RunSensible to Freshsales migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave RunSensible
Other ways to arrive at Freshsales
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.