CRM migration

Migrate from Dentrix to Twenty CRM

Field-level mapping, validation, and rollback between Dentrix and Twenty CRM. We move data and schema; workflows are rebuilt natively in Twenty CRM.

Dentrix logo

Dentrix

Source

Twenty CRM

Destination

Twenty CRM logo

Compatibility

92%

11 of 12

objects map 1:1 between Dentrix and Twenty CRM.

Complexity

BStandard

Timeline

48–72 hours

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Dentrix stores dental practice data in a domain-specific model built around patients, providers, appointments, treatment plans, insurance carriers, and clinical notes. Twenty CRM operates as a generic business CRM with standard objects for People, Companies, Opportunities, Notes, and Tasks, plus support for custom objects and custom fields per workspace. The migration challenge is translating Dentrix's clinical and billing constructs into Twenty's commercial CRM schema without losing patient context or appointment history. We extract Dentrix data via the platform's export tools and API where available, transform patient records into Twenty People objects, referring providers into Companies, open treatment cases into Opportunities, and appointment/clinical history into Tasks and Notes. Insurance information and billing ledger data require custom fields or custom objects in Twenty since the platform has no native insurance or accounts-receivable model. Custom dental properties (procedure codes, clinical flags, insurance plan types) migrate as custom fields on the relevant objects. What does not transfer: Dentrix workflows, clinical imaging files (X-rays, CBCT scans), integration configurations with imaging hardware, and practice-specific automation rules. These must be rebuilt in Twenty's Settings → Data Model and Settings → Workflows sections. The migration uses a staged CSV import approach with Twenty's documented import order (Companies → People → Opportunities → Custom objects) to maintain referential integrity.

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

Dentrix logo

Dentrix

What's pushing teams away

  • Practices report that customer support has become harder to reach, with at least one review stating monthly account closure threats, undermining trust.
  • The UI is described as visually dull and outdated, with a dated color scheme and interface that frustrates front-office staff daily.
  • Staff find the feature depth overwhelming — many practices report using only a fraction of available functionality despite years on the platform.
  • Growing interest in cloud-based alternatives (Open Dental, Curve Dental, CareStack, Dentrix Ascend) driven by the desire for automatic updates, mobile access, and lower upfront server costs.
  • Practices report that Dentrix G runs on aging server hardware and struggles with performance as database files grow over years of use.

Choosing

Twenty CRM logo

Twenty CRM

What's pulling them in

  • Top open-source CRM on GitHub with 40.6K stars, giving teams full source code access and infrastructure ownership without per-feature licensing surprises.
  • Free self-hosting under AGPL-3.0 means unlimited users and custom objects for the cost of cloud infrastructure alone, typically $20–100/month.
  • Pricing page explicitly mocks competitors for charging add-on fees for API access, webhooks, and workflows — transparency that resonates with RevOps teams burned by Salesforce.
  • Unlimited custom objects and fields with no price impact, letting teams shape the data model to their business rather than forcing business into rigid schemas.
  • Modern TypeScript/React/PostgreSQL stack means developer-led teams can extend, self-host, or integrate without fighting legacy architecture.

Object mapping

How Dentrix objects map to Twenty CRM

Each row shows how a Dentrix object lands in Twenty CRM, including any object-level transformations, lookup resolution, or schema-design dependencies.

Typical mapping — final map is confirmed during the sample migration step.

Dentrix

Patient

maps to

Twenty CRM

People

1:1
Fully supported

Dentrix Patient record maps directly to Twenty People. The patient name, date of birth, contact information, address, and medical alerts translate as direct fields or custom fields on the People object. Medical alerts (allergies, conditions) require a custom Alert__c multi-select field in Twenty since the platform has no native clinical-alert mechanism.

Dentrix

Referring Provider / Doctor

maps to

Twenty CRM

Company

1:1
Fully supported

Referring dentists, oral surgeons, and specialist offices stored as referring providers in Dentrix map to Twenty Company records. Company name, practice name, address, phone, and NPI number transfer as standard Company fields. Referring provider type (oral surgeon, endodontist, etc.) maps as a custom Type__c pick-list on the Company object.

Dentrix

Insurance Carrier

maps to

Twenty CRM

Company (secondary)

many:1
Fully supported

Insurance carriers from Dentrix (Delta Dental, Cigna Dental, MetLife, etc.) merge into a separate Company record type in Twenty, distinguished from referring providers via a custom Company_Type__c field set to 'Insurance Carrier'. This allows linking patients to their insurance plan Company record while keeping the insurer separate from referral sources.

Dentrix

Appointment / Visit

