CRM migration

Migrate from axiUm Dental to Nutshell

Field-level mapping, validation, and rollback between axiUm Dental and Nutshell. We move data and schema; workflows are rebuilt natively in Nutshell.

axiUm Dental logo

axiUm Dental

Source

Nutshell

Destination

Nutshell logo

Compatibility

100%

12 of 12

objects map 1:1 between axiUm Dental and Nutshell.

Complexity

BStandard

Timeline

1–3 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

axiUm Dental logo

axiUm Dental

What's pushing teams away

  • Outdated desktop-first interface requires significant user training, and multi-step workflows for completing post-treatment documentation frustrate clinical staff and slow patient throughput.
  • Limited visibility for custom medical alerts — non-standard health history items that should flag prominently in a patient record require IT configuration to display correctly, creating patient safety risks.
  • Transitioning from a dental school environment to a commercial dental service organization reveals that axiUm's student evaluation and competency tracking features are overkill for private practice workflows.
  • Customer support responsiveness is inconsistent, with institutional IT staff often left to resolve configuration issues without vendor escalation paths.
  • Proprietary data schema and limited published API documentation make third-party integrations and data portability difficult without Exan Professional Services involvement.

Choosing

Nutshell logo

Nutshell

What's pulling them in

  • Lowest cost entry point among mid-market CRMs—Foundation plan starts at $13/user/month, making it accessible for teams validating CRM fit before committing.
  • Integrated sales automation and email sequencing on Pro plans without requiring a separate email marketing platform, per verified Capterra reviews.
  • Consistently praised for intuitive interface and fast onboarding, with case studies reporting 100% team adoption rates within initial deployment periods.
  • Strong customer support responsiveness cited across G2 reviews, with dedicated support tiers available on Enterprise plans.
  • Native integrations with WhatsApp, Facebook Messenger, Instagram, and Slack reduce reliance on third-party middleware for common communication channels.

Object mapping

How axiUm Dental objects map to Nutshell

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

maps to

Nutshell

Person

1:1
Fully supported

axiUm 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

maps to

Nutshell

Person (custom fields)

1:1
Fully supported

Insurance 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

maps to

Nutshell

Company

1:1
Fully supported

For 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

maps to

Nutshell

Person (custom fields)

1:1
Fully supported

axiUm 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

maps to

Nutshell

Activity (call/meeting)

1:1
Fully supported

axiUm 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

maps to

Nutshell

Activity (task)

1:1
Fully supported

axiUm 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

maps to

Nutshell

Custom fields on Person

1:1
Fully supported

axiUm 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

maps to

Nutshell

Note + Custom fields on Person

1:1
Fully supported

axiUm 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

maps to

Nutshell

Note + Custom fields on Person

1:1
Fully supported

axiUm 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

maps to

Nutshell

File attached to Person

1:1
Fully supported

axiUm 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

maps to

Nutshell

Person → assigned Owner

1:1
Fully supported

axiUm 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.)

maps to

Nutshell

Note or Custom fields on Person

1:1
Fully supported

axiUm 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.

Gotchas + challenges

What specifically takes care here

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 logo

axiUm Dental gotchas

High

Citrix dependency for on-premise deployments

Medium

Custom form schema varies per institution

High

MiPACS imaging data lives outside axiUm's database

Medium

CDT code versioning drift between systems

Nutshell logo

Nutshell gotchas

High

Contact tier limits enforced on import

Medium

No bulk API endpoint requires paginated extraction

Medium

Email sequences not exportable via API

Medium

Foundation plan disables key sales features

