CRM migration
Field-level mapping, validation, and rollback between Pulse Digital Clinic and Nutshell. We move data and schema; workflows are rebuilt natively in Nutshell.
Pulse Digital Clinic
Source
Nutshell
Destination
Compatibility
11 of 12
objects map 1:1 between Pulse Digital Clinic and Nutshell.
Complexity
BStandard
Timeline
48–72 hours
Overview
Pulse Digital Clinic is a medical practice management platform designed for healthcare workflows — patient registration, clinical records, appointment scheduling, e-prescribing, and billing all live in one system without an exposed API. Nutshell is a small-to-mid-market CRM that organizes data into People (contacts), Companies, Leads, Deals, and Activities. The two platforms have fundamentally different data models: Pulse structures around patients and clinical encounters; Nutshell structures around accounts, opportunities, and sales activities. We map Pulse patient records to Nutshell People, clinic identifiers to Company records, appointment timestamps to Activity records, and preserve Pulse's medical record numbers and treatment histories as custom fields on Nutshell contacts. Because Pulse has no public API, data export relies on the platform's built-in data import/export functionality or structured manual extraction. Nutshell's JSON-RPC API receives the mapped records. Automations, e-prescribing workflows, and billing logic cannot migrate — they must be rebuilt in Nutshell or handled through separate healthcare-specific tools. Our migration approach sequences People before Companies, resolves owner assignments by email match, runs a sample migration with field-level diff, then executes the full cutover with a delta-pickup window for in-flight records.
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 Pulse Digital Clinic 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.
Pulse Digital Clinic
Patient / Patient Registration
Nutshell
Person
1:1Pulse patient records map directly to Nutshell People. Each patient name, contact detail, and demographic field translates to the corresponding Nutshell Person field. The original Pulse patient ID is preserved as Source_Pulse_ID__c for traceability.
Pulse Digital Clinic
Clinic / Facility
Nutshell
Company
1:1Pulse's multi-clinic configuration maps to Nutshell Companies. Each clinic location becomes a Company record with address and contact information. Clinic-level identifiers are preserved as custom fields on the Company.
Pulse Digital Clinic
Medical Record Number (MRN)
Nutshell
Custom Field on Person (MRN__c)
1:1Nutshell has no native medical record number field. We create a custom text field (MRN__c) on the Person object and populate it with Pulse's internal patient identifier for clinical reference and cross-system lookups.
Pulse Digital Clinic
Appointment / Scheduling
Nutshell
Task and Activity
1:1Pulse appointment records become Nutshell Tasks (for standalone tasks) and Activities (for physician visits, procedures). Appointment type, physician name, and status map to Task subject, owner, and status fields. Original appointment timestamps and duration are preserved.
Pulse Digital Clinic
Appointment Status / Encounter Type
Nutshell
Task Status
1:1Pulse appointment statuses (Scheduled, Completed, No-Show, Cancelled) map to Nutshell Task status values. We apply a value-by-value mapping so that completed encounters reflect as completed tasks and cancelled appointments reflect as such in Nutshell.
Pulse Digital Clinic
Physician / Practitioner
Nutshell
Person (owner) or Custom Field
many:1Pulse physician records may map to Nutshell users by email match if physician contact details include email addresses. Otherwise, physician name stores as a custom field (Attending_Physician__c) on the related Person record.
Pulse Digital Clinic
Clinical Notes / Encounter Notes
Nutshell
Note on Person
1:1Pulse clinical encounter notes migrate as Nutshell Notes attached to the Person record. Original encounter dates and physician names are preserved in the Note metadata. Rich-text formatting in Pulse notes is converted to plain text to match Nutshell's Note format.
Pulse Digital Clinic
Prescription / E-Prescribing Data
Nutshell
Custom Field on Person (Prescription_History__c)
1:1Pulse prescription records do not have a direct Nutshell equivalent. We concatenate prescription history into a custom multi-line text field (Prescription_History__c) on the Person record for reference.
Pulse Digital Clinic
Billing / Payment Record
Nutshell
Custom Field on Person (Billing_Summary__c) or Deal
1:1Pulse billing records (invoices, payments, outstanding balances) do not map to standard Nutshell objects. We create a custom text field capturing billing summary, or map outstanding balances to Deal amounts if the clinic uses Nutshell Deals to track service agreements.
Pulse Digital Clinic
Patient Tags / Categories
Nutshell
Custom Field on Person (Patient_Category__c)
1:1Pulse patient category tags (New Patient, Follow-up, Specialist Referral) have no Nutshell equivalent. We create a custom pick-list field (Patient_Category__c) on Person and map values directly.
Pulse Digital Clinic
Campaign / Outreach Data
Nutshell
Lead Source or Custom Field
1:1Pulse campaign management data maps to Nutshell's Lead Source field on Person records. Historical campaign membership is preserved as a custom field (Source_Campaign__c) if the data exists.
Pulse Digital Clinic
Pulse System Metadata (created date, modified date)
Nutshell
Custom Datetime Fields on Person
1:1Original Pulse record creation and modification timestamps are preserved as custom datetime fields (Original_Created_Date__c, Original_Modified_Date__c) on the Person record for audit continuity.
| Pulse Digital Clinic | Nutshell | Compatibility | |
|---|---|---|---|
| Patient / Patient Registration | Person1:1 | Fully supported | |
| Clinic / Facility | Company1:1 | Fully supported | |
| Medical Record Number (MRN) | Custom Field on Person (MRN__c)1:1 | Fully supported | |
| Appointment / Scheduling | Task and Activity1:1 | Fully supported | |
| Appointment Status / Encounter Type | Task Status1:1 | Fully supported | |
| Physician / Practitioner | Person (owner) or Custom Fieldmany:1 | Fully supported | |
| Clinical Notes / Encounter Notes | Note on Person1:1 | Fully supported | |
| Prescription / E-Prescribing Data | Custom Field on Person (Prescription_History__c)1:1 | Fully supported | |
| Billing / Payment Record | Custom Field on Person (Billing_Summary__c) or Deal1:1 | Fully supported | |
| Patient Tags / Categories | Custom Field on Person (Patient_Category__c)1:1 | Fully supported | |
| Campaign / Outreach Data | Lead Source or Custom Field1:1 | Fully supported | |
| Pulse System Metadata (created date, modified date) | Custom Datetime Fields on Person1: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.
Pulse Digital Clinic gotchas
No public API forces manual or custom extraction
WhatsApp conversation history is non-exportable
Medical records require field-level schema mapping
Lifetime license holders face migration timing pressure
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 and audit Pulse data using available export tools
We begin with a full data extraction audit from Pulse Digital Clinic using the platform's built-in data import/export functionality. We validate record counts for patient registrations, appointment histories, clinical notes, and billing records against your internal counts. Any objects or fields the export tool omits are flagged with impact assessment — your team decides whether to include manual extraction for those records or defer to post-migration entry. This audit establishes the migration scope and forms the basis of the field-level mapping plan.
Design Nutshell custom fields and custom object for Pulse data
Based on the extraction audit, we create the custom fields in Nutshell that Pulse data requires: MRN__c on Person for medical record numbers, Prescription_History__c for prescription data, Original_Created_Date__c for audit continuity, and any billing-specific fields identified in the scope. If billing records require a custom object, we design that object schema before the import phase begins. This step runs in parallel with the extraction audit so Nutshell is schema-ready when data arrives.
Resolve owners and validate physician email matches
We match Pulse physician and practitioner records against Nutshell users by email address. Matched records inherit the corresponding Nutshell user as owner; unmatched records are flagged with the physician name and current assignment status. Your team confirms the fallback owner for unmatched records or creates Nutshell user accounts for physicians who need direct ownership. Owner resolution must complete before the full migration runs to avoid orphaned records.
Run sample migration with field-level diff
A representative slice of records — typically 100–500 spanning patients, appointments, and billing entries — migrates first. We generate a field-level diff comparing source Pulse values against the migrated Nutshell records so you can verify MRN preservation, appointment mapping, physician assignment, and billing field accuracy before committing the full run. Any mapping adjustments are applied before the full cutover.
Execute full cutover with delta-pickup window
The full migration loads all validated records into Nutshell — patients mapped to People with MRN__c and custom fields, appointments mapped to Tasks with physician ownership, and billing data mapped to Deals or custom objects per the agreed design. A delta-pickup window (24–48 hours) captures any records created or modified in Pulse during the cutover. An audit log records every operation, and one-click rollback is available if reconciliation identifies unexpected gaps.
Platform deep dives
Pulse Digital Clinic
Source
Strengths
Weaknesses
Nutshell
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 of 8 objects need a manual workaround.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Pulse Digital Clinic and Nutshell.
Object compatibility
1 of 8 objects need a manual workaround.
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
Pulse Digital Clinic: Not applicable — APIs explicitly not available.
Data volume sensitivity
Pulse Digital Clinic 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 Pulse Digital Clinic to Nutshell migration scoping. Not seeing yours? Book a call.
Walk through your Pulse Digital Clinic 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 Pulse Digital Clinic
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.