maps to

Twenty CRM

Task

1:1
Fully supported

Dentrix appointments map to Twenty Tasks linked to the People record. Each appointment task captures the appointment date, provider assigned, procedure codes performed, and status (completed, no-show, cancelled). Recurring recall appointments become recurring Tasks in Twenty — the platform supports due date-based recurring tasks on the Task object.

Dentrix

Treatment Plan

maps to

Twenty CRM

Opportunity

1:1
Fully supported

Open treatment plans in Dentrix map to Twenty Opportunities representing the remaining treatment value. The Opportunity Stage maps to treatment plan status (Proposed, Scheduled, In Progress, Completed, Cancelled). Treatment plan procedure codes and estimated fees transfer as line items using Twenty's Opportunity model or as custom fields if the practice uses a simplified single-value approach.

Dentrix

Clinical Note / Progress Note

maps to

Twenty CRM

Note

1:1
Fully supported

Dentrix clinical progress notes attach to the Patient record and map to Twenty Notes linked to the People record. We preserve the original note date, provider author, and full note body. Clinical notes use Twenty's rich-text Note capability, but per Twenty's documentation, Notes are free-form and not searchable via the standard filter — they appear in the record timeline.

Dentrix

Insurance Plan (per patient)

maps to

Twenty CRM

Custom Object or Custom Fields on People

1:1
Fully supported

Patient-specific insurance details (carrier, group number, subscriber ID, eligibility dates, coordination of benefits) require custom fields on the People object: Insurance_Carrier__c (lookup to Company), Group_Number__c, Subscriber_ID__c, Eligibility_Start__c, Eligibility_End__c, and Subscriber_Relationship__c. These fields must be created in Twenty Settings → Data Model before the People import runs.

Dentrix

Ledger / Billing Record

maps to

Twenty CRM

Custom Object: Ledger_Entry__c

1:1
Fully supported

Dentrix billing ledger entries (charges, payments, adjustments, insurance payments, write-offs) do not map to any standard Twenty object. We create a custom Ledger_Entry__c object with fields for Entry_Date__c, Type__c (charge/payment/adjustment/writeoff), Amount__c, Description__c, Provider__c (relation to Company), and Patient__c (relation to People). Each entry links to the People record. This requires Twenty Organization-tier or a self-hosted instance to create multiple custom objects.

Dentrix

Procedure Code (CDT codes)

maps to

Twenty CRM

Custom Field on Task or Custom Object: Procedure_Code__c

1:1
Fully supported

CDT (Current Dental Terminology) procedure codes performed at each appointment do not have a native equivalent in Twenty. We map them as a custom Procedure_Code__c text field on the Task object, storing the CDT code (e.g., D0120, D2750) and description. Practices using procedure codes for production tracking may prefer a separate Procedure__c custom object linked to Task for more granular reporting.

Dentrix

Document / Attachment (non-imaging)

maps to

Twenty CRM

File (Twenty native)

1:1
Fully supported

Dentrix documents attached to patient charts (consent forms, insurance cards, referral letters in PDF/Word format) export from Dentrix and re-upload to Twenty as native file attachments on the People record. We download the files from Dentrix's document management path and attach them to the corresponding People record during migration. PDF and image files re-host directly; Word documents may require format conversion.

Dentrix

User / Provider (Staff member)

maps to

Twenty CRM

WorkspaceMember

1:1
Fully supported

Dentrix provider and staff accounts (dentists, hygienists, office managers, billing staff) resolve against Twenty WorkspaceMembers by email match. If a provider email exists in Dentrix and a matching email invite is sent to Twenty before migration, records assign to the correct owner. Unmatched providers flag as 'Unassigned Provider' and must be resolved post-migration.

Dentrix

Imaging (X-rays, photos, CBCT)

maps to

Twenty CRM

No equivalent

1:1
Fully supported

Dentrix imaging files (bitewing X-rays, panoramic radiographs, intraoral photos, CBCT scans in proprietary or DICOM format) have no migration path to Twenty CRM. The imaging viewer in Twenty is not designed for clinical radiology. We export a manifest of imaging file names and dates linked to the patient People record, but the actual image files must remain in Dentrix or be exported separately to a dedicated dental imaging PACS system.

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.

Dentrix logo

Dentrix gotchas

High

No public API for Dentrix G data extraction

High

Imaging files stored separately from patient records

Medium

Balance-forward billing ledger requires explicit handling

Medium

In-flight insurance claims must clear before cutover

Low

Custom fields vary per practice with no standard schema

Twenty CRM logo

Twenty CRM gotchas

High

