Open Dental Cloud in 2026: What Changes for Your IT and Integrations

Most owners who look at Open Dental Cloud are in the same place: the server in the closet is five years old or just died, the backup nobody tested is on it, and the vendor's page promises nightly backups and no database server to look after. The question is what you actually give up, and what still lands on your IT provider's desk.

This guide takes the IT view. It sets out the three ways Open Dental can run "in the cloud" and who owns what in each, the published prices, Open Dental's own fit test, what your team notices on day one, what still runs in the office, how sessions and sign-ins work, the backup schedule, the migration steps, and a full section on the Open Dental API and third-party integrations. Every vendor figure comes from Open Dental's own pages, read on 6 November 2026, and those pages say the hosting fees "may change from time to time."

What is Open Dental Cloud, and how is it different from "Open Dental in the cloud"?

Open Dental Cloud is one of three ways to run Open Dental: Open Dental hosts it and manages the database. The second is a server your IT provider rents in a data center and connects through Open Dental's Middle Tier. The third is the on-site server. Each puts the database, backups and blame somewhere different.

Owners hear all three described as "cloud," and some IT companies' articles blur the first two, so start by naming which one you are being sold.

Best for, in plain terms: Open Dental Cloud suits a Windows office with good internet that wants to stop owning a database server and accepts the feature and integration limits below. A self-directed cloud server suits a group that wants the full server version, every integration and remote access, and has an IT provider to run it. An on-site server suits an office that wants control of updates, integrations and imaging under one roof, and has the IT support to keep a server healthy. If you are weighing Open Dental against another system at the same time, our Dentrix vs Open Dental comparison covers that decision; this page assumes you are staying with Open Dental.

Is Open Dental Cloud a good fit for your practice?

Open Dental publishes its own fit test. A good fit uses Windows, has at least 20 Mbps download and 10 Mbps upload, measures latency below 30 milliseconds to an Open Dental data center, accepts updates when they arrive, and relies only on third-party tools that use the Open Dental API or sit on the Cloud integrations list.

The vendor's page is worth reading as a pair of columns. On the "may be a good fit" side: a practice that "uses Windows," "has a reliable internet connection with a minimum speed of 20 Mbps download and 10 Mbps upload," "has latency below 30ms with at least one of our data centers," "wants to use the latest tools available in the software," "wants automated backups of the database and OpenDentImages folder," and "does not have the resources or desire to manage a local server."

On the "may NOT be a good fit" side: a practice that "uses macOS," whose internet "is unstable or does not meet recommended minimum speeds," that "has latency above 50ms with our data centers," that "wants to choose when to update the software," that "wants to continue to self-manage backups," that depends "on third-party integrations that do not use the Open Dental API," or that "wants separate Imaging software to be cloud hosted by Open Dental."

Three of those lines decide most cases:

• • Latency, not speed. Open Dental Cloud streams a Windows desktop application, so the round-trip time to the data center matters more than the headline bandwidth. A 300 Mbps cable connection with 60 ms to the data center fails the test; a 50 Mbps fiber line at 15 ms passes. Open Dental's coordinator performs "network testing" before setup; have your IT provider measure latency at the busiest hour first, so you know the answer before the questionnaire does.
• • Updates on the vendor's schedule. If your imaging bridge or a clearinghouse connection has ever broken after an Open Dental update, you know why an office might want to choose the update day. In Cloud, updates "are routinely installed automatically"; a bug-fix update outside that cycle is by appointment with Open Dental Support.
• • Integrations that do not use the API. This is the line that catches established offices. The section on the Open Dental API below explains how to check every vendor you use against Open Dental's own lists before you sign.

The vendor also says the service "is currently in limited release" and that it accepts "a limited number of customers" with "preference to those whose situation is a good match," so a practice that fails a line may simply not be accepted.

What does Open Dental Cloud cost in 2026?

Open Dental Cloud is priced as a monthly hosting package by concurrent sessions and storage, $250 to $2,370 a month, plus a one-time $400 migration fee, on top of Open Dental's support fee of $199 a month per location in year one and $149 after. A single office on the Small package pays about $449 a month, then $399.

