Open Dental is a serious piece of software. It is mature, deeply feature-rich, free to license, and backed by an active community of US-based dental practices and consultants. For clinics with an in-house IT lead and a strong US-payer billing workflow, it is a legitimate choice for the long term.
For other clinics — particularly APAC clinics where US payer rails aren't relevant and IT capacity is the office manager's weekend — the freedom of self-hosting becomes the cost of self-hosting. This article is for clinic owners weighing whether to leave Open Dental for a managed PMS, and what that migration actually looks like in practice.
What you actually lose, and what you gain
The main things you lose moving from Open Dental to a managed PMS:
- Configurability. Open Dental can be customised deeply — custom reports written in SQL, custom views, custom procedure codes. Managed PMS are typically more opinionated by design.
- Self-hosting sovereignty. Your data sits on your hardware. For some clinics (defence contractors, certain government partnerships) that is a hard requirement. For most, it is a preference that comes with operational cost.
- Free license. Open Dental does not charge for the software itself. You pay for support, hosting, IT time, and customisation effort — but not the binary.
The main things you gain:
- No infrastructure burden. No Windows server to patch, no MySQL/MariaDB to back up, no upgrade weekends. A managed PMS runs continuously and you do nothing to maintain it.
- Continuous deployment.Every clinic on the managed PMS is on the same version every week. Open Dental installations across clinics drift; managed PMS installations don't.
- Modern UX.Open Dental's interface evolved over two decades and has a Windows-leaning, dense menu structure. Modern web-native PMS — drag-driven schedule, click-through navigation, mobile-friendly layouts — are a different category of experience.
- APAC-specific features. WhatsApp Business API for recall, Singapore GST handling at billing, region-hosted patient data, PDPA-aware audit logs. None of this is what Open Dental was built for.
The three risks specific to leaving Open Dental
Open Dental migrations have three risks that don't come up in the same way with other PMS migrations. See the Plato migration playbook for the more general migration risk model; what follows is what's Open Dental-specific.
Risk 1: Custom-query export
Open Dental clinics that have been running 3+ years typically have accumulated custom SQL reports, custom queries the office manager runs at month-end, and possibly custom database views. These don't port to a managed PMS — the destination doesn't expose SQL or accept your custom views.
The mitigation is upfront: list every custom query the clinic currently runs and ask the destination PMS to confirm which built-in report covers the same need. Most cover ~80% out of the box; the last 20% either get rebuilt as managed dashboards or get accepted as a feature gap.
Risk 2: Customisation expectations
Open Dental's configurability creates a culture of expecting any change to be possible. Front-desk staff used to “can you add a custom field for X?” getting answered by clicking around in Open Dental settings will be surprised by “not in the current version, on the roadmap for Q2” from a managed vendor.
Set this expectation at week-1 of pilot, not at the first feature request. The trade-off is that the managed product is more opinionated and ships faster across all clinics; the cost is less individual flexibility.
Risk 3: Self-hosted-data extraction
Open Dental's data lives in a MySQL/MariaDB database on your clinic's server. Extracting it means scheduling a maintenance window, dumping the database, sanitising any test/dev rows, and validating field-by-field against the destination PMS's schema. This is a real DBA task — usually 4–8 hours of focused work — and the clinic should expect to pay for it (either to their IT lead or to the destination PMS's migration team).
Plato migrations skip this step because Plato is a desktop client with a vendor-managed export path. Open Dental migrations don't skip it.
The migration playbook for Open Dental specifically
The general three-week pattern still applies. Where Open Dental differs:
Week 1 — Audit and prep, with custom-query catalogue
- Schema export from the Open Dental MySQL/MariaDB. The destination PMS team will tell you which tables are needed.
- Custom-query catalogue: the office manager lists every recurring report or query they run today. Each gets matched against the destination's built-in reports, or marked as a gap.
- Customisation review: any custom procedure codes, custom fee schedules, custom appointment types get reviewed. Most map cleanly; some get redesigned.
- Cutover date pinned. Wednesday remains the recommended day for the same reason it does for Plato migrations.
Week 2 — Cutover with a maintenance window
- Tuesday evening: maintenance window starts. Open Dental database is dumped and locked read-only.
- Tuesday night: data import to the destination PMS, with row counts verified (patients, appointments, invoices, recall list, treatment history).
- Wednesday 8am: front desk opens the new PMS. Open Dental remains read-only on the office server for historical lookups.
- Wednesday and Thursday: discharge and billing flow through the new PMS. Same-day-bill rate dips for the first day, then recovers.
Week 3 — Stabilise and decommission
- Recall list rebuilt in the new PMS with the surfacing window configured.
- Open Dental server kept available for 30 days as a read-only fallback for historical queries.
- After 30 days, the Open Dental server is decommissioned (or kept offline for archival per the clinic's legal hold policy).
Whether to do this at all
Open Dental is the right choice for a meaningful slice of clinics. If you're a US practice with deep US-payer billing, an in-house IT lead, and a budget for OD-certified consultants, the case for leaving is weaker. If you're an APAC practice running fee-for- service, no IT lead, and the office manager is also the weekend-DBA against her better judgement, the case for leaving is stronger.
For a feature-by-feature comparison, see Oralstack vs Open Dental. For a worked example of a managed-PMS pilot in an APAC clinic, see the DFI Synergy case study.