Import order is enforced and critical

High

Export limited to 20,000 records and visible columns only

Medium

Soft-deleted records count toward uniqueness and trigger restores

Medium

API rate limits cap at 200 req/min on Organization tier

Low

No native email sequences — follow-up cadences require external tools

Pair-specific challenges

  • Dentrix clinical imaging (X-rays, CBCT, intraoral photos) has no migration path to Twenty CRM

    Dentrix stores radiographic images, photos, and CBCT scans in a proprietary image path (Trophy, DEXIS, or Schick integration depending on the practice's imaging hardware). Twenty CRM's file storage is designed for standard documents and has no DICOM viewer or clinical imaging module. We can export a manifest of image file names, dates, and tooth references linked to the patient People record, but the actual image files must remain in Dentrix or be exported separately to a dental PACS system. Practices that rely on the imaging module for clinical decision-making should plan a parallel storage strategy for radiographs before cutting over to Twenty.

  • Twenty's People object lacks native medical-alert and clinical-flag fields — custom field creation is mandatory before import

    Twenty ships with a minimal set of standard fields on the People object: name, email, phone, job title, company, and a few relation fields. There is no native field for medical alerts, allergies, conditions, medications, or clinical flags that Dentrix stores directly on the patient chart. Per Twenty's own documentation, fields must exist before CSV import — you cannot create fields during import. We pre-create custom fields (Alert__c multi-select, Medication__c text, Condition__c text) in Twenty Settings → Data Model before running the import. Practices with many clinical custom fields in Dentrix should budget extra schema design time for mapping each one.

  • Billing ledger migration requires a custom object that only Organization-tier or self-hosted Twenty supports

    Dentrix maintains a full patient accounting ledger with charges, payments, adjustments, insurance payments, and write-offs per patient — a model with no equivalent in Twenty's standard object set. To migrate billing data, we create a Ledger_Entry__c custom object with multiple custom fields. However, Twenty's Pro Cloud tier caps custom objects at 10. Practices that need both a Ledger custom object and a Treatment Plan custom object (plus insurance carrier custom fields) may exceed the Pro limit. Organization Cloud ($19/user/month) or self-hosted Twenty removes the custom object cap entirely. Practices must choose their Twenty tier before migration planning to ensure the schema fits.

  • On-premise Dentrix G4 uses legacy .dat file storage — export requires coordination with the practice IT team

    Dentrix G4 (the long-running on-premise version) stores data in legacy .dat file formats and a database structure that is not directly accessible via the Dentrix API. Exporting patient records, ledger entries, and documents requires using the Dentrix Database Export utility or working with the practice IT team to access the underlying SQL Server or Pervasive database. This is a known friction point documented in Reddit r/Dentistry threads where practices attempting to export describe it as a 'nightmare'. We coordinate with the practice's IT provider to run the export before migration begins — this step alone can add 3–7 days to the overall project timeline compared to cloud-first Dentrix Ascend exports.

  • Twenty's import order constraint means Companies must migrate before People — circular references require manual resolution

    Twenty's CSV import requires uploading objects in dependency order: Companies first (the 'one' side of the People-Company relationship), then People (linked to Companies via companyId), then Opportunities, then Custom objects. If Dentrix contains referring providers linked to patients who are also linked back to those providers in a way that creates a circular reference in the import files, Twenty's import will fail silently on those records. We detect circular company-person links during the audit phase and resolve them by designating one record as the primary Company before generating the import files. Practices with complex multi-location referral networks should flag this during discovery.

Migration approach

Six steps for a successful Dentrix to Twenty CRM data migration

  1. Audit Dentrix data export and define the Twenty schema plan

    We run a data audit against the Dentrix export (cloud API or on-premise database export) to inventory patient records, insurance entries, treatment plans, ledger transactions, provider records, and documents. We identify data quality issues (duplicate patients, missing email addresses, incomplete insurance records) and surface them before migration. Simultaneously, we deliver a Twenty schema plan: a list of custom fields and custom objects to create in Settings → Data Model, their types, and which Twenty tier (Pro vs Organization) is required. This step produces the migration blueprint and a data-cleanse checklist for the practice team.

  2. Create Twenty custom fields and custom objects before import

    Per Twenty's documentation, fields must exist before CSV import — the import creates records, not fields. We (or the practice admin) create all required custom fields in Settings → Data Model: Medical_Alert__c, Insurance_Carrier__c (lookup to Company), Group_Number__c, Subscriber_ID__c, Eligibility_Start__c, Eligibility_End__c, Subscriber_Relationship__c on People; and if the Organization tier is chosen, Ledger_Entry__c and its fields. We also configure the Opportunity pipeline stages to match the practice's treatment plan statuses (Proposed, Scheduled, In Progress, Completed, Cancelled). The Twenty workspace must be ready before any data lands.

  3. Export, transform, and load data in Twenty's required import order

    We export Dentrix data in CSV format using the platform's export tools. Data transforms according to the field mapping document: insurance carriers generate Company records, patients generate People records, appointments generate Tasks, open treatment plans generate Opportunities, and ledger entries generate Ledger_Entry__c records. We load data into Twenty in the documented order: Companies first, then People (linked via companyId), then Opportunities (linked to People and Company), then Custom objects last. Owner resolution matches Dentrix provider email addresses to Twenty WorkspaceMember emails — unmatched owners flag in a pre-migration report.

  4. Run a sample migration with field-level diff before full commit

    A representative slice of records — typically 100–500 patients spanning different appointment histories, insurance configurations, and treatment plan statuses — migrates first. We generate a field-level diff between the Dentrix source values and the Twenty destination values for every mapped field. The practice team reviews the diff to verify medical alert migration, insurance carrier linking, treatment plan-to-Opportunity mapping, and owner resolution. Any field mapping errors or data quality issues surface here before the full run commits. This step typically runs over 24–48 hours.

  5. Full migration with delta-pickup window and one-click rollback

    The full dataset migrates against Twenty. A delta-pickup window (24–48 hours after the primary run) captures any new appointments, ledger entries, or patient updates made in Dentrix during the migration window. All operations are logged in an audit log. If reconciliation fails — a record count mismatch, a critical field that failed to map, or a custom object that didn't create correctly — one-click rollback reverts the Twenty workspace to its pre-migration state so the team can re-run without data residue.

Platform deep dives

Context on both ends of the pair

Dentrix logo

Dentrix

Source

Strengths

  • Mature, feature-rich practice management covering scheduling, billing, clinical charting, and analytics in one platform.
  • Strong insurance claims workflow with direct submission pipelines and established payer relationships.
  • Deep integration with DEXIS and Schick imaging hardware from Henry Schein One.
  • Comprehensive practice metrics and reporting dashboards for monitoring production and collections.
  • Established 35-year market presence with a large trained workforce and active user community.

Weaknesses

  • Server-based architecture requires dedicated on-premise hardware, IT maintenance, and manual backup management.
  • No public REST API for Dentrix G — data extraction requires direct database access or third-party tools.
  • Dated user interface with poor visual design that frustrates front-office staff.
  • Increasingly difficult customer support, with multiple reviews citing account issues and poor response times.
  • High total cost of ownership for the cloud version ($40,000–$60,000 annually) relative to cloud-native competitors.
Twenty CRM logo

Twenty CRM

Destination

Strengths

  • AGPL-3.0 open-source license with full source code on GitHub — no vendor lock-in, no sunset risk.
  • Unlimited users and unlimited custom objects on self-hosted, with no feature gating based on headcount.
  • REST and GraphQL APIs available on all paid tiers, not locked behind an enterprise add-on fee.
  • MCP server and webhooks shipped as standard features, not premium upgrades.
  • Modern PostgreSQL-backed data model that developer teams can query, extend, and self-host.

Weaknesses

  • Recent v1.0 release means limited production hardening compared to CRMs with multi-year operational track records.
  • No native email sequencing or sales engagement tools — follow-up cadences require a separate platform.
  • No native two-way email sync or inbox integration, requiring third-party connectors for full activity logging.
  • Self-hosting 'free' pricing hides real infrastructure and DevOps costs that stack up over time.
  • Workflow automation is functional but lacks the complexity needed for sophisticated multi-step sales motions.

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 Dentrix and Twenty CRM.

  • 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

    Dentrix: Not publicly documented for Dentrix Ascend API Exchange.

  • Data volume sensitivity

    B

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

Estimator

Estimate your Dentrix to Twenty CRM 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 Dentrix to Twenty CRM data migrations

Answers to the questions buyers ask most during Dentrix to Twenty CRM migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your Dentrix to Twenty CRM migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most Dentrix-to-Twenty migrations complete in 48–72 hours of clock time for practices with fewer than 25,000 patient records. On-premise Dentrix G4 setups add 3–7 days for data export coordination with the practice IT team. Practices with over 25,000 records or complex custom object schemas (billing ledger, treatment plan custom objects) extend to 7–14 days. The longest single step is creating the Twenty custom field schema and the audit/cleanse phase before any data moves.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Dentrix.
Land in Twenty CRM, 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