When dental practice or DSO leaders evaluate whether to upgrade their practice management software, the conversation almost always centers on one system: the on-premises platform they bought years ago under a perpetual license.
Because the license is already paid off, the only remaining cost is a maintenance fee, typically a flat annual charge to keep the system technically supported. That fee is on the invoice; it is easy to compare year over year, and it gives finance teams a clean number to point to when someone asks whether the current system is worth the expense. On paper, sticking with that older system often looks like the fiscally responsible choice. The license was paid off years ago. The maintenance fee is modest. Why spend more on something new?
I call this the mid-cycle economics problem, and it is one of the more common blind spots I see among dental finance decision-makers. It happens when a practice or DSO judges the cost of its software at a single point in the ownership cycle, usually the point where the visible costs look lowest, rather than across the full life of the system. The maintenance fee tells you what you are paying to keep the lights on. It tells you almost nothing about what that system is costing you everywhere else.
Where the Costs Hide
The true cost of legacy, on-premises software rarely shows up as a single expense. It accumulates in places that never make it onto a line item, and it is worth walking through each of them individually because they compound in ways a single maintenance fee comparison can never capture. Single-site practices might be able to look at this in simpler terms, but the larger a practice group, the greater the impact of these hard to track costs.
Start with internal IT burden. Older systems typically require more hands-on maintenance: patching servers, managing local hardware, troubleshooting issues that a modern, cloud-based platform would resolve automatically. That is time your IT staff spends keeping the system running rather than helping the business grow. In a budget review, this time rarely gets coded back to the software itself, but it is a real cost, and it competes directly with the capacity your team has for higher-value work like supporting new locations or improving data infrastructure.
Then there is the update cycle. On-premises systems tend to update in large, infrequent, disruptive pushes rather than continuously in the background. Each of those updates carries planning time, testing time, and often some amount of downtime. A single office absorbing that disruption once a year can be frustrating but manageable. A DSO with dozens of locations, each on a slightly different version or update schedule, is absorbing that same disruption dozens of times over, often at different times on the calendar. This makes it harder to plan around and easier to underestimate its impact.
Then there is fragmentation. As a DSO grows through acquisition or expansion, it is common to end up with different versions of the same software running at different sites, or entirely different systems stitched together with manual workarounds. That fragmentation shows up as inconsistent reporting, duplicate data entry, and workflows that vary from office to office. This makes it harder to run the business as one organization. None of that appears on an invoice, but it shapes how efficiently your teams operate every day, and it is often the reason a monthly close or a board package takes longer to produce than it should.
Finally, and this one is easy to overlook until it happens to you, there is knowledge deterioration. Legacy systems are rarely well-documented. The people who understand how a specific workaround was built, why a certain report was configured a certain way, or how to fix the one server issue that pops up every few months tend to be one or two specific individuals on your IT team, not a written process.
When those people retire, get poached, or simply move on, that knowledge leaves with them. What is left behind is a system nobody fully understands anymore, held together by institutional memory that no longer exists. Rebuilding that knowledge from scratch, or paying a premium to retain the people who have it, is a real and recurring cost. It just never shows up as a line item labeled software risk.
The Growth Trap
This problem gets worse, not better, during periods of rapid growth, and that is where I think it deserves more attention than it usually gets. In a low-cost capital environment, it is tempting to prioritize acquisition volume over integration discipline. A DSO can move quickly, add locations, and grow revenue without ever stopping to ask whether the underlying technology stack can support that growth cleanly.
The results of that approach rarely show up immediately. They show up in the medium and long term, once the organization has accumulated enough fragmented systems and enough manual workarounds that the cracks become visible in the financials. By then, the fix is no longer a straightforward software decision. It is a much larger integration project, often occurring under time pressure—possibly during a transaction or a due diligence process that surfaces the problem for everyone to see at once. In my experience, the DSOs that end up in the most difficult positions grew fast without paying enough attention to what was happening in procurement, in systems, in the basic plumbing of the business.
Why the Blind Spot Persists and The Cost of Waiting Too Long
I understand the instinct to be dogmatic about dollars and cents here. Finance leaders are trained to distrust soft, hard-to-quantify costs, and rightly so. But there is a version of financial discipline that focuses so tightly on the visible number that it misses the larger picture. A modern, cloud-based platform typically carries a higher visible cost than a legacy system's maintenance fee. What it also does is remove much of the invisible tax I just described: less manual upkeep, fewer disruptive update cycles, and more consistency across locations. That is a real return on investment. It is just a return that does not always show up in the place you are used to looking for it.
The challenge with mid-cycle economics is timing. By the time the hidden costs become impossible to ignore, an organization is usually deep into its software cycle. IT teams have adapted to the workaround, staff have built habits around the fragmentation, and the pain has become normalized rather than solved. At that point, an upgrade decision that could have been made proactively becomes reactive, often driven by a crisis such as a security issue, a vendor sunsetting support, or a due diligence process ahead of a transaction that forces the issue.
Looking Beyond the Maintenance Fee
None of this means every practice or DSO needs to rip and replace its technology stack tomorrow. It means the evaluation should be broader than the number on the invoice. When you are weighing whether to modernize, ask what your IT team's time is actually being spent on. How much staff time goes into workarounds that exist only because your systems do not talk to each other well? Is your reporting consistent enough across every location for you to trust it without double-checking? And if you are growing quickly, ask whether your technology stack is being integrated with the same discipline you are applying to the rest of the deal.
Those questions will not show up on a single line item, and that is exactly the point. The maintenance fee was never the full picture. It is time we start evaluating software decisions the way we evaluate the rest of the business: on total cost and total value, not just a line item that happens to be easiest to see in a financial report.