Open Dental publishes all of these figures. The hosting table, read on 6 November 2026:

Four lines change the real number:

• • A session is an open window, not a person. Open Dental defines a concurrent session as "one Open Dental Cloud user interface instance." A six-operatory office with two front-desk computers, a screen in every operatory and the doctor's private office open at once needs nine instances, which is the Medium package, not Small. Opening a second Open Dental window on the same computer also "does count as a new session."
• • Storage is billed on the peak. Extra database or image storage is "$0.40/GB over the monthly allotment," and the fee "is based on the largest size recorded for the database or OpenDentImages folder, at any time during the billing cycle." An office with 30 GB of images on the Small package pays for 10 GB over, about $4 a month, every month; ten years of intraoral photos and scanned documents can run much higher, so measure the folder before you choose a package.
• • Support is separate and mandatory. The fee page says "Open Dental Cloud fees are in addition to the Open Dental Software License and Support fees," and the Cloud page says "Each location must remain on Open Dental support for the duration of their cloud usage." US support is "Initial Rate: $199/month/location" for twelve months, then the "Current Reduced Rate: $149/month/location," with $20 a month for each provider beyond three.
• • Migration is $400, once, non-refundable. It is "Collected before a final Migration is started." If you are coming from another practice system, the data conversion is a separate step and fee; Open Dental's conversions page lists "The typical cost for a United States customer is $1450 per database," with scanned-document and X-ray image conversions quoted separately.

What one location pays per month, before storage overage and extra providers:

Set against that: no server purchase, no Windows Server license, no server backup subscription and no server replacement in year five. What the move does not remove is the cost of the computers, network, firewall, internet lines and imaging that stay in the office, which is why a fair comparison looks at the whole stack over several years. Our guide to what still needs a server with cloud dental software works that through. Open Dental's own exit terms are unusually clear: customers "may switch to Self-Hosted at any time instead without penalty."

What changes on day one with Open Dental Cloud?

Open Dental says Cloud "looks and feels just like our local version," and for charting, scheduling and billing that is true. The differences live at the edges: the images folder is no longer on your network, the built-in backup tools disappear, ERAs no longer download by hand, and a short list of features is switched off.

Walk the team through the list before the migration, not after. Open Dental's own differences page, condensed, with what each line means for the front desk and for your IT provider:

Two of these matter more than they look. The images-folder change touches every workflow that used to say "browse to the shared drive," and the loss of the built-in backup tool means the practice's copy of its own data is now something you request rather than something you hold.

What still runs in your dental office with Open Dental Cloud?

Everything that touches a patient or a device stays in the office: Windows computers, sensors, cameras and imaging software, scanners, signature pads, printers, card terminals, the network, firewall and internet lines, and whatever backs up what the vendor does not. In Open Dental's words, the local computers "are still fully managed by the practice or their IT."

Open Dental Cloud needs a small program on each workstation, the OpenDentalCloudClient (ODCloudClient). Open Dental says it "must be installed on a Windows machine to bridge to third-party softwares (such as imaging software, credit card processing, etc.)," that it is "not required to access Open Dental, but users receive a warning if it is not installed," and that it exists to allow clipboard copy and paste, capture the local computer name, run Program Links and "Access TWAIN drivers to acquire images." It "keeps itself updated via Powershell," and Open Dental notes that if Microsoft Defender blocks the install, the user clicks "More Info, then Run Anyway." For your IT provider that is a deployment, an allow-list entry and a PowerShell policy decision on every PC, not a one-off download.

What stays local, by category:

