CRM migration
Field-level mapping, validation, and rollback between CASEpeer and Nutshell. We move data and schema; workflows are rebuilt natively in Nutshell.
CASEpeer
Source
Nutshell
Destination
Compatibility
10 of 12
objects map 1:1 between CASEpeer and Nutshell.
Complexity
BStandard
Timeline
48–72 hours
Overview
CASEpeer structures its database around legal-case objects: Parties (plaintiffs, defendants, attorneys, medical providers), Cases, Medical Records, Documents, and Calendar Events. Its custom intake forms add firm-specific fields per case type. Nutshell uses a standard CRM schema: People (contacts), Companies, Leads, Deals (opportunities), Tasks, and Events — with custom fields available on People, Companies, and Leads. The data model divergence is significant: CASEpeer's case-centric, multi-party-per-case structure has no direct equivalent in Nutshell's deal-centric model. We resolve this by mapping each CASEpeer Case to a Nutshell Deal, with the primary plaintiff Party mapped to the associated People record. Other parties (medical providers, opposing counsel) become additional People records with a custom Party_Role__c field to preserve their relationship to the case. Custom intake form fields migrate as custom fields on Nutshell People. CASEpeer does not expose a documented public REST API; we use CASEpeer's internal export tools and structured data pull to extract records, then load into Nutshell via its JSON-RPC API with type-aware field mapping. Documents and medical records are flagged as reference-only — Nutshell has no document-management object, so those files are exported to a downloadable archive with links stored in a custom field. Workflows, calendaring rules, and intake-form logic do not migrate; we provide a rebuild reference export so your Nutshell admin can reconfigure automations post-migration.
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 CASEpeer object lands in Nutshell, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
CASEpeer
Party
Nutshell
Person
1:1Each CASEpeer Party maps to a Nutshell Person record. The primary plaintiff on a case is flagged as the primary contact on the associated Deal. Other party types (medical provider, opposing counsel, witness) map to additional Person records with Party_Role__c set to distinguish their role in the case context.
CASEpeer
Party
Nutshell
Company
many:1CASEpeer Party records that represent organizations — medical providers, insurance carriers, opposing law firms, and similar entities — map to Nutshell Company records when the Party record contains an organizational name and corresponding contact information. Individual attorney parties and single-person entities remain as Person records with their contact details preserved. This organization-versus-individual distinction ensures that the correct CRM object type is used for each party type.
CASEpeer
Case
Nutshell
Deal
1:1Each CASEpeer Case maps to one Nutshell Deal. The CASEpeer case name becomes the Deal name; the case number is preserved in Case_Number__c. The primary plaintiff Party is linked via a Deal-Person association in Nutshell. All other party People are associated to the same Deal with their Party_Role__c values.
CASEpeer
Case Custom Fields
Nutshell
Person (custom fields)
1:1CASEpeer custom intake form fields are tied to Case type. Since Nutshell has no custom fields on Deals, each custom field is migrated as a custom field on the Person record linked as the primary plaintiff. Your migration plan identifies the case type field first, then branches intake fields to the correct Person custom field group.
CASEpeer
Medical Record
Nutshell
Activity Note (custom)
1:1CASEpeer medical records have no Nutshell equivalent. We export them as structured JSON objects stored in a Medical_Records_JSON__c custom field on the associated Person record, with the original record type, provider, date, and summary fields preserved for reference. Medical records require a separate archive for document-level files.
CASEpeer
Document / File Attachment
Nutshell
External archive + link field
1:1CASEpeer documents attached to cases have no native document management counterpart in Nutshell. We export all documents to a compressed archive organized by case number and deliver the archive alongside the migration. A Document_Archive_URL__c custom field on the Deal stores the archive path or shared-link reference for access post-migration.
CASEpeer
Calendar Event
Nutshell
Event / Task
1:1CASEpeer calendar entries — court dates, filing deadlines, depositions — map to Nutshell Events with the original date, time, and description preserved. Statute-of-limitations dates are stored as custom date fields on the Deal. Nutshell's Events do not support court-deadline reminders, so this requires post-migration reconfiguration in Nutshell's Tasks or a third-party calendaring tool.
CASEpeer
Case Note
Nutshell
Note (on Deal or Person)
1:1CASEpeer case notes migrate as Nutshell Notes attached to the associated Deal record. Original timestamps and note author are preserved. If the note references a specific party, the note is duplicated on the corresponding Person record with a note referencing the case.
CASEpeer
Opposing Party / Insurance Carrier
Nutshell
Person or Company + custom field
many:1CASEpeer opposing parties and insurance carriers that are organizations map to Nutshell Company records; individual adjusters map to Person records. A custom Insurance_Role__c pick-list field on the Company or Person record captures whether the entity is an insurer, adjuster, or opposing party for case-context clarity.
CASEpeer
Custom Intake Form
Nutshell
Person custom fields (grouped by case type)
1:1CASEpeer intake forms are firm-specific and case-type-specific. We extract all intake form definitions and field values, then create corresponding Nutshell Person custom fields grouped by case type in the field naming convention (e.g., Auto_MI_Date_of_Loss__c). Your admin receives a field-map spreadsheet showing every intake field and its Nutshell destination.
CASEpeer
CASEpeer User / Staff
Nutshell
Nutshell User
1:1CASEpeer user accounts (attorneys, paralegals, staff) are resolved by email match against Nutshell user accounts. Unmatched CASEpeer users are flagged before migration — your team creates corresponding Nutshell users or assigns records to a fallback Nutshell user to prevent orphaned activities and case assignments.
CASEpeer
Workflow / Automation
Nutshell
N/A
1:1CASEpeer workflows, calendaring rules via CalendarRules, and intake-form conditional logic have no direct Nutshell equivalent due to platform-specific automation architecture. We export all workflow definitions and CalendarRules configuration as a structured JSON reference document. Your Nutshell admin uses this export to rebuild equivalent automations in Nutshell's workflow tools available on Pro and above. Complex automations involving multi-step conditional branching or court-deadline logic may require supplementary configuration or a third-party scheduling tool integration.
| CASEpeer | Nutshell | Compatibility | |
|---|---|---|---|
| Party | Person1:1 | Fully supported | |
| Party | Companymany:1 | Fully supported | |
| Case | Deal1:1 | Fully supported | |
| Case Custom Fields | Person (custom fields)1:1 | Fully supported | |
| Medical Record | Activity Note (custom)1:1 | Fully supported | |
| Document / File Attachment | External archive + link field1:1 | Fully supported | |
| Calendar Event | Event / Task1:1 | Fully supported | |
| Case Note | Note (on Deal or Person)1:1 | Fully supported | |
| Opposing Party / Insurance Carrier | Person or Company + custom fieldmany:1 | Fully supported | |
| Custom Intake Form | Person custom fields (grouped by case type)1:1 | Fully supported | |
| CASEpeer User / Staff | Nutshell User1:1 | Fully supported | |
| Workflow / Automation | N/A1: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.
CASEpeer gotchas
Dropbox custom folder creation fails silently for extended periods
Custom fields unavailable on the Client Intake Form
Data Sync is a daily batch export, not a live data feed
Mass texting and attachment-in-text unavailable across all tiers
Nutshell gotchas
Contact tier limits enforced on import
No bulk API endpoint requires paginated extraction
Email sequences not exportable via API
Foundation plan disables key sales features
Pair-specific challenges
Migration approach
Extract CASEpeer data using structured export
We use CASEpeer's data export capabilities and structured API pulls to extract all Parties, Cases, Medical Records, Case Notes, and Calendar Events. Document metadata is extracted from CASEpeer's integration logs and Dropbox export manifest. The extracted data is profiled for quality — duplicate parties, multi-party case relationships, and missing required fields are flagged before mapping begins. Your team receives a data-quality report showing record counts by type, duplicate candidates, and any fields that cannot be extracted from CASEpeer.
Design Nutshell schema and custom field configuration
Based on the CASEpeer data profile, we design the Nutshell custom field set: Party_Role__c pick-list on Person, Case_Number__c and Case_Type__c text/pick-list on Deal, SOL_Date__c and Incident_Date__c date fields on Deal, and intake-form fields grouped by case type on Person. We deliver a schema setup plan so your Nutshell admin creates the custom fields before data loads begin. Pipeline stages are proposed based on CASEpeer case status values. User accounts are resolved by email match — unmatched CASEpeer users are flagged so Nutshell accounts can be provisioned or records assigned to a fallback owner.
Run sample migration with field-level diff
A representative slice — typically 50–200 records spanning multiple case types, parties, and activity types — migrates first into your live Nutshell instance. We generate a field-level diff report comparing source values to destination values for every mapped field. You review the diff to verify party-role mapping, case-status value mapping, custom field population, and owner resolution. Sample migration results determine whether the value-mapping table for case statuses needs adjustment before the full run commits.
Execute full migration with delta-pickup window
The full migration loads all CASEpeer records into Nutshell. A delta-pickup window (24–48 hours) captures any records created or modified in CASEpeer during the cutover window — your team continues working in CASEpeer while the migration runs. All operations are logged in an audit trail. If reconciliation identifies missing or incorrectly mapped records, one-click rollback reverts the Nutshell load so corrections can be made and the run re-executed. After rollback window closes, your team exports the Dropbox document archive using the manifest we provided, imports files to a chosen document management system, and updates Document_Archive_URL__c with the final file locations.
Deliver rebuild reference and post-migration verification
We deliver the CASEpeer workflow definitions and CalendarRules configuration as a structured JSON export, the complete field-map spreadsheet showing every intake field and its Nutshell destination, and the document manifest. Your Nutshell admin uses these artifacts to rebuild automations in Nutshell's workflow tools and configure calendar integrations post-migration. Additionally, we run a comprehensive reconciliation report that compares CASEpeer record counts by type against Nutshell record counts to confirm all records were loaded successfully and no data was missed during the migration process.
Platform deep dives
CASEpeer
Source
Strengths
Weaknesses
Nutshell
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 2 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 CASEpeer and Nutshell.
Object compatibility
2 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
CASEpeer: Not publicly documented — CASEpeer does not publish a general developer portal with limits. Partner integrations operate under contractually defined thresholds..
Data volume sensitivity
CASEpeer 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 CASEpeer to Nutshell migration scoping. Not seeing yours? Book a call.
Walk through your CASEpeer to Nutshell migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave CASEpeer
Other ways to arrive at Nutshell
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.