Webinar Transcript: The Forrester TEI Study — A Conversation with Franciscan Health

Featuring: David Berliner, Senior Director of Product, Silk Chuck Christian, VP of Technology & CTO, Franciscan Health

David Berliner: Welcome everyone, and thank you for joining us today. I’m David Berliner, Senior Director of Product here at Silk, and I’m really excited to have you all with us for this webinar.

We’re going to talk today about a problem I imagine many of you are facing: the challenge of overspending and optimizing your cloud environment. We’ll cover the Forrester report we worked on with Forrester Consulting to quantify this challenge, as well as Silk’s ability to impact it.

And most excitingly, I’m thrilled to have Chuck Christian, the CTO of Franciscan Health, here to talk about what it’s actually like in practice — his experience adopting Silk, moving his workloads to the cloud, and dealing with these cost efficiency challenges. Welcome, Chuck.

Chuck Christian: Thanks, David, for the opportunity to share.

David Berliner: You’re most welcome. I’m going to start for a few minutes and lay some context about what we’ll discuss today, then we’ll have a conversation with Chuck, and I’ll save time at the end for Q&A. You can submit your questions through the chat. We’ll be here for about 45 minutes. Let’s dive in.

If you’re running high-performance workloads in the cloud — databases, analytics, AI inferencing — you’ve likely hit a wall where it feels like a forced choice: pay for performance, or optimize for efficiency. You can’t get both. You need your IOPS, your throughput, the low latency your applications demand, so you’re provisioning large amounts of premium storage and oversizing at both the storage layer and the VM layer.

Every month, you’re paying for capacity you’re not using — overprovisioning required just to hit the performance level your application demands. It’s the only way it seems to stay on the right side of your SLAs for business-critical applications.

What you’ve experienced, and what Forrester has found, is that this isn’t a temporary pricing anomaly — it’s the fundamental way the cloud is set up. And the shift toward AI workloads is only going to make this more challenging, since there’s more demand on the business-critical systems where your most valuable information lives.

That cost pressure isn’t going away. That’s the exact problem Silk was built to solve, and we have evidence — through a report from Forrester Consulting, and borne out further by customers like Franciscan — that it works.

Forrester Consulting, the independent research firm, recently completed a Total Economic Impact (TEI) study on Silk. In this rigorous, methodology-driven research, they measured the real-world impact of our technology — both the challenges organizations faced before adopting Silk, and the improvements to SLAs, performance, and operations that came after.

They interviewed decision-makers at four organizations across healthcare, financial services, and software — organizations that together represent tens of thousands of employees and billions in revenue — and built a composite model of the results.

The headline numbers: an average Silk customer sees a 139% return on investment over three years. For a composite organization, the three-year net present value of the benefits was $6.3 million, with a less than six-month payback period. Much of that value comes from a 50% reduction in storage costs, driven by Silk’s underlying architecture, which moves away from the overprovisioning the cloud typically forces on you.

Another major area of value was productivity. Without Silk, many organizations have development and infrastructure teams working nights and weekends trying to cobble together the performance they need — at far more expense than they’d like. Forrester found Silk delivers a 60% improvement in application performance, plus significant time savings for DBA teams — for example, shrinking nightly ETL processes from many hours down to just fifteen minutes.

With that context, I want you to hear from someone who’s lived this experience. I’m honored to introduce Chuck Christian, VP of Technology and CTO of Franciscan Health — one of the largest Catholic healthcare systems in the Midwest, with eleven hospital campuses in Indiana, nineteen thousand employees, and several nationally recognized centers of healthcare excellence.

Under Chuck’s leadership, Franciscan Health has led the way in bringing Epic workloads into the cloud on Azure. Chuck brings over three decades of healthcare IT leadership — he’s been a CIO, chairman of HIMSS, and more. Welcome, Chuck.

Chuck Christian: Thanks, David. And you’ve got me a little younger than I really am — I’m actually in my sixth decade in healthcare. Four of those decades have been in healthcare IT; before that, I was a clinician in radiology.

Let me give the audience some context. We moved Epic to the cloud a couple of years ago. Back in early 2023, when I was first introduced to Silk’s technology, I wasn’t a fan — I’m an old-school guy. When the cloud first came out, I wasn’t a fan of that either, mostly because of regulatory requirements like HIPAA.