• • Imaging. Sensors, intraoral cameras, pan and CBCT units capture through the imaging suite installed on the local PC; Open Dental bridges to it through the ODCloudClient. Open Dental's fit test says a practice that "uses separate Imaging software that doesn't need to be hosted" is a good fit and one that "wants separate Imaging software to be cloud hosted by Open Dental" is not. The images Open Dental itself stores (the A to Z folder) move to the cloud; the imaging suite's own database and 3D volumes stay where the suite keeps them. Owners are often told that taking X-rays means always keeping a physical server; a capture PC and, for CBCT, often a local store is closer to the truth.
• • Workstations. Windows only, and Windows 10 left Open Dental's supported list on 14 October 2025. Open Dental warns that "Home editions of Windows are sometimes unacceptable" and recommends 4 to 8 GB of memory; a streamed application still needs a healthy PC, a current browser or the Amazon WorkSpaces client, and working TWAIN drivers.
• • Network and internet. The internet line becomes the thing that keeps the schedule open. Plan a second connection with automatic failover, a firewall that does not add latency, and wired connections for every operatory. Once the software lives in the cloud, a slow line means a slow front desk. Our guide to why Open Dental is slow covers how to measure the layers.
• • Peripherals. Topaz signature pads, label and receipt printers, scanners and card readers all live on the local PC; test each one in the Cloud test environment.
• • Backups of what is left. Open Dental backs up its database and images folder. It does not back up your imaging suite's database, your CBCT volumes, your QuickBooks file, your scanned HR folder or the PCs themselves.

How do sign-ins and sessions work in Open Dental Cloud?

Open Dental Cloud is sold by concurrent sessions and offers two ways in: a browser URL, where the office shares one Cloud username and password and each person logs into Open Dental as themselves, and Amazon WorkSpaces, where "It is required that each user have their own credentials." Both enforce the session limit, so idle windows cost seats.

Details from the vendor's sign-in page that your team and your IT provider should know before day one:

• • Two logins, not one. With the URL method, the Cloud username and password "is the same for all users accessing the database," and then each person logs into Open Dental with their own Open Dental user. Open Dental recommends "each User have their own logon credentials in Open Dental" and says "Strong passwords are turned on by default for Open Dental Cloud users."
• • Where you can log in from is controlled. "Users without the Allow Login From Any Location permission can only log in from workstations with an IP Address listed on the Allowed List." Working from home means an administrator adds that address, and a changed home IP address means a locked-out doctor first thing in the morning. Your IT provider should own the allowed list and the permission.
• • Sessions are a hard limit. "If the allowed number of sessions has been met, another session cannot open and a prompt will appear," and the prompt offers to "close the session of another user." Open Dental says "Because sessions are limited, it is important to log off and close out of Open Dental Cloud." Expect the first week to include someone closing the hygienist's chart from the front desk.
• • More than one window counts. Opening a second instance in another browser tab "does count as a new session," and running several per browser "may experience degraded performance."
• • WorkSpaces has its own moving parts. The Amazon WorkSpaces client is installed on each PC, has native and classic modes, and offers Disconnect (keeps the streaming instance briefly) or End Session. Open Dental also notes that ortho graphics and custom text on the tooth and perio charts are "available in Cloud when using WorkSpaces."

Security permissions still live in Open Dental's own Security window, where every person "should have a unique user name and password," and the audit trail records log-ons as before. What changes is that two more layers sit in front of the chart: the Cloud sign-in and, for remote work, the IP allowed list.

How are backups handled in Open Dental Cloud, and what should you still back up?

Open Dental backs up the Cloud database and images folder on a published schedule: full backups nightly at 11 pm local time, kept on site and off site for three days, weekly off-site copies kept six months, monthly copies a year, yearly copies three years. The practice's own backup tool is switched off; copies are requested from Open Dental support.

The schedule, from Open Dental's backups page (the vendor notes "Backup frequencies are subject to change"):

Open Dental adds that backups "are encrypted, tested for integrity nightly, and stored off-site," and that if a Cloud server fails "the most recent backup will be restored to a new server by Open Dental staff." That is a stronger routine than most single offices run on their own server, and for many owners it is the whole reason to move. Two cautions from the IT side:

• • Three days is the fine-grained window. A ledger error noticed on a Friday that happened on the previous Monday has already aged past the daily copies and into the weekly one. Decide with Open Dental how you would request a point-in-time copy and how long it takes.
• • Your copy is no longer automatic. The Backup Tool and Supplemental Backups are gone in Cloud. Open Dental says "Copies of backups can be requested by contacting Open Dental support." Many offices will want a periodic copy of their own database and images on media they control, for an exit, an audit or an insurer's questionnaire; agree the cadence and who asks for it.
• • Everything else still needs a backup. The imaging suite's database, 3D volumes, documents outside Open Dental, accounting files and the workstations are the practice's problem, as before.

