CRM migration
Field-level mapping, validation, and rollback between axiUm Dental and Nutshell. We move data and schema; workflows are rebuilt natively in Nutshell.
axiUm Dental
Source
Nutshell
Destination
Compatibility
12 of 12
objects map 1:1 between axiUm Dental and Nutshell.
Complexity
BStandard
Timeline
1–3 weeks
Overview
Migrating from axiUm Dental to Nutshell is a cross-domain move: axiUm is a clinical practice-management and academic dental EHR with dental-specific objects (patients, providers, appointments, treatment plans, periodontal charts, billing transactions), while Nutshell is a general sales CRM built around People, Companies, Leads, Deals, and Activities. There is no direct structural equivalent for clinical fields like the odontogram, CDT codes, or HIPAA-grade patient notes. We map axiUm patient demographics to Nutshell People, companies/practices to Nutshell Companies, and appointment history to Nutshell Activities with original timestamps. Insurance carrier, group number, CDT procedure codes, and treatment plan references migrate as custom fields — Nutshell's custom field infrastructure (created per Company, Person, or Lead object) accommodates these cleanly. Financial-transaction history is preserved as custom fields since Nutshell has no native billing module. axiUm's API supports scoped data export for migration use cases. FlitStack AI sequences the migration: audit source schema, create destination custom fields, migrate people and companies first (with proper foreign-key ordering), attach activity history, then run a sample diff before full cutover. A 24–48 hour delta-pickup window captures records modified during the switch. Automations, alerts, student-evaluation rules, and clinical templates do not have CRM equivalents and must be rebuilt in Nutshell manually or with FlitStack's rebuild-reference export.
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 axiUm Dental 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.
axiUm Dental
Patient
Nutshell
Person
1:1axiUm patient demographics (name, DOB, contact info, address) map directly to Nutshell Person fields. The patient record's clinical data (allergies, medical alerts) migrates as custom Person fields. Nutshell Persons do not support clinical notes natively — those are stored in a custom text field or as a linked file.
axiUm Dental
Patient → Primary Insurance
Nutshell
Person (custom fields)
1:1Insurance carrier name, group number, subscriber ID, andeligibility date map to Nutshell Person custom text fields. Nutshell has no native insurance object — these must be defined as custom fields before migration and labeled clearly so front-desk staff can find them during patient intake in Nutshell.
axiUm Dental
Company / Practice
Nutshell
Company
1:1For practices that store referring dentists, group practices, or DSO parent entities in axiUm, those practice names and addresses map to Nutshell Companies. A Nutshell Company record is linked to each Person (patient) via the 'belongs_to' relationship so patient-provider attribution is preserved in the CRM graph.
axiUm Dental
Provider / Faculty
Nutshell
Person (custom fields)
1:1axiUm provider names, specialties (general dentist, oral surgeon, periodontist), and provider IDs map to custom fields on the Person record. In Nutshell, these are text fields (Primary_Provider__c, Provider_Specialty__c). Provider assignment on appointments also migrates as a custom field since Nutshell Activities have no native provider concept.
axiUm Dental
Appointment
Nutshell
Activity (call/meeting)
1:1axiUm appointments map to Nutshell Activities (type='Meeting' for scheduled visits, type='Call' for follow-up calls). The appointment date becomes the Activity due date, the provider becomes Primary_Provider__c, the appointment type (restorative, hygiene, emergency) maps to Appointment_Type__c, and the status (completed, no-show, cancelled) maps to a custom status field. Original timestamps are preserved.
axiUm Dental
Recall / Patient Reminder
Nutshell
Activity (task)
1:1axiUm recall entries (6-month hygiene recall, annual exam) map to Nutshell Tasks with a due date matching the recall date and a subject like 'Hygiene Recall Due'. Nutshell's Tasks serve as the recall mechanism in the CRM workflow — your team can then convert overdue recalls into booked appointments manually.
axiUm Dental
Transaction / Billing Ledger
Nutshell
Custom fields on Person
1:1axiUm transaction history (charges, payments, adjustments, insurance payments, patient balance) has no Nutshell equivalent. We preserve total_charges, total_payments, insurance_paid, and current_balance as custom currency fields on the Person record. The full itemized ledger is exported as a CSV and attached to the Person record as a reference file.
axiUm Dental
Treatment Plan
Nutshell
Note + Custom fields on Person
1:1axiUm treatment plan entries (procedure description, ADA code, estimated cost, status) map to a Nutshell Note attached to the Person record summarizing the plan. Key codes and statuses are also stored in custom fields (CDT_Code__c, Treatment_Status__c) so your team can query and report on planned treatments without opening the note.
axiUm Dental
Clinical Note / Medical Alert
Nutshell
Note + Custom fields on Person
1:1axiUm medical alerts (allergies, conditions requiring antibiotic pre-medication, medical history flags) map to a Nutshell Note on the Person record plus a custom checkbox field (Medical_Alert__c) set to true when alerts are present. Clinical notes containing PHI should be flagged as sensitive during migration planning given Nutshell's standard SaaS security model.
axiUm Dental
Attachment / Consent Form
Nutshell
File attached to Person
1:1axiUm attachments and scanned consent forms (HIPAA acknowledgment, treatment consent, imaging release) migrate as files attached to the corresponding Nutshell Person record. File size limits apply — documents over 25MB should be split or compressed before upload. We download, package, and re-upload each file with its original filename for traceability.
axiUm Dental
User / Owner
Nutshell
Person → assigned Owner
1:1axiUm staff and faculty user accounts are matched to Nutshell users by email address. Unmatched users are flagged before migration — your team either creates Nutshell accounts for them first or assigns their patients and appointments to a designated fallback owner. No record lands in Nutshell without an assigned owner.
axiUm Dental
Custom Module (Lab Order, Dispensary, etc.)
Nutshell
Note or Custom fields on Person
1:1axiUm Plus modules (Lab Tracking, Dispensary, Inventory) hold operational data that does not map to a CRM object. We extract module records as structured data, summarize them into a Nutshell Note on the relevant Person or Company, and surface key fields (lab case status, material used) as custom fields where they support sales or service follow-up workflows.
| axiUm Dental | Nutshell | Compatibility | |
|---|---|---|---|
| Patient | Person1:1 | Fully supported | |
| Patient → Primary Insurance | Person (custom fields)1:1 | Fully supported | |
| Company / Practice | Company1:1 | Fully supported | |
| Provider / Faculty | Person (custom fields)1:1 | Fully supported | |
| Appointment | Activity (call/meeting)1:1 | Fully supported | |
| Recall / Patient Reminder | Activity (task)1:1 | Fully supported | |
| Transaction / Billing Ledger | Custom fields on Person1:1 | Fully supported | |
| Treatment Plan | Note + Custom fields on Person1:1 | Fully supported | |
| Clinical Note / Medical Alert | Note + Custom fields on Person1:1 | Fully supported | |
| Attachment / Consent Form | File attached to Person1:1 | Fully supported | |
| User / Owner | Person → assigned Owner1:1 | Fully supported | |
| Custom Module (Lab Order, Dispensary, etc.) | Note or Custom 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.
axiUm Dental gotchas
Citrix dependency for on-premise deployments
Custom form schema varies per institution
MiPACS imaging data lives outside axiUm's database
CDT code versioning drift between systems
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 source schema and identify export vectors
FlitStack AI connects to your axiUm instance via the exposed API endpoints (patients, appointments, transactions, providers, custom modules) and performs a schema discovery pass. We catalog every object, field, and relationship present in your axiUm database — identifying custom fields, module extensions, and any deprecated or legacy field names from prior axiUm versions. This discovery pass generates the migration map before any data moves.
Design Nutshell custom field schema
Before data is written to Nutshell, we create all required custom fields on the Person, Company, and Activity objects: Insurance_Carrier__c (text), Insurance_Group__c (text), Insurance_Subscriber_ID__c (text), CDT_Code__c (text), Medical_Alert__c (checkbox), Appointment_Type__c (text), Primary_Provider__c (text), Provider_Specialty__c (text), Account_Balance__c (currency), Total_Charges__c (currency), Total_Payments__c (currency), Insurance_Paid__c (currency), and Source_System_ID__c (text). We use Nutshell's API to create these fields programmatically so the schema is ready before migration validation runs. The schema design phase also documents each field's data type, validation rules, and which source axiUm field maps to it, providing a complete field specification reference for the migration team.
Resolve owners and create Nutshell user accounts
axiUm staff and faculty accounts are matched to Nutshell users by email address. Unmatched users are flagged with their axiUm user record and email — your team creates the Nutshell account first or assigns those patients/appointments to a designated fallback owner. No patient record, company, or activity lands in Nutshell without a resolved OwnerId. This step gates the entire migration because Nutshell requires an owner reference on all records.
Migrate companies and people in dependency order
Nutshell requires a Company to exist before a Person can be linked to it via the 'belongs_to' relationship. We migrate Companies first (practice names, referring dentists, DSO parent entities), then Persons (patients) with their Company linkage, then Activities (appointments, tasks, notes) with Person linkage. This sequencing ensures foreign-key integrity — a patient record with an unresolvable Company reference would land as an orphan in Nutshell.
Run sample migration with field-level diff
A representative sample (typically 100–300 records spanning patients, appointments, transactions, and attachments) migrates to Nutshell first. We generate a field-level diff showing every mapped value from axiUm against the corresponding Nutshell field — you verify that insurance fields, appointment types, and provider names landed correctly before the full run commits. Any mapping errors are corrected and the sample re-runs until the diff is clean.
Execute full migration with delta-pickup window
The full dataset migrates: all patients, companies, appointments, transactions, treatment plan summaries, medical alerts, and attachments. During cutover, your team continues working in axiUm — FlitStack AI maintains scoped read access. A 24–48 hour delta-pickup window after the initial run captures any records modified or created in axiUm during the switch. An audit log records every operation, and one-click rollback reverts the Nutshell instance to its pre-migration state if reconciliation uncovers data integrity issues.
Platform deep dives
axiUm Dental
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 axiUm Dental 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
axiUm Dental: Not publicly documented.
Data volume sensitivity
axiUm Dental 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 axiUm Dental to Nutshell migration scoping. Not seeing yours? Book a call.
Walk through your axiUm Dental 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 axiUm Dental
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.