Migrate from Dentally to Nutshell

Clinical charting and per-tooth records have no Nutshell destination

Dentally stores charting data at the tooth level — per-tooth status, periodontal measurements, treatment completed per surface. Nutshell has no tooth, charting, or clinical-record object. These records cannot migrate into a meaningful CRM context. We export charting data as a structured PDF or CSV and attach it to the corresponding Nutshell Person record as a static file. The practice should decide whether to retain these files in Dentally for clinical access or attach them to Nutshell for a single point of reference. This is a pair-level gotcha because the absence of a clinical object is specific to the Dentally-to-Nutshell path — it does not apply when migrating Dentally to another dental-practice-management platform.

Nutshell appointment gap requires Task-based appointment reconstruction

Nutshell has no native appointment or scheduling object — calendar events must be modelled as Tasks. This creates a representation gap: appointment duration, operatory, and appointment-type fields from Dentally have no native Nutshell landing field and are collapsed into the Task description. Practices that rely on Dentally's structured appointment data (e.g., for recall campaigns or treatment-tracking reports) will find the Nutshell Task view less granular. We advise creating a custom Nutshell view or report grouping Tasks by description keywords to approximate the Dentally appointment report. This gotcha is specific to the Dentally-to-Nutshell direction because Nutshell is not a scheduling platform — it is a sales and contact CRM.

Practitioner-to-User email matching is required before migration

Dentally practitioner records contain names and GDC numbers but no email in every configuration. Nutshell Users are identified by email. If Dentally practitioner records do not contain an email address, we cannot auto-match them to Nutshell Users and must flag each unmatched practitioner for manual resolution. We strongly recommend populating a practitioner email field in Dentally before the migration engagement begins. If no email exists, the practitioner migrates as a Person record with a Practitioner__c flag rather than a Nutshell User, which means appointment Tasks cannot be auto-assigned to the correct practitioner.

Custom fields on Treatment Items cannot use Nutshell's structured field model

Dentally supports custom fields on Treatment Items (e.g., material type, ADA category, in-house code). Nutshell custom fields exist only on Person, Company, and Lead. There is no Treatment Item object in Nutshell where these fields can land natively. We migrate Treatment Item custom field data as Person-level custom fields keyed to the most recent treatment for each patient. If the practice needs a complete treatment history rather than a single current-value snapshot, we recommend exporting the full Treatment Item table as a CSV and linking it as a file attachment on the Person record.

Nutshell does not natively support multi-location or multi-practice data separation

Dentally is designed for multi-surgery practices and stores a location or surgery identifier on each record. Nutshell does not have a native multi-location concept — all People, Companies, and Tasks live in a single workspace. We add a Practice_Location__c custom field to every migrated record, sourced from the Dentally surgery identifier. Practices that need to segment data by location in Nutshell must use this custom field in filters and reports, or rely on Nutshell's built-in tag functionality to label records by location.