But as I understood more about how the technology works, we dug into how to make sure we wouldn’t have data loss — because the premise behind Silk is that it virtualizes storage across VMs. When you’re running things in memory, if you have a catastrophic event in the cloud, you could lose data. In healthcare, that’s not acceptable — the doctors and patients don’t like it, and neither does administration (nor would it help my continued employment, which my wife enjoys).

So it was important to understand the scope of what we were doing. When we started looking at running Epic in the cloud, storage wasn’t fast enough. Today we’re running anywhere between 17 and 20 million GRefs — global references per second, an Epic term — which tells you how fast storage has to respond. It’s mind-boggling, the performance these applications require.

We’d been running Epic on a private cloud for the last five years, and an opportunity came up to move. Our CIO, Charles, and I had been talking for a while about moving Epic to the cloud, but we didn’t want to be pioneers — nobody was really doing it with production systems yet, just DR and a few other things. We had networking work to do to make sure we had the right environment. Eventually we took the plunge and decided to move, with Silk as a partner. We also engaged a couple of other organizations to help, since we had no in-house expertise — we’d outsourced Epic management for the previous five years. It took about 18 months to get done, with partners like Silk, Microsoft, and a handful of others.

David Berliner: I think you’ve touched on the savings side. What’s the one question everybody has: how do you actually save money by moving to the cloud?

Chuck Christian: My mantra used to be: if you’re moving workloads to the cloud just to save money, get over it — it may actually be more expensive. A lot of my career has been spent trying to figure out how much it actually costs to run an application in my own data center. That’s really hard, because you have to make assumptions about what percentage of shared hardware, memory, and storage is running what. You end up with guesstimates.

When you move things to the cloud and tag them appropriately, you can tell exactly how much something costs — and once you know that, you can use the tools available to actually manage it. In 2023, after hearing a lot of horror stories about out-of-control cloud costs, I created a position called a cloud cost analyst. If anyone wants that job description, reach out — I’ve shared it many times.

Charles has a saying: “I need somebody who gets up every morning and this is what they think about all day long.” That’s the role. Eric, our cloud cost analyst, is extremely detail-oriented, and he keeps learning — as do we — about how to better manage that environment. We’re making changes right now that will net us about $200,000 a year in additional savings, just from fully understanding how Microsoft charges for consumption-based compute versus the capital investment model we used to run.

The upside of a consumption model is we can take advantage of new technology almost immediately. Silk worked directly with Microsoft to tune hardware specific to how they use the underlying platform, and we’re currently moving to those servers — savings of roughly $50,000 a month, or over half a million dollars a year.

I asked Eric to look back over the last twelve months of 2025. If you run Epic, you know every upgrade requires adding hardware — usually at the presentation layer — which means standing up more VMs in the cloud. Over the past twelve months, our physical footprint in the cloud grew by 20%, but because of how we managed cost, our actual spend only increased 3.8%. That’s a testament to the work Eric does, along with a FinOps consultant who helps on the back end.

It’s about watching it daily. Every Wednesday morning, like clockwork, Eric sends a detailed report to me, my director, and finance — where our spend is that month, how it compares, where he sees savings opportunities, and any red flags. My recommendation: if you’re not going to manage cost actively, don’t go to the cloud, because you’ll spend far more than you need to.

David Berliner: I love that you shared you weren’t initially enamored with Silk — that skepticism matters when you’re supporting a hospital system. What convinced you that Silk could meet your requirements without forcing you onto the most expensive infrastructure?

Chuck Christian: There was storage available that could meet our global-reference requirements, but it was unbelievably expensive — premium, dedicated storage in the cloud. I don’t think that’s the best use of resources; if you’re going to the cloud, you should be leveraging the shared, hyperscaled, hyperconverged environment.

Honestly, “convinced” isn’t quite the right word — I was more reassured that we weren’t making an inappropriate decision. I’ve been in healthcare since 1971; I graduated high school one day and walked into hospital training the next. At the end of the day, we can have beautiful buildings and outstanding technology, but we’re still taking care of patients. I’ve been a patient myself — lying in that bed after bypass surgery, I never once thought about the technology being used to take care of me. That’s the point: it has to be as invisible as possible. The clinical staff shouldn’t need to worry about compute — that’s my job.

I wanted two things: that it would run stably without issue, and that if we did have a problem, we could recover quickly and the environment would be resilient. It’s no different from how cloud architecture works generally — if a component has trouble, it stands up another and moves the workload over. Silk does the same thing.

