Migrate your Open Dental data
Self-hosted dental practice management software for Windows that owns its own database. Practices that need full data ownership and low per-seat cost choose it; those without IT staff often leave for cloud alternatives.
In its favor
Why people choose Open Dental
The signal that keeps Open Dental on the shortlist. Sourced from G2, Capterra, and customer scoping calls.
Practices cite the per-seat cost as significantly lower than Dentrix or Eaglesoft, especially for multi-location groups that have negotiated support contracts with Patterson.
Open-source architecture means the database schema is documented and data exports are straightforward for practices that want ownership and control of their records.
The community of users and independent trainers produces a deep library of how-to content, forum answers, andYouTube walkthroughs that make self-service troubleshooting practical.
Multi-location practices value the Clinics feature for operating separate locations from a single database while keeping reports segmented.
Practitioners upgrading from paper or older server-based systems find the feature set covering appointments, charting, billing, and Rx to be a complete practice management solution.
Open Dental runs on a local Windows server that the practice must maintain; offices without dedicated IT staff experience server crashes, slowdowns, and update failures as operational risk.
The interface and feature set have a dated UX that newer staff find unintuitive compared to cloud-first alternatives, leading to training overhead and reduced staff satisfaction.
Scaling beyond two or three locations requires significant configuration work (Replication, CEMT, Enterprise features) that demands technical expertise most solo or small-group practices lack.
Performance degrades with large patient bases and years of transaction history stored in the same database, causing slow queries and screen delays during peak hours.
Reasons to switch
Why people leave Open Dental
The recurring reasons buyers give for replacing Open Dental. Presented as facts, not knocks.
Platform scorecard
Strengths, weaknesses, and where Open Dental fits
Grades across six dimensions, plus a SWOT-style view of where the platform shines and where it falls short.
SWOT — strengths, weaknesses, and use-case fit
Strengths
Weaknesses
Where it works
Where it struggles
Pricing tiers
Open Dental pricing overview
Open Dental charges a per-provider monthly subscription that includes the software license and support. There is no per-patient or per-record billing. After the first year, many practices negotiate multi-year support agreements. Third-party cloud hosting through providers like Darkhorse Tech adds a recurring fee that ranges from $300 to $800 per month depending on the provider and included services.
Per-Seat License
Tier 1 of 3
~$169/month per active provider (standard tier)
What's included
Need help selecting your CRM?
Book a free 30 minute consultationPricing is informational. FlitStack AI does not bill on Open Dental's schedule — see our quote-based pricing →
What gets migrated
Open Dental object support
Object-by-object support for Open Dental migrations. Per-pair details surface during scoping.
Patients
Fully supportedThe core patient record (PatNum) is the primary key across the entire system. All clinical, financial, and communication data links back to Patients. We migrate patient demographics, contact info, billing guarantors, and super-family groupings. Family tab structure is preserved by mapping guarantor relationships.
PatFields
Mapping requiredCustom patient fields support Text, PickList, Date, Checkbox, and Currency types. Field definitions (PatFieldDefs) must be exported separately from values. We map both definitions and values, and resolve picklist items by name against the destination system's equivalent lists.
Appointments
Fully supportedAppointment records include provider, operatory, start/end times, recall linking, confirmation status, and appt field values. We preserve appointment history including completed, cancelled, and no-show records and reconstruct the recall chain linking.
Procedures (ProcedureLogs)
Fully supportedClinical procedure records include tooth numbers, surfaces, ADA codes, provider, date performed, fee, and status. We map procedure codes to destination equivalents and preserve treatment plan stages, attachments, and benefit insurance estimates.
Claims
Fully supportedClaims link patients, providers, procedures, and insurance plans. We migrate claim status history, supplemental claim records, tracking entries, and associated ClaimProcs. The ClaimPayments table is also migrated to preserve the insurance payment ledger.
PayPlans
Mapping requiredPayPlans (dynamic) support structured payment schedules with PayPlanLinks to individual procedures or charges. We preserve the plan terms, linked items, and completed pay splits. Some legacy PayPlan formats may require mapping review for date-range and adjustment logic.
Documents
Mapping requiredDocuments are stored as files (images, PDFs) with database entries referencing patient folders. We export document metadata, category assignments, and file references. Actual binary files must be exported from the A-to-Z folder on the server separately from the database export. Radiographs require a separate x-ray bridge and are not included in standard migrations.
Insurance Plans (InsPlans)
Fully supportedInsurance plan definitions, fee schedules, coverage categories (CovCats), and coverage spans migrate as structured data. PatPlans linking patients to insurance carriers are preserved. We map carrier names and plan numbers but verify benefit percentages against destination plan structures.
Providers
Fully supportedProvider records include name, credentials, NPI, fee schedules, and scheduling rules. We map provider assignments across procedures, appointments, claims, and pay splits. Provider specialties are preserved as provider properties.
Clinics
Mapping requiredThe Clinics feature is only active when enabled. Multi-location practices may have Clinics disabled. We detect the Clinics setting during pre-migration scoping and map clinic assignments only where the feature is in use. Practices running separate databases per location do not use this object.
Providers (Userods)
Mapping requiredUser accounts and security permissions are separate from provider clinical records. We map user logins, role assignments, and preference overrides. Password hashes do not transfer; staff will need to reset credentials on the destination system.
Sheets (Custom Forms)
Mapping requiredCustom sheets use a proprietary XML format that only imports into another Open Dental database. We export sheet definitions and data, but the XML structure requires conversion for any non-Open Dental destination. Sheet data attached to patient records is migrated as structured fields.
| Object | Support | Notes |
|---|---|---|
| Patients | Fully supported | The core patient record (PatNum) is the primary key across the entire system. All clinical, financial, and communication data links back to Patients. We migrate patient demographics, contact info, billing guarantors, and super-family groupings. Family tab structure is preserved by mapping guarantor relationships. |
| PatFields | Mapping required | Custom patient fields support Text, PickList, Date, Checkbox, and Currency types. Field definitions (PatFieldDefs) must be exported separately from values. We map both definitions and values, and resolve picklist items by name against the destination system's equivalent lists. |
| Appointments | Fully supported | Appointment records include provider, operatory, start/end times, recall linking, confirmation status, and appt field values. We preserve appointment history including completed, cancelled, and no-show records and reconstruct the recall chain linking. |
| Procedures (ProcedureLogs) | Fully supported | Clinical procedure records include tooth numbers, surfaces, ADA codes, provider, date performed, fee, and status. We map procedure codes to destination equivalents and preserve treatment plan stages, attachments, and benefit insurance estimates. |
| Claims | Fully supported | Claims link patients, providers, procedures, and insurance plans. We migrate claim status history, supplemental claim records, tracking entries, and associated ClaimProcs. The ClaimPayments table is also migrated to preserve the insurance payment ledger. |
| PayPlans | Mapping required | PayPlans (dynamic) support structured payment schedules with PayPlanLinks to individual procedures or charges. We preserve the plan terms, linked items, and completed pay splits. Some legacy PayPlan formats may require mapping review for date-range and adjustment logic. |
| Documents | Mapping required | Documents are stored as files (images, PDFs) with database entries referencing patient folders. We export document metadata, category assignments, and file references. Actual binary files must be exported from the A-to-Z folder on the server separately from the database export. Radiographs require a separate x-ray bridge and are not included in standard migrations. |
| Insurance Plans (InsPlans) | Fully supported | Insurance plan definitions, fee schedules, coverage categories (CovCats), and coverage spans migrate as structured data. PatPlans linking patients to insurance carriers are preserved. We map carrier names and plan numbers but verify benefit percentages against destination plan structures. |
| Providers | Fully supported | Provider records include name, credentials, NPI, fee schedules, and scheduling rules. We map provider assignments across procedures, appointments, claims, and pay splits. Provider specialties are preserved as provider properties. |
| Clinics | Mapping required | The Clinics feature is only active when enabled. Multi-location practices may have Clinics disabled. We detect the Clinics setting during pre-migration scoping and map clinic assignments only where the feature is in use. Practices running separate databases per location do not use this object. |
| Providers (Userods) | Mapping required | User accounts and security permissions are separate from provider clinical records. We map user logins, role assignments, and preference overrides. Password hashes do not transfer; staff will need to reset credentials on the destination system. |
| Sheets (Custom Forms) | Mapping required | Custom sheets use a proprietary XML format that only imports into another Open Dental database. We export sheet definitions and data, but the XML structure requires conversion for any non-Open Dental destination. Sheet data attached to patient records is migrated as structured fields. |
Gotchas
What to watch for in Open Dental migrations
Issues we've hit on past Open Dental migrations, tagged by severity. FlitStack AI handles every one — surfacing them up front because buyer engineering teams want to know.
X-ray images do not migrate between systems
Scanned documents require a separate image conversion with additional cost
Server must run MySQL with myISAM engine, not InnoDB
API pagination is limited to 100 records per request
Custom sheets use proprietary XML that only imports to Open Dental
| Severity | Issue |
|---|---|
| High | X-ray images do not migrate between systems |
| Medium | Scanned documents require a separate image conversion with additional cost |
| High | Server must run MySQL with myISAM engine, not InnoDB |
| Medium | API pagination is limited to 100 records per request |
| Medium | Custom sheets use proprietary XML that only imports to Open Dental |
Leaving Open Dental?
Where Open Dental customers move next
12 destinations Open Dental can migrate to.
How a Open Dental migration works
Four steps, Open Dental-specific
Connect
API key authentication (Open Dental API key) into Open Dental. Scopes limited to read-only on the data we move.
Map
We translate Open Dental-specific structures (custom fields, objects, value lists) to the destination's model.
Sample
Test with a 50–200 record subset to validate Open Dental quirks before production.
Migrate
Full migration with Open Dental rate-limit handling. Rollback available throughout.
FAQ
Open Dental migration FAQ
Answers to the questions buyers ask most during Open Dental migration scoping. Not seeing yours? Book a call.
Can't find your answer?
Walk through your Open Dental migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationReady when you are
Migrate Open Dental.
Without the rebuild.
Free scoping call with a migration engineer. Tell us about your Open Dental setup and destination — written quote back within a business day.