How does moving to Open Dental Cloud work, step by step?

Open Dental runs the migration itself through nine steps it calls "lengthy to ensure Open Dental Cloud is a good fit for the practice": contact support, complete a questionnaire, a coordinator tests your network and sets up a test environment, you review it, schedule and pay for the final migration, Open Dental migrates and reviews the data, then follows up.

Your IT provider's work sits around those steps. The vendor's steps with the IT owner's job beside each:

Three things the process page does not say that the IT side must plan:

• • If you are not on Open Dental yet, the conversion comes first. "If your practice is considering Open Dental and you are currently using a different practice management system, you must first complete a Data Conversion." That is the standard Open Dental conversion ($1,450 typical per US database, with image and X-ray conversions quoted separately) and then the Cloud migration on top. Our dental software migration checklist covers the conversion side.
• • The old server does not switch off on migration day. The eConnector, any API Service, the clearinghouse report service, imaging bridges and shared folders still point at it. Keep it on, isolated, with a final verified backup until the first month's claims, ERAs, reports and integrations have been checked in Cloud. Then wipe it properly or repurpose it as a local imaging or document store; the live guide to server replacement vs cloud migration has the decommissioning list. If the old box runs Windows Server 2016, its own clock is ticking too: see what Windows Server 2016 end of support means for a dental office.
• • Train on sessions before the first Monday. Log off, close the tab or end the session, and know who holds the Allowed List and the Security Admin permission.

Open Dental API and integrations: what works in the Cloud and what breaks?

The Open Dental API is the approved way for other software to read and write your database. In Cloud it is the dividing line: tools that use the API, plus the bridges, clearinghouses and payment processors on Open Dental's Cloud integrations list, are expected to work; tools that write directly to the database or install a server program are not.

Audit your vendor list against Open Dental's own pages before you sign, not after the migration fee is paid.

How Open Dental classifies integrations

Open Dental's integration-types page says that "generally the only safe way for third parties or larger Dental Support Organizations (DSOs) to write data to the Open Dental data tables is through the Application Programming Interface (API)," while "Neither customers nor third parties need Open Dental's approval to read data, for example to use for third-party dashboards or reporting tools." Writing directly to the database "is unsafe, often insecure, and does not allow the office to know what program or user made the change."

The same page sets out the safe types: API integrations; native integrations built by Open Dental (eRx and payment processing); Program Links, "also known as bridges," which launch another program with patient data and "do not write data back to Open Dental"; and read-only SQL queries. It flags two types as possibly dangerous (automated external queries that "can slow down Open Dental if they are large, indexed poorly, or run too frequently," and legacy plug-ins), and one as dangerous: anything that writes to the database by its own method.

Open Dental also publishes a third-party vendors page that groups named companies by the method each uses, with a dated "Reported Concerns and Warnings" section underneath. The groupings change, so read the live page rather than any article, including this one. A useful rule: a vendor on the top tier uses a method that should survive version updates and the move to Cloud; a vendor flagged as using a direct-write method or an unlisted plug-in is a vendor to replace or renegotiate before you move, because Open Dental's fit test lists dependence on integrations that do not use the API as a reason Cloud is not a fit.

What the Cloud integrations list says

Open Dental publishes a separate Cloud list, with the caveat that the integrations "are expected to work within Open Dental Cloud. Not all integrations have been tested." It names about fifty imaging bridges, among them Carestream, Dexis, DTX Studio, Planmeca and Romexis (through the Dimaxis setup), Sirona Sidexis, XDR, VixWin, Apteryx and XVWeb, Cerec, i-Dixel and NewTom NNT; clearinghouses including DentalXChange ClaimConnect, Electronic Dental Services (dental and medical), Inmediata and Post-n-Track; the PayConnect, Global Payments and PaySimple payment integrations; DoseSpot and, for some users, Ensora eRx; and a miscellaneous group including QuickBooks Online, CareCredit, Pearl and Oryx.