Getting to know the engineering team and the CEO, asking a lot of what I call “dumb questions” — they were very good about explaining how the technology works, including backups. We now have access to their dashboards; Eric and my technical team can look at them anytime. It’s not magic. On several occasions, I’ve gotten a text or call from the engineering team saying, “We’re seeing this, we’re going to do that to prevent any disruption.” It’s like the check-engine light coming on in your car — the car doesn’t stop, it’s just letting you know something needs attention before it becomes a real problem. Being a bit of a technical geek myself, understanding how it worked helped me get comfortable that it wasn’t going to fail us.

David Berliner: On that note of resiliency — you recently flipped your entire production environment to a disaster recovery region, and essentially no one noticed. Why was that previously impossible, and what does it prove about the architecture you’ve adopted?

Chuck Christian: When I joined Franciscan just over seven years ago, they were running on-prem and about to move to a private cloud — largely because they faced a multimillion-dollar investment to shore up their DR site. We had two data centers, one in Indianapolis and one in Lafayette, and decided that money was better spent moving to a private cloud instead.

Even in the private cloud, running on Virtustream (a Dell company at the time), our production was in Sterling, Virginia, and DR was in Las Vegas — separated by real geography. We tested DR periodically but never actually failed over and ran on it.

Now, in the public cloud, our production runs in San Antonio (South Central, multi-zonal), and our DR site is in Chicago (currently single-zone). Epic requires participants in their Honor Roll program to actually fail over and run for a period of time — a day, a month, six months, whatever you choose, as long as you can prove it works. We did that in November of last year.

In October, we failed over to North Central on a Thursday — our regular monthly downtime window. We went down, failed over, and came back up 45 minutes later, right on target. The following month I sat in on the Physicians of Central Indiana leadership meeting, and when asked if I had anything to share, I mentioned we’d failed over to our DR site a couple of weeks earlier. Their response: “When? We didn’t notice.” Exactly the point.

When we failed back in November, same thing — routine downtime, came back up now running in San Antonio. This ties into a broader initiative we’ve had going for over a year and a half called Blackout Blueprint — planning how the organization runs in the event of a major incident. We’re also working on an integrated, isolated recovery environment, fully separated from the rest of the network. That resiliency — proving we can fail over during a real DR event — reassures our board and our sisters (we’re a Catholic healthcare system) that we’re being good stewards of the organization.

David Berliner: You’ve also worked with a partner, Optify, on this journey. How has that experience been?

Chuck Christian: It continues to be good — we leverage their expertise. Optify is a partnership between Sentara Health and Infinite. Sentara had already been experimenting early on with moving workloads to Azure, so it’s been a good partnership, and we continue to lean on their expertise as needed. They’re also on our RFP list for building out the isolated recovery environment.

David Berliner: Are there new use cases you’re exploring — more resilient architecture, AI inferencing, additional onboarding — that were cost-prohibitive before adopting Silk?

Chuck Christian: We’ve recently stood up our data lakehouse using Databricks on Microsoft, and we’re working on migrating our current data management platform there. We’ve also had conversations with the folks at Synterro about how they’re leveraging the Silk platform to create zero-cost, mountable database copies.

Going back to the ETL point — ours used to run five to seven hours or more a night, and we have a cutoff for when reports need to be ready each morning. Since moving to Silk, that’s dropped to about an hour or two. Synterro has also shown us how to split reporting workloads off into separate nodes — snapping a copy, mounting it, and running two groups of reporting servers without duplicating storage cost. We haven’t needed that yet, but it’s absolutely on our list.

David Berliner: You mentioned quantifying roughly $2.8 million in annual direct savings from using Silk. Where did those savings come from — storage, compute, elsewhere?

Chuck Christian: Most of it is on the storage side — comparing what standard or premium storage would have cost versus what we’re paying now. Silk compresses and dedupes on the fly, so we’re using far less virtualized storage than we would with hard storage. In essence, Silk is paying for its own license cost on an annual basis.

David Berliner: What’s been the impact on your DBA team? Have refresh cycles or environment provisioning changed meaningfully?

Chuck Christian: There’s so much change happening in the environment that it’s hard to isolate. As we build out the data lakehouse, the team is continually refining their processes. It’s tough for me to say definitively what “life could have been” — that’s a branch of the timeline we haven’t experienced, since our databases keep growing over time regardless.

