CRM migration
Field-level mapping, validation, and rollback between tab32 and Nutshell. We move data and schema; workflows are rebuilt natively in Nutshell.
tab32
Source
Nutshell
Destination
Compatibility
12 of 12
objects map 1:1 between tab32 and Nutshell.
Complexity
BStandard
Timeline
48–72 hours
Overview
tab32 is a cloud-native dental practice management system built for DSOs, storing patient records, tooth-chart data, perio exam results, treatment plans, appointment schedules, insurance claims, and provider profiles across multi-location practices. Nutshell is a sales CRM for small-to-mid-market teams that organizes data as People, Companies, Leads, Deals, and Activities with a simple pipeline model and four flexible pipeline views (List, Map, Chart, Board). The migration maps tab32 patient records to Nutshell People, tab32 companies to Nutshell Companies, tab32 appointments to Nutshell Activities (Tasks), and tab32 treatment plans and clinical data to custom fields on Person records. tab32's Open Data Warehousing exports give FlitStack API access to structured patient data including insurance details, recall dates, and clinical notes. We sequence the migration by resolving tab32 provider IDs to Nutshell Users by email match, then migrate Companies first, then People, then Activities so foreign-key relationships resolve correctly. Automations, recall workflows, and treatment-plan rules in tab32 do not migrate — we export those definitions as rebuild references for your team to recreate in Nutshell's automation tools. A delta-pickup window captures any new appointments or patient updates during the cutover 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 tab32 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.
tab32
Patient
Nutshell
Person
1:1tab32 Patient records map 1:1 to Nutshell Person records. The patient's full name splits into firstName and lastName on the Nutshell Person. DOB, address, phone, and email transfer as standard fields. Insurance data and recall-interval fields become Nutshell custom fields on the Person record.
tab32
Practice / Location
Nutshell
Company
1:1tab32 practice locations map to Nutshell Company records. Practice name, address, phone, and timezone transfer as standard Company fields. For DSOs with parent-company hierarchies, the top-level DSO becomes the parent Company in Nutshell and each location is a child Company linked via the parentId relationship.
tab32
Appointment
Nutshell
Activity (Task / Event)
1:1tab32 appointments map to Nutshell Tasks (for tasks like follow-up calls) and Events (for scheduled visits). The appointment date and time become the Task due date or Event start/end time. Provider ID resolves to the Nutshell User by email match. CDT procedure codes, appointment type (hygiene, restorative, surgical), and operatory location become custom fields on the Activity record.
tab32
Treatment Plan
Nutshell
Note on Person record
1:1tab32 treatment plans include procedure description, CDT code, treatment status (proposed, accepted, completed), estimated cost, and provider recommendation. These transfer as a structured Note on the associated Person record in Nutshell. Active treatment-plan status is preserved as a custom pick-list field on the Person so sales or ops teams can see ongoing care context at a glance.
tab32
Provider / Dentist
Nutshell
Nutshell User / Custom Field on Person
1:1tab32 provider profiles (dentist name, specialty, NPI number) map to Nutshell User records via email match. When a provider is a treating clinician on a patient record without a corresponding Nutshell login, the provider name and specialty migrate as a custom field on the Person record so clinical attribution is preserved.
tab32
Insurance Record
Nutshell
Custom Fields on Person
1:1tab32 stores insurance carrier name, group number, subscriber ID, subscriber relationship, and coverage percentages per patient. Nutshell has no native insurance fields, so FlitStack creates custom text and pick-list fields on the Person record: Insurance_Carrier__c, Insurance_Group_Number__c, Insurance_Subscriber_ID__c, and Coverage_Level__c (single/family).
tab32
Recall / Re-care Date
Nutshell
Custom Field on Person
1:1tab32 recall intervals trigger re-care appointments (e.g., 6-month hygiene recall). The next recall date migrates as a custom date field (Next_Recall_Date__c) on the Person record in Nutshell. This enables ops teams to build task automations in Nutshell around recall follow-up without rebuilding from scratch.
tab32
Clinical Note / Charting Data
Nutshell
Note / Custom Fields on Person
1:1tab32 tooth-chart and perio exam data are clinical records with procedure-level detail. Because Nutshell is a CRM and not a clinical system, this data migrates as structured Notes attached to the Person record. FlitStack maps perio pocket-depth readings to a Note with a standardized format (Tooth-Surface-Pocket-Depth) so clinical staff can review historical perio status in Nutshell.
tab32
Claim / Billing Record
Nutshell
Custom Fields on Person + Activity
1:1tab32 insurance claim records include claim status (submitted, pending, paid, denied), amount billed, amount paid, and adjusted amount. Claim status and last-claim-date migrate as custom fields on the Person record. Each claim submission date becomes a Note or Task on the Person so the billing history is accessible to the ops team in Nutshell.
tab32
tab32 File / Attachment
Nutshell
Nutshell Attachment / Note with link
1:1tab32 patient attachments (insurance cards, treatment consent forms, imaging referrals) are files associated with a patient record. FlitStack downloads these files and re-uploads them as attachments on the corresponding Nutshell Person record. File size limits follow Nutshell's attachment constraints. Files that exceed size limits are converted to hosted links stored as a Note.
tab32
Patient Balance / A/R
Nutshell
Custom Field on Person
1:1tab32 tracks outstanding patient balances and accounts receivable. The current balance migrates as a custom currency field (Outstanding_Balance__c) on the Nutshell Person record. This is a reference field only — revenue cycle management is handled in the dental PMS or billing system, not in Nutshell's CRM context.
tab32
Lead / Prospective Patient
Nutshell
Nutshell Lead
1:1tab32 prospective patients (leads from marketing campaigns, new-patient intake forms, or walk-in inquiries) map directly to Nutshell Lead records. Lead source, inquiry date, and referred-by information transfer as standard Nutshell Lead fields or custom fields if tab32 captures additional referral context.
| tab32 | Nutshell | Compatibility | |
|---|---|---|---|
| Patient | Person1:1 | Fully supported | |
| Practice / Location | Company1:1 | Fully supported | |
| Appointment | Activity (Task / Event)1:1 | Fully supported | |
| Treatment Plan | Note on Person record1:1 | Fully supported | |
| Provider / Dentist | Nutshell User / Custom Field on Person1:1 | Fully supported | |
| Insurance Record | Custom Fields on Person1:1 | Fully supported | |
| Recall / Re-care Date | Custom Field on Person1:1 | Fully supported | |
| Clinical Note / Charting Data | Note / Custom Fields on Person1:1 | Fully supported | |
| Claim / Billing Record | Custom Fields on Person + Activity1:1 | Fully supported | |
| tab32 File / Attachment | Nutshell Attachment / Note with link1:1 | Fully supported | |
| Patient Balance / A/R | Custom Field on Person1:1 | Fully supported | |
| Lead / Prospective Patient | Nutshell Lead1: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.
tab32 gotchas
Data quality inheritance blocks clean migration
DSO multi-location structure requires explicit office mapping
Imaging data lives outside the standard export path
Fee schedule consolidation is a pre-migration prerequisite
Training and support model assumes daytime availability
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
Audit tab32 data export and map patient-to-person relationships
FlitStack begins by querying tab32's API exports for all patient records, appointment histories, treatment plans, provider profiles, practice locations, and insurance records. We cross-reference patient-to-location relationships and provider IDs against the tab32 user roster. This audit produces a data-volume report and flags any records with missing email addresses (required for Nutshell User match) or incomplete insurance data. We deliver a pre-migration data-cleaning checklist if duplicate patients, outdated records, or incomplete addresses are found above a defined threshold.
Create Nutshell custom fields and Company hierarchy
Before data lands in Nutshell, FlitStack provisions the custom fields identified in the mapping plan: Insurance_Carrier__c, Insurance_Group_Number__c, Insurance_Subscriber_ID__c, Coverage_Level__c, Next_Recall_Date__c, Treatment_Status__c, Outstanding_Balance__c, Claim_Status__c, Original_Created_Date__c, Source_System_ID__c, and others. For multi-location DSO setups, we create the parent-Company hierarchy in Nutshell first so each child Company exists before patient records are linked to it. This step also includes setting up any Nutshell pick-list values (gender, subscriber relationship, claim status) that match tab32 enumerated values.
Match tab32 providers to Nutshell Users and flag gaps
tab32 provider IDs are matched to Nutshell Users by email address. FlitStack runs a pre-flight match against Nutshell's User list and generates a gap report showing which tab32 providers have no corresponding Nutshell User account. Your team either creates new Nutshell User accounts for those providers before the migration run, or FlitStack assigns their records to a designated fallback User and stores the provider name in a custom field on each affected Person record. No patient record migrates without a resolved owner.
Migrate in dependency order with sample diff
The migration runs in the correct foreign-key sequence: Companies first (establish the account hierarchy), then People (linking each Person to a Company via the person-company association), then Activities (Tasks for appointments, Notes for treatment plans and clinical data). A representative sample migration (typically 100–300 patient records with appointments) runs first. FlitStack generates a field-level diff comparing source values in tab32 against the migrated values in Nutshell so you can verify recall-date mapping, insurance field population, provider ownership, and treatment-plan Note formatting before the full run commits.
Execute full migration with delta-pickup cutover
The full dataset migrates against Nutshell's production instance. A delta-pickup window of 24–48 hours captures new patient records created, appointments scheduled, or treatment plans updated in tab32 during the cutover window. FlitStack logs every record created, updated, or skipped with a reason code. After the delta window closes, we run a reconciliation count comparing total records in tab32 at cutover against total records in Nutshell and surface any gaps for manual review. One-click rollback is available if reconciliation fails.
Platform deep dives
tab32
Source
Strengths
Weaknesses
Nutshell
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 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 tab32 and Nutshell.
Object compatibility
1 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
tab32: Not publicly documented.
Data volume sensitivity
tab32 exposes a bulk API — large-volume migrations stream efficiently.
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 tab32 to Nutshell migration scoping. Not seeing yours? Book a call.
Walk through your tab32 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 tab32
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.