The closing paragraph is the one to read twice: "many third-party vendors using the Open Dental API are also available to Open Dental Cloud users. Vendors who install a separate program, however, may not be compatible. We recommend reaching out to the Authorized API vendor to confirm." A tool that runs as a service on your server, reads the database on a timer or drops files into the shared images folder is the kind of "separate program" that has nowhere to live once the server is gone.

How the API connects, and why Cloud changes the mode

Open Dental documents three API modes. The Local API runs inside Open Dental on each workstation on port 30222. The API Service runs continuously on the database server on port 30223 and is the mode Open Dental recommends when "The third-party service is installed upon the database server" or "The practice is using Open Dental Cloud." The Remote API is "A public facing, cloud-hosted version of our API" at api.opendental.com, routed to your office; Open Dental says "In order to use the Remote API, the office must have an eConnector running" and that "Customers will receive an Alert if their eConnector stops working."

Each API request carries two keys, a developer key and a customer key, and the practice turns a key on or off at Setup, Advanced Setup, API. Open Dental's page says the customer "can view permissions granted to that key, but they cannot change those permissions," and separately that the normal Open Dental user permissions "do not restrict the API from making changes." In other words, the practice's control is the on/off switch and the contract, and Open Dental's API page says "API developers should have a Business Associate Agreement (BAA) in place with their clients."

Open Dental also publishes the price ladder developers pay, per location: "Free - Read All (1 request per 5 seconds throttle)"; "$15 - Comm, Documents, InsuranceSimple, Setup, and Queries (1 request per 1 second throttle)"; "$30 - All except Payments, PayPlans, and Special"; and "$35 - All except Special." Fees are paid by the developer, billing stops when a key is disabled, and the page notes "The last time prices were changed was September, 2020." For an office, the useful fact is that a read-only reporting or dashboard tool costs its developer nothing in API fees, so a vendor who insists on direct database access instead of the API is making a choice about method, not money.

The API can also push data out as webhooks, which Open Dental calls API Events. They matter in Cloud for one reason: Database Events are generated by Open Dental or the API Service polling the database, and if the subscribed workstation or service "is not running … such as if they are closed for a weekend, then that Workstation will not poll the database or send events." An integration that relied on the always-on server to fire events needs a new home.

The eConnector and eServices

Open Dental's eServices (texting, confirmations, online scheduling, eClipboard, the patient portal) run through the eConnector, which the manual says "is used by, and required, for all eServices," is installed "on one machine (typically the server)," "should always be on and awake," and "is not compatible with Linux or Mac." Open Dental's fit test counts a practice that "uses (or can use) Open Dental eServices" as a good fit for Cloud, so expect eServices to be part of the Cloud package rather than something you host; confirm during the questionnaire exactly which eServices run from Open Dental's side and whether anything still needs a local machine awake.

An integration audit your IT provider can run in an afternoon

1. 1. List every program on the server and on each PC that touches Open Dental: imaging suites, clearinghouse software, payment terminals, texting and reminder tools, analytics dashboards, AI assistants, accounting links, backup agents.
2. 1. For each, note the method: API, native, bridge (Program Link), SQL read, direct write, plug-in, or "installs a service on the server." Vendors will tell you if you ask in writing.
3. 1. Check each name against Open Dental's third-party vendors page and the Cloud integrations list on the day you check, and keep a dated copy.
4. 1. For anything that is a direct write, an unlisted plug-in or a server-resident service: ask the vendor for an API-based version, a Cloud-compatible version, or a replacement.
5. 1. Re-test every survivor in the Cloud test environment before the final migration, and keep the old server on until the first claim, ERA, text and payment have gone through.

Does Open Dental Cloud fit a group with several locations?

Open Dental Cloud lists "Great for multiple location offices, easily expand" among its benefits, and a group running one Open Dental database with the Clinics feature can move it as one. A group with separate databases per location, or many sites, should compare it with Open Dental's other multi-location designs: a shared database over a VPN, or the Middle Tier.

