SaaS vs. On-Premise ERP for Mid-Market Hospitals: A Rigorous TCO Comparison
Budget season is when ERP decisions actually happen at mid-market health systems. Strategy decks float ideas all year. Capital committees decide.
When the SaaS-versus-on-premise question lands on the capital agenda, most CFOs encounter the same problem. Vendor materials show SaaS winning by a wide margin on five-year cost. Internal IT shows on-premise winning by a narrow margin on year-one cash. Both can be correct. They are measuring different things. And the version of the comparison that lands in front of the board is usually the one prepared by whichever side wrote it.
The CFO needs a third version. One that includes the costs both sides leave out, draws clear lines around what is genuinely uncertain, and gives the board a defensible number rather than a vendor-friendly one.
This guide walks through the categories that belong in a rigorous TCO model for healthcare ERP, where the typical ranges actually land for a mid-market multi-entity health system, and where each model has a real advantage versus a marketing advantage. For the upstream evaluation framework that informs how to assess each platform against these categories, see our earlier post: Cloud-Native Finance Platforms for Healthcare: What CFOs Need to Evaluate.
The Comparison Most Boards See, and Why It Fails
Most TCO comparisons fail in one of two ways.
The vendor version overstates on-premise costs by including aggressive assumptions about IT labor, infrastructure refresh, and downtime that may or may not apply to your environment. It often understates SaaS implementation costs by quoting reference deals that did not have your entity complexity or integration footprint.
The IT version often undercounts on-premise costs because much of the maintenance burden is buried in existing labor budgets. Database administrators, integration engineers, and infrastructure staff are already on payroll, so their hours feel free. They are not free. They are committed.
The honest TCO model accounts for both. It uses real labor numbers, real infrastructure costs, and realistic implementation estimates for your specific entity count and integration scope. It tells you what each option costs the organization, not what makes either option easier to defend.
The Categories That Belong in the Model
There are nine cost categories that materially affect ERP TCO for mid-market healthcare organizations. Build the model with all nine. Skipping any of them is how comparisons get distorted.
Category 1: Software Licensing
On-premise. Perpetual license fees with annual maintenance (commonly a meaningful percentage of license cost per year). Often front-loaded, with a large year-one outlay that the CFO has to capitalize and depreciate. New modules require additional licensing.
SaaS. Subscription-based, usually billed per user per month or per entity per year. Predictable, treated as operating expense, scales with adoption. The headline number often looks higher than annual on-premise maintenance, but the comparison is misleading until you add infrastructure and IT labor.
Use your vendor’s actual quote and your historical maintenance invoices to fill in the five-year licensing line. This is where vendor decks usually stop. This is also where the comparison is least meaningful.
Category 2: Infrastructure
On-premise. Servers, storage, networking, backup systems, disaster recovery infrastructure. Capital expenditure with depreciation schedules and refresh cycles (commonly every several years). Power, cooling, and data center costs allocated from facilities. A redundant DR site materially increases infrastructure expense if you do not currently have one.
SaaS. Included in the subscription. No capital outlay, no refresh cycle, no DR build. The vendor’s infrastructure is your infrastructure.
Pull your actual infrastructure costs from finance and IT for the on-premise line; the SaaS line is included in subscription pricing.
Category 3: IT Labor
On-premise. Database administration, infrastructure management, version upgrade coordination, integration maintenance, backup and recovery operations, security patching. In a hiring environment where healthcare IT teams are stretched, this labor competes directly with cybersecurity, EHR optimization, and digital initiatives.
SaaS. Reduced significantly. Database administration disappears. Version upgrades become release-note reviews. Integration maintenance shifts from reactive to proactive, but does not vanish.
This is usually the single largest line item in a properly built TCO model. It is also the one most often understated, because the labor sits inside existing payroll and feels free. It is not free. It is committed. The audit in our earlier post for CIOs is the source for the on-premise number; the SaaS number comes from translating that audit to the post-migration state.
Category 4: Implementation
On-premise. Implementation is real, but the organization may have already absorbed it years ago. The relevant comparison is not historical implementation cost. It is the cost of a re-implementation (often required when the platform hits end-of-life or when significant customizations need to be unwound).
SaaS. Fresh implementation. The cost depends materially on entity complexity, integration scope, and the depth of process redesign required. Ask the implementation partner for a quote based on your specific environment, and ask for references at organizations with similar entity counts and EHR platforms.
If the project needs to extend across a longer timeline, the right phasing approach is by module rather than by entity (going live with core modules first and adding nice-to-haves later). Phasing by entity introduces design and training fragmentation that is rarely worth the smoother cash flow.
Category 5: Integration
On-premise. Existing integrations have an ongoing maintenance cost (covered in IT labor above) but no new build cost unless systems are being added or changed. New integrations on legacy platforms are typically built as flat files or batch jobs, which are cheaper to build but expensive to maintain.
SaaS. Re-implementation of integrations to EHR, payroll, AP automation, and other systems. Cost depends on the number of integrations and whether prebuilt connectors are available. API-native integrations are more expensive to build than flat-file approaches and significantly cheaper to maintain over the long term.
Category 6: Customization and Reporting
On-premise. Customizations have accumulated over the life of the platform. Many of them break during version upgrades, which is one reason on-premise upgrades feel so painful. Custom reports require database queries and skilled developers.
SaaS. Healthcare-validated platforms ship with healthcare-specific dimensions, report templates, and dashboards. The custom development burden drops substantially. Reports that took weeks of developer time on the legacy platform often exist out of the box. Sage Intacct is the platform DSD recommends in this space; its HFMA peer-reviewed financial reporting library is one of the reasons mid-market hospital finance teams shorten the report-build timeline meaningfully after migration.
Where on-premise still wins. Extreme customizations that have been built over years and would need to be rebuilt or rationalized during migration. If your organization runs a heavily customized GL structure or has unique workflow requirements that pre-date current best practices, expect implementation effort to skew higher.
Category 7: Training and Change Management
On-premise. Ongoing training costs are typically lower because the platform changes infrequently. Onboarding new finance staff requires training on a system that often has limited documentation and inconsistent UI patterns.
SaaS. Initial training is more substantial because everyone is learning a new platform. Ongoing training is lighter because the platform is documented publicly, UI patterns are consistent, and the vendor maintains training resources. Onboarding new hires gets easier over time.
Treat training and change management as a real line item, not a footnote. Projects that under-invest here usually pay for it in user adoption problems later.
Category 8: Risk and Compliance
On-premise. Audit trail reconstruction, security incident response, business continuity, and compliance documentation are all internal responsibilities. Audit costs are typically higher because supporting documentation lives across multiple systems and workpapers.
SaaS. Audit trails are native to the platform. Compliance certifications (SOC 1, SOC 2, HIPAA-aligned hosting) come with the vendor. Audit costs typically drop after migration, driven primarily by reduced support effort during fieldwork and cleaner trails.
Quantify the risk reduction in dollar terms. A material control weakness or a delayed audit has cost implications well beyond fee savings.
Category 9: Opportunity Cost
The category vendors do not price, because it is hard to. But it is real.
What is your organization not doing because of the current platform? Service-line profitability analysis that would change capital allocation decisions. Continuous close that would shorten the gap between operational reality and financial reporting. AP automation that would unlock early-payment discounts. Real-time consolidation that would let the board see month-end financials before mid-month. Driver-based forecasts that respond to payer-mix shifts the same week the data arrives, because the planning module shares a data model with the GL.
Sage Intacct’s tighter planning-plus-GL integration is one of the reasons it shows up so often in mid-market healthcare evaluations: scenario modeling against live financial data is a daily capability rather than a quarterly project.
Mid-market hospitals on legacy platforms commonly run close cycles materially longer than what cloud-native platforms support. That compression is not just an efficiency gain. It is decision velocity. In a margin environment as compressed as today’s healthcare market, faster decisions are rewarded disproportionately.
Putting It Together: A Five-Year Range
For a typical mid-market multi-entity health system, the directional comparison across three scenarios usually looks like this once all nine categories are accounted for.
| Scenario | Five-Year Total Cost (Directional) |
|---|---|
|
On-premise (status quo, no re-implementation)
|
Higher than vendor decks suggest, once IT labor is fully loaded
|
|
On-premise (with end-of-life re-implementation in years 2 to 3)
|
Highest of the three scenarios
|
|
SaaS (full migration with phased implementation)
|
Lowest, in most mid-market healthcare scenarios
|
The absolute figures depend heavily on your entity count, integration footprint, and how aggressively you account for IT labor and opportunity cost. Run the model with your numbers. The relative position of the three scenarios is what matters more than the absolute figures, and in most mid-market healthcare environments today the relative position is consistent with the directional pattern above.
Where On-Premise Still Wins
There are real scenarios where on-premise is the better answer for now. Be honest about them in your model.
If your platform is recent, well-supported, and the team is genuinely small and stable, the maintenance burden may not be material. Migration cost will exceed migration value over a three-to-five-year horizon.
If your organization has unique workflow requirements that current SaaS platforms have not yet caught up with, the gap may favor staying put until those gaps close. This is increasingly rare in healthcare finance but still occurs.
If a major M&A event or restructuring is imminent and would disrupt an implementation, sequence matters. Sometimes the right call is “not yet, here is the trigger that would change our answer.”
Where SaaS Wins by a Margin That Should Move the Decision
For the typical mid-market health system in 2026, the case favors SaaS clearly when one or more of the following are true.
- The current platform is on or near end-of-life and a re-implementation is on the horizon either way.
- IT capacity allocated to ERP maintenance is a meaningful share of the team and the strategic backlog is significant.
- The current close runs materially longer than what the executive team needs.
- Integration with the EHR is a known operational pain point.
- The audit committee has flagged financial reporting timeliness as a concern.
- Service-line profitability reporting requires manual rebuilding every cycle.
- The organization is in growth mode — adding facilities or service lines currently requires proportional growth in back-office finance and accounting headcount.
When two or more of these are present, the TCO model should show SaaS winning by enough margin that the decision is not close. The growth-mode case in particular is where Sage Intacct’s dimensional architecture earns its differentiation: adding a facility is a configuration task rather than an implementation project, so back-office headcount does not have to scale linearly with the entity count.
Using This Model in the Capital Committee
The board does not need a 200-line spreadsheet. It needs a single page that shows the nine cost categories, the assumptions behind each, and the five-year totals for two or three scenarios. The defensible version is the one where assumptions are explicit and where the categories most often left out (IT labor, opportunity cost, audit cost, integration maintenance) are present.
When the comparison is built honestly, the math usually does its own work. The CFOs who present it well are the ones who did not over-claim. They presented ranges, named uncertainties, and let the board reach the same conclusion from the same data.
Once the TCO model is built, the next step is packaging the case for the board.
Start the Conversation
DSD Business Systems is a Sage Intacct implementation partner specializing in mid-market healthcare organizations. Our consulting team includes former CFOs, Controllers, and Directors of Finance from healthcare systems who have built TCO models on both sides of the migration. We have run the analysis from the inside, in capital committees, with audit committees pushing back.
If you are building a TCO model for your fiscal year planning cycle, we can pressure-test your assumptions against patterns we have seen at similar organizations. We are not going to inflate the SaaS case to win the work. The CFOs we talk to do not respond well to inflated cases, and neither do their boards.
See what your TCO model looks like with the categories most decks leave out.
Douglas Luchansky
Director, Client Transformation
