CRM migration
Field-level mapping, validation, and rollback between Dental-Exec and Nutshell. We move data and schema; workflows are rebuilt natively in Nutshell.
Dental-Exec
Source
Nutshell
Destination
Compatibility
13 of 14
objects map 1:1 between Dental-Exec and Nutshell.
Complexity
BStandard
Timeline
24–72 hours
Overview
Dental-Exec structures its data around dental-practice operations — patients as primary records, treatment plans, production goal tracking, and drug interaction flags. Nutshell models everything as standard CRM objects: People (contacts), Companies (practices or insurance carriers), Leads, Deals (treatment-case or production tracking), Activities (appointments and calls), Tasks, and Notes. The migration maps Dental-Exec patient fields to Nutshell People, insurance carrier references to Companies with custom fields for carrier-specific data, production metrics to custom fields on Deals, and treatment-plan notes to Nutshell Notes or custom fields. We use Dental-Exec's API or CSV export to extract all records, transform field names and data types to match Nutshell's schema, create any required custom fields (Person, Company, or Lead tabs) before import, then load data in dependency order — Companies first, then People, then Leads, then Deals, then Activities. A delta-pickup window captures any records modified during cutover. Workflows, automation rules, and drug interaction logic in Dental-Exec do not have equivalents in Nutshell and must be rebuilt manually post-migration using Nutshell's automation tools.
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 Dental-Exec 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.
Dental-Exec
Patient
Nutshell
Person
1:1Dental-Exec patients map directly to Nutshell People. All core fields — name, date of birth, phone, email, and address — transfer as‑is. The original patient ID is stored as Source_System_ID__c on the Nutshell Person for traceability, and the original create date is preserved in Original_Create_Date__c. Owner assignment (provider) is resolved via email match and recorded on the Person record.
Dental-Exec
Patient.phone
Nutshell
Person.phone
1:1Primary phone number on the Dental‑Exec patient record maps to Nutshell Person.phone without transformation. If Dental‑Exec stores a mobile or secondary phone number in separate fields, those values are mapped to Person.alt_phone or a custom phone field as appropriate. Any missing phone field results in a blank entry in Nutshell; no data is dropped.
Dental-Exec
Patient.email
Nutshell
Person.email
1:1Email address moves directly from Dental‑Exec to Nutshell Person.email. Nutshell enforces uniqueness per account, so if the same email appears on multiple patient records, the migration pauses the duplicate record and flags it for your admin to resolve before the final commit. This prevents duplicate contacts while preserving the original email data.
Dental-Exec
Patient.insurance_carrier
Nutshell
Company + custom field
1:1Dental-Exec insurance carrier references (a lookup or string field on the patient) become a Company record in Nutshell representing the insurance carrier, plus a custom field (Insurance_Carrier__c) on the Person linking back. This lets practices track carrier-specific data separately from patient records.
Dental-Exec
Treatment Plan
Nutshell
Deal
1:1Dental-Exec treatment plans map to Nutshell Deals. Deal name derives from the treatment plan description or a patient-name + date composite. Deal.Amount maps from the treatment plan estimated cost if present. Deal.stage maps from the treatment plan status (proposed, in-progress, completed).
Dental-Exec
Treatment Plan.stage
Nutshell
Deal.stage
1:1Dental‑Exec treatment plan status values such as 'Scheduled', 'In Progress', 'Completed', or 'Cancelled' map to corresponding Nutshell Deal stage values through a value‑by‑value lookup. If Dental‑Exec uses custom status labels beyond these defaults, we create a custom mapping table during discovery, ensuring each label resolves to the most appropriate Nutshell stage or a custom stage when necessary.
Dental-Exec
Provider / Dentist
Nutshell
User (Owner)
1:1Dental‑Exec provider records are matched to Nutshell Users by email address, the preferred key for owner resolution. When a provider record lacks an email, we fall back to name matching and flag the record for your admin to either map to an existing Nutshell user or invite the provider as a new user before the migration runs. All resolved owners are set on the related Deals, Activities, and Tasks, preserving accountability across the CRM.
Dental-Exec
Appointment
Nutshell
Activity
1:1Dental‑Exec appointments convert to Nutshell Activities, preserving the appointment type (checkup, cleaning, procedure) as the Activity type field. Start and end times are transferred directly, linked to the corresponding Person (patient) and, when present, to a Company (insurance carrier or practice). The owning User is set to the provider who performed the appointment, and original timestamps are retained for historical reporting.
Dental-Exec
Production Goal
Nutshell
custom fields on Deal + custom field on User
1:1Dental-Exec production goal tracking per provider has no native Nutshell equivalent. We create custom fields — Production_Goal__c and Production_Actual__c — on Nutshell Deals to capture the goal context, and link to the responsible User. Nutshell's reporting can then surface provider performance by querying these custom fields.
Dental-Exec
Task / Reminder
Nutshell
Task
1:1Dental‑Exec tasks and reminders migrate to Nutshell Tasks with subject, due date, assigned User, and completion status all transferred directly. Completed tasks retain their original completion timestamp, while open tasks keep their due date and owner. Each task is linked to the associated Person (patient) record so that the task appears in the patient’s activity feed within Nutshell.
Dental-Exec
Clinical Note
Nutshell
Note + custom field on Person
many:1Dental-Exec clinical notes (drug interactions, clinical observations) merge into Nutshell Notes attached to the Person record. For compliance-relevant notes (e.g., allergy flags), we also populate a custom field on Person (e.g., Clinical_Flag__c) so the flag surfaces without opening the note.
Dental-Exec
Custom Field (Patient-level)
Nutshell
custom field on Person
1:1Dental-Exec custom fields on patient records map to Nutshell Person-level custom fields. Each custom field gets created in Nutshell under the Person tab before migration. Field type is preserved — text, number, date, pick-list — using Nutshell's corresponding field types.
Dental-Exec
Custom Field (Treatment-level)
Nutshell
custom field on Deal
1:1Dental‑Exec custom fields attached to treatment plans are recreated as custom fields on the corresponding Nutshell Deal. Field types such as text, number, date, or pick‑list are matched to Nutshell’s equivalent field types during the discovery phase. If the custom field holds provider‑specific metrics or compliance data (e.g., a drug‑interaction flag), we map it to a custom field with an appropriate type and include it in Deal reporting views.
Dental-Exec
Attachment / File
Nutshell
File attachment on Person / Deal
1:1Dental‑Exec file attachments such as treatment images, consent forms, and insurance documents are migrated as file attachments on the related Nutshell Person or Deal record. File size is limited to the standard upload limit defined by the Nutshell plan tier; files exceeding this limit are flagged for your admin to upload manually after cutover or to increase storage. Original file names and creation timestamps are preserved where possible.
| Dental-Exec | Nutshell | Compatibility | |
|---|---|---|---|
| Patient | Person1:1 | Fully supported | |
| Patient.phone | Person.phone1:1 | Fully supported | |
| Patient.email | Person.email1:1 | Fully supported | |
| Patient.insurance_carrier | Company + custom field1:1 | Fully supported | |
| Treatment Plan | Deal1:1 | Fully supported | |
| Treatment Plan.stage | Deal.stage1:1 | Fully supported | |
| Provider / Dentist | User (Owner)1:1 | Fully supported | |
| Appointment | Activity1:1 | Fully supported | |
| Production Goal | custom fields on Deal + custom field on User1:1 | Fully supported | |
| Task / Reminder | Task1:1 | Fully supported | |
| Clinical Note | Note + custom field on Personmany:1 | Fully supported | |
| Custom Field (Patient-level) | custom field on Person1:1 | Fully supported | |
| Custom Field (Treatment-level) | custom field on Deal1:1 | Fully supported | |
| Attachment / File | File attachment on Person / Deal1: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.
Dental-Exec gotchas
No public API for automated exports
Recall and hygiene data embedded in task records
Drug interaction flags are binary, not structured
Thin vendor footprint raises continuity risk
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
Request and audit Dental-Exec full data export
FlitStack AI requests a complete data export from Dental-Exec — typically a CSV backup covering patients, treatment plans, appointments, tasks, clinical notes, and any custom fields. We audit the export for field completeness, identify any fields Dental-Exec omits from its export, and document which objects have data. If the export is incomplete, we surface gaps before scope is finalized. This step also identifies the unique carrier names used in insurance fields so we can plan the Company deduplication logic before import.
Create Nutshell custom fields and Company records
Before any data loads into Nutshell, we create all required custom fields: Production_Goal__c and Production_Actual__c on Deal, Insurance_Carrier__c and Allergy_Flag__c on Person, and any dynamic custom fields discovered in the Dental-Exec export. We also pre-create Company records for every unique insurance carrier name found in the export, normalizing spelling variations to avoid duplicates. This ensures the Person import can resolve carrier lookups correctly on first pass.
Resolve owners and users by email match
Dental-Exec provider and staff IDs are matched to Nutshell Users by email address. If a Dental-Exec provider has no associated email in the export, we flag the record and your admin either maps it to an existing Nutshell user or creates a new Nutshell user before migration. No Deal, Activity, or Task lands in Nutshell without a valid owner assignment — unresolved assignments are held in a staging queue for manual resolution.
Run a sample migration with field-level diff
A representative slice of records — typically 100–300 patients, their associated treatment plans, appointments, and tasks — migrates first. We generate a field-level diff showing source value, transformed value, and destination value for every mapped field. You review the diff to verify production goal mapping, insurance carrier linking, clinical note attachment, and stage assignment before the full run commits. This is the validation checkpoint where adjustments to value-mapping tables or custom field creation are made.
Execute full migration with delta-pickup window
The full migration runs against Nutshell's API in dependency order: Companies (carriers) first, then People (patients), then Leads, then Deals (treatment plans), then Activities (appointments), then Tasks, then Notes and attachments. A delta-pickup window of 24–48 hours after the full run captures any records created or modified in Dental-Exec during cutover. An audit log records every operation; one-click rollback is available if reconciliation fails.
Platform deep dives
Dental-Exec
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 Dental-Exec 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
Dental-Exec: Not publicly documented.
Data volume sensitivity
Dental-Exec 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 Dental-Exec to Nutshell migration scoping. Not seeing yours? Book a call.
Walk through your Dental-Exec 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 Dental-Exec
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.