Open Dental's multiple-locations page lays out four designs, from separate databases per office to "Single Database using a VPN," which it typically recommends for "fewer than 5 locations," and it is blunt that "Open Dental Support cannot assist with network setup. It is recommended to have a capable IT set up and maintain any network settings." The Middle Tier, used for self-directed cloud hosting, "isolates the database, improving speed and security by preventing client workstations from directly accessing the database," and lets "ordinary thick clients running the full Windows version of Open Dental" connect over slower links; the client "doesn't need access to the MySQL username and password." For groups the decision is less "cloud or not" than "whose cloud, and who holds the database credentials." The DSO view, including standards and acquisition due diligence, lives on our DSO IT support page, and our guide to where IT cost hides in a growing dental group covers the license sprawl that a per-location hosting package can add to.

The IT side: what your IT provider owns after the move

Open Dental Cloud removes the database server from your IT provider's list and adds the ODCloudClient, the internet and latency, the Allowed List and sessions, the integration audit, the bridges, and the backups of everything Open Dental does not hold. That is the shape of the job after the move: monthly work, not a one-off project.

What changes in the monthly work, in plain terms:

Monitoring still matters: a PC that cannot reach the data center, a bridge that stops launching after a client update, a latency jump after the internet provider changes routing, and a session limit being hit every morning are all problems a managed provider sees before the front desk does. If you want one place to look at how we handle the server, workstation and imaging side of Open Dental, see dental practice management software support, and for the whole office under one agreement, managed IT services for dental practices.

What to verify before you sign

Open Dental Cloud is a vendor relationship with its own paperwork, and most of the surprises are avoidable with a written answer to each of these ten points. Verify them during the test environment, with your IT provider in the room, not after the migration fee is paid.

1. 1. Latency and speed at your busiest hour, measured by your IT provider to the data center Open Dental names, against the 30 ms and 20/10 Mbps figures, and again on the failover line.
2. 1. The session count you really need, counted as open windows across front desk, operatories and private offices, and which package that puts you in.
3. 1. The size of your database and images folder today, and its growth per year, against the package allotment and the $0.40 per GB peak-based overage.
4. 1. Every third-party tool's status on Open Dental's vendor and Cloud integrations pages, with the vendor's written confirmation that its product works in Cloud and which mode or program it needs.
5. 1. Imaging: that each sensor, camera, pan and CBCT unit bridges through the ODCloudClient in the test environment, and where 3D volumes will live.
6. 1. Backups: the retention schedule, how you request a copy, how long a restore to a point in time takes, and the cadence of the practice's own copy.
7. 1. Exit: Open Dental's "switch to Self-Hosted at any time … without penalty" in writing, and what a return migration involves and costs.
8. 1. The features you lose, checked against the differences page with the people who use them: Letter Merge, Video Capture, Import Automatically, Voice Perio, touch-screen signatures, manual ERA downloads.
9. 1. Fees: the hosting package, the support fee by year, provider add-ons, the migration fee, and the vendor's note that hosting fees "may change from time to time."
10. 1. Paperwork: Open Dental's business associate agreement signed and filed, and BAAs with every API vendor that reads your data.

What to ask your IT provider about Open Dental Cloud

How Legend Networking can help

Legend Networking is a Dallas-based dental IT company that has served over 3,500 practices since 2004, with 22+ years in dental IT. Legend supports the IT environment for the practice software Dentrix, Eaglesoft, Open Dental and Archy, which in an Open Dental Cloud move means the workstations, the ODCloudClient, the imaging bridges, the network and internet, and the backups of everything the vendor does not hold. Onsite dispatch is by appointment across served dental markets; support is remote-first nationwide, with 24/7 monitoring.

The author, Ian Lynch, has 22 years in dental IT and oversees the NOC, onsite dispatch and client technology roadmaps. Legend holds a 4.8 rating from 173 Google reviews. For the Open Dental-specific side, from eConnector drops to server migrations, see our Open Dental IT support page; for an example of the office side done end to end, see a recent full technology build covering computers, networking, software, imaging integration, backups and security; and to find dental IT support in your city, start with the locations page.