Why “Cloud-First” Is Costing You More Than You Think

When Chuck Christian, VP of Technology and CTO of Franciscan Health, first heard his organization had a “cloud-first strategy,” he asked a simple follow-up question: does that mean every application — including the legacy, self-written systems built over decades — can actually run in the cloud?

The answer was, “We don’t know.”

That answer is more common than most IT leaders would like to admit, and it’s exactly the kind of gap that turns a cloud migration into a runaway budget line. As Christian put it: “Then you don’t have a cloud-first strategy. What you have is a workload placement strategy.” That single reframe — from cloud-first to workload placement — is worth sitting with, because it’s the difference between a cost strategy and a cost problem.

The Myth of “Move Everything”

The instinct to move everything to the cloud usually comes from a good place: simplify operations, cut hardware maintenance, gain flexibility. But not every workload is a good candidate, and pretending otherwise gets expensive fast.

At Franciscan Health, an 11-hospital system in Indiana, some systems simply won’t run in the public cloud — not because of preference, but because vendors won’t support it. Oncology systems running radiation treatment machines have to stay on-prem. Critical care systems, like cardiac monitors, are the same story. When Christian’s team asked one vendor whether a newly consolidated cardiac monitoring platform could move to the cloud, the response was blunt: “Sure. You want to be first?”

That’s not a technology limitation — it’s a vendor readiness limitation, and no amount of cloud enthusiasm changes it. Consolidating that same cardiac monitoring environment from 12 sets of on-prem servers down to a single high-availability pair eliminated 70–80 servers, but it happened on-prem, not in the cloud. The lesson: efficiency gains don’t require a cloud migration. Sometimes they require the opposite — a clear-eyed assessment of what belongs where.

Franciscan followed a familiar prioritization model, tackling straightforward migrations first and saving the harder, vendor-dependent workloads for later. It’s a slower path, but a far cheaper one than migrating indiscriminately and discovering mid-project that an application can’t actually run where you put it.

You Can’t Manage What You Can’t See

Here’s the part every finance leader will recognize: on-premises cost accounting is largely guesswork. Shared hardware, shared memory, shared storage — allocating true cost per application means estimating, not measuring.

The cloud removes that excuse. Tag resources correctly, and cost becomes visible down to the workload. But visibility only helps if someone is actually watching it — which is why Franciscan created a role that didn’t exist before: a dedicated cloud cost analyst.

The mandate for that role, in Christian’s words, is simple: “I need somebody that gets up every morning and this is what they think about all day long.” That person now sends a detailed spend report every week — where the money went, how it compares to prior periods, where the savings opportunities are, and whether anything needs a red flag.

The result of that discipline shows up directly in the numbers. Over a recent 12-month period, Franciscan’s cloud footprint grew by 20% — driven largely by routine platform upgrades that require additional infrastructure. Cost, however, only grew 3.8%. That gap — footprint growth outpacing cost growth — is the clearest evidence that active cost management, not cloud adoption itself, is what actually protects the budget.

Resilience Has a Cost Too — Just Not the One You’d Expect

Cost conversations in the cloud tend to focus on storage and compute, but resilience planning belongs in the same conversation. Franciscan’s prior disaster recovery setup required a multimillion-dollar investment to keep a secondary data center current — a cost that, in practice, often gets deferred because DR rarely gets tested under real conditions.

In the cloud, that math changes. Franciscan now runs production in one region and DR in another, and — critically — actually fails over to prove it works, a practice increasingly required by application vendors like Epic for their reliability certification programs. When Franciscan executed a full production failover, physicians in a hospital leadership meeting didn’t notice it had happened. That’s not just a resilience story; it’s a cost-avoidance story. The multimillion-dollar “just in case” investment became a manageable operational exercise.

Plan the Exit Before You Plan the Move

One more piece of cost discipline is easy to skip in the excitement of a migration: knowing what it costs to leave.

Vendor lock-in is a real, well-documented risk, and Christian’s team built their cloud strategy around avoiding it. Because Epic had already been moved once — from on-prem to a private cloud, and then to the public cloud — the team knew the workload was portable. That portability isn’t free, but it’s a known, budgetable cost rather than an unplanned one. The alternative — discovering after the fact that you’re stuck with a single vendor at any price — is the far more expensive outcome.

The Common Thread

None of this is really about the cloud. It’s about discipline: knowing which workloads belong where, watching cost continuously rather than annually, planning for resilience as a budget line rather than an afterthought, and understanding the true cost of both entering and exiting a platform.

Organizations that treat the cloud as a strategy get surprised by their bill. Organizations that treat it as one tool among several — placed deliberately, watched closely, and planned for both directions — tend to get the outcome they were actually looking for in the first place.