Pair-specific challenges

  • Clinical dental fields have no CRM equivalent and must become custom fields

    axiUm stores CDT procedure codes, tooth numbers, perio pocket readings, odontogram conditions, and treatment plan status per visit. Nutshell has no clinical data model — these fields have no native equivalent. We map CDT codes to a custom text field (CDT_Code__c) and treatment plan summaries to a Note attached to the Person, but the granular per-tooth charting (Quadrant, Tooth Number, Surface, Condition) cannot be represented in Nutshell's flat field structure. Your team should export axiUm clinical charts as PDFs and attach them to the patient record if the historical detail is required for compliance or referral documentation.

  • axiUm API rate limits require staged export windows

    axiUm's API (v7.04 and above) enforces per-connection rate limits that require pagination across large patient record sets. For practices with 10,000+ patients and multi-year appointment histories, a single bulk export can hit throttling and return partial results. FlitStack AI implements exponential backoff and segmented export windows — we export patients, appointments, and transactions in separate passes, with checkpointing at each stage so a throttled run can resume without duplicating already-exported records.

  • Insurance EDI billing data does not transfer to Nutshell

    axiUm routes electronic claims (837P format) through DentalXChange and tracks EDI status, claim IDs, and remittance advice. Nutshell has no billing module and no EDI integration capability. We preserve claim-level metadata (claim date, amount billed, amount approved, payment date) as custom fields on the Person record, but the EDI claim workflow itself terminates with migration — your team must manage insurance billing through your existing EDI clearinghouse or adopt a separate dental billing tool post-migration.

  • Nutshell's standard SaaS model lacks HIPAA-grade PHI controls

    axiUm's Power Admin module provides field-level access controls, role-based HIPAA auditing, and encryption options (Use Advanced Encryption in System Options) that satisfy academic dental compliance requirements. Nutshell's standard data security uses role-based access and audit logs but does not offer field-level encryption or a HIPAA Business Associate Agreement (BAA) as a default feature. Practices subject to HIPAA that store PHI in Nutshell custom fields (medical history, treatment notes, insurance IDs) should consult with Nutshell's enterprise team about a BAA before migrating sensitive clinical data into the platform.

  • axiUm student evaluation and faculty grading data has no CRM home

    axiUm's Evaluations module tracks student competency assessments, grades, and faculty comments tied to specific patient encounters — this is academic-specific data with no counterpart in Nutshell's sales-focused data model. We export the evaluation summaries as attachments to the relevant patient record (linking faculty evaluator name, student name, and date as metadata in the attachment filename), but the structured rubric data and grading scores cannot map to any Nutshell object or custom field. This data should be exported from axiUm separately and archived per institutional retention policy.

Migration approach

Six steps for a successful axiUm Dental to Nutshell data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Context on both ends of the pair

axiUm Dental logo

axiUm Dental

Source

Strengths

  • Market-leading position in North American dental academic institutions with 90%+ penetration.
  • Comprehensive HIPAA-compliant EHR combining clinical, financial, and educational data in one system.
  • Modular architecture allows institutions to license only the modules relevant to their clinical and educational workflows.
  • Citrix-delivered desktop access and web-based PatientAccess and DoctorAccess portals provide deployment flexibility.
  • CODA accreditation compliance built into reporting and student competency tracking.

Weaknesses

  • Desktop-first application architecture with an outdated user interface that creates a steep learning curve for new users.
  • No publicly available API documentation for customers — the REST API exists only in CE 7.04+ and requires a software maintenance agreement to access.
  • Medical alert configuration lacks an intuitive interface, requiring IT-level setup to surface non-standard health flags.
  • Multi-step treatment completion workflow disperses post-care documentation across three or four separate areas of the application.
  • Limited pricing transparency with no published tiers — sales engagement required to obtain a quote.
Nutshell logo

Nutshell

Destination

Strengths

  • Simple, intuitive interface with minimal learning curve for sales teams new to CRM
  • Per-seat pricing is transparent and predictable, with annual billing reducing monthly cost
  • Full data export tool available for all account data including backups
  • Open JSON-RPC API allows programmatic access to all core objects
  • Native multichannel engagement (email, SMS, WhatsApp) without third-party add-ons for communication

Weaknesses

  • Reporting and analytics are considered weak, requiring manual Excel exports for detailed analysis
  • No bulk API endpoint—migration requires paginated API reads that must be rate-limited carefully
  • JSON-RPC API is less common than REST, requiring custom integration code compared to standard REST CRMs
  • Add-on costs (Forms, Nutshell IQ, Email Marketing) are per-company charges that stack on top of per-seat pricing
  • Feature restrictions on entry-level plans mean teams often need mid-tier to get basic automation

Complexity grading

How hard is this migration?

Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across axiUm Dental and Nutshell.

  • Object compatibility

    B

    1 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    axiUm Dental: Not publicly documented.

  • Data volume sensitivity

    B

    axiUm Dental doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your axiUm Dental to Nutshell migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about axiUm Dental to Nutshell data migrations

Answers to the questions buyers ask most during axiUm Dental to Nutshell migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

A typical dental practice with fewer than 5,000 patient records completes in 1–3 weeks of project time. The planning and schema design phase takes 3–5 days, the sample migration and validation another 3–5 days, and the full cutover with delta-pickup runs over a 48–72 hour window. Multi-location practices or those with extensive transaction histories and custom Plus-module data extend to 3–5 weeks, primarily due to the volume of appointment history that must be exported in rate-limited API passes.

Adjacent paths

Related migrations to explore

Ready when you are

Move from axiUm Dental.
Land in Nutshell, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day