David Berliner: Thinking back to when you built the internal business case to move to the cloud and onto Silk — what were the core points you used to convince leadership this was the right solution?

Chuck Christian: We used a consultant group to help write that business case. It needed to be cost-neutral, essentially — like a three-legged stool: better, faster, cheaper. The rule of thumb is you can typically get two of the three, not all three.

We wanted a more modern environment and data adjacency to our data warehouse. My role requires me to look over the horizon — you can’t make architectural changes quickly, they have to be planned and budgeted 18 to 24 months out, and the further out you look, the cloudier that crystal ball gets. Healthcare systems expand and contract, and we’ve done both during my tenure, so we needed a flexible platform.

There are always costs to moving data — ingress, egress, even movement within the cloud, though that’s minor (it’s like the cable company, they never miss a chance to charge you for something). We wanted something we could visualize, watch, understand, and control. It needed to be resilient — I’ll call it “self-healing,” even though that’s a bit of a misnomer — because hardware fails, and if you architect well with the right partners, you minimize downtime.

But the technology is only part of it. One reason for our Blackout Blueprint project is helping our operational leaders understand how we run our facilities without the technology, if it ever comes to that. It’s like power to your home — you don’t realize what you’re dependent on until it goes out. I have a 24kW whole-house generator; when my power goes out, it’s back in three seconds. We wanted that same resiliency for our organization. And of course, we also wanted something that wouldn’t break the bank — the difference between running this for a single hospital versus an eleven-hospital system is just more zeros on the budget, which makes controlling those costs even more important.

Audience Q&A

Q: If you were talking to another IT leader struggling with cloud costs and performance, what’s one thing you wish you had known before starting this journey?

Chuck Christian: [laughs] My retirement date — just kidding. I don’t think there’s one single thing. It’s like golf — I’m not good at it, but I still enjoy it, and every time I play I learn something new, either what to do or what not to do. It’s the same with moving architecture to the cloud.

One thing I’d remind everyone: if you think you can move everything to the cloud, you’re wrong. When I joined Franciscan, I was told, “We have a cloud-first strategy — we’re moving everything to the cloud.” I asked whether our legacy, self-written applications could run in the cloud, and the answer was, “We don’t know.” I said, “Then you don’t have a cloud-first strategy — you have a workload placement strategy.” That’s the language we shifted to.

Some vendors simply require on-prem hardware. Our oncology systems running radiation treatment machines have to run on-prem — they won’t run in the public cloud, only a private one. Same with critical care systems like cardiac monitors. We did consolidate a lot of our IoMT solutions — cardiac monitoring went from 12 different sets of on-prem servers down to two sets in a high-availability pair in the data center, eliminating 70–80 servers. But when I asked the vendor (Philips) if we could run that in the cloud, they said, “Sure — want to be first?” No thanks.

So you have to be clear about your intentions. Some applications may never run in the cloud until we switch vendors — not everything is cloud-agnostic or easily portable. We followed the Gartner quadrant approach: did the easy migrations first, and now we’re tackling the harder ones, including applications that vendors themselves need to upgrade and migrate — those are the most costly.

Q: Did you consider an exit strategy as part of your entry into the cloud?

Chuck Christian: Yes, that’s always something you need to think about. There’s a term — vendor lock-in — that we’ve seen with plenty of vendors who try to keep you tied in. If I moved Epic from on-prem to a private cloud and now to the public cloud, I can do the same thing again — move to another cloud, or back to private. It’s movable; it just costs money, and that’s the consideration: what’s the cost of the change?

In some cases you don’t have a choice — when Virtustream/Dell decided to exit the private cloud/data center business, we either had to find another private cloud provider or move to the public cloud. We chose the latter because we felt we could manage costs better and gain more flexibility than we had on-prem.

David Berliner: Thank you, Chuck, for sharing your experience so candidly. And thank you to everyone who joined today. Three things to keep in mind if you’d like to learn more:

1. We’re happy to share a one-page summary of the Forrester TEI study as a post-session follow-up.
2. We can build a custom Total Cost of Ownership study for your organization, modeling what Forrester found for Silk customers against your own environment.
3. And a parting thought: in many cases, the question isn’t “Can we afford to fix this?” — it’s “Can we afford not to?”

Thank you all — and thanks again, Chuck. Hope you all have a great day.

Chuck Christian: Thanks very much. Appreciate it.