Faisal Zain stands at the intersection of traditional medical device manufacturing and the rapidly evolving world of digital health infrastructure. With a career dedicated to driving innovation in diagnostic and treatment technologies, he has witnessed firsthand how the promise of “digital transformation” often hits a wall of technical debt and architectural misalignment. Faisal argues that the healthcare industry’s obsession with “moving to the cloud” is frequently a misunderstood journey, leading many organizations to overpay for outdated structures. He advocates for a rigorous maturity model, emphasizing that the real value of the cloud lies not in where data sits, but in how it is architected to support the next generation of clinical AI and real-time decision-making. This conversation explores why so many health systems stall at the initial stages of migration and how they can pivot toward a more sustainable, high-performing future.
Many organizations find that moving existing servers to a cloud provider actually increases their monthly expenses. Why does this “lift-and-shift” approach often backfire financially?
The primary reason is a fundamental misunderstanding of what the cloud is designed to do versus how legacy software functions. In this initial stage, which we call relocation, teams essentially pick up their existing servers and drop them into a provider’s data center without changing a single line of code or architectural logic. It feels like a win because you can tell the board you’ve reached a “cloud milestone,” but you’re essentially renting a virtual machine to run 24 hours a day, seven days a week, just like the hardware you used to own. Since that hardware was likely already paid off and depreciated, moving to a subscription-based rental model for the exact same performance actually drives costs up in that first year. You haven’t changed the “thing” itself; you’ve just changed the garage it sits in, and the landlord is now charging you a premium for the convenience.
Once a system realizes that simply relocating servers isn’t enough, what does a successful transition into the optimization stage actually look like on the ground?
Optimization is the moment when the cloud starts paying for itself because you finally begin using the tools that justify the price of admission. Instead of running a self-hosted database that requires constant manual patching and overhead, you move to a managed database service provided by the cloud vendor. You start getting smart about storage, moving data that hasn’t been touched in years from expensive, high-speed block storage onto much cheaper object storage. Perhaps most importantly, you stop paying for idle capacity; instead of having a server farm running at full tilt during the quiet hours of three in the morning, your infrastructure automatically scales down to match the actual demand. It’s a shift from static ownership to dynamic consumption, though it’s important to remember that the underlying applications are often still monolithic at this point.
You’ve noted that “cloud-native refactoring” is the stage most health systems skip or never fully reach. Why is breaking down these monolithic applications so uniquely difficult in a healthcare environment?
Refactoring is genuinely hard work because it isn’t just a technical update; it reaches into the very fabric of clinical workflows and existing vendor contracts. To do this properly, you have to break those giant, rigid monoliths into smaller, agile services and adopt an API-first posture. This is where FHIR-native data exchange becomes the standard, replacing the clunky nightly batch files and the dozens of one-off interfaces that healthcare has relied on for decades. The reason it gets skipped isn’t a lack of talent, but rather because there is no “magic button” or vendor you can simply pay to do it for you. It requires a year or more of grueling “plumbing” work that doesn’t always result in a flashy new app to show off, so it often keeps sliding to next year’s roadmap.
If a health system successfully navigates that refactoring, they arrive at the “data platform” stage. How does this shift the way they handle clinical data and governance?
At this stage, the organization stops treating every application as a silo that needs to reach into the Electronic Health Record (EHR) on its own terms. Instead, you build a curated, governed data layer that serves as the single source of truth for the entire enterprise. Governance functions like lineage, versioning, audit trails, and access controls are handled once at the platform level, rather than being reinvented or duplicated inside every separate tool. This is the only way to make analytics and AI work at a real, meaningful scale because every tool is finally reading from the same playbook. It creates a sense of reliability where clinicians can trust the data they see, knowing it hasn’t been mangled by five different “private copies” of the truth held by various departments.
We are seeing a lot of excitement around “agentic AI” and real-time clinical support. What are the risks of deploying these advanced Stage 5 tools on a Stage 1 or Stage 2 infrastructure?
This is where the strategy gets incredibly expensive and, frankly, quite risky for patient care. I have seen health systems with the best intentions go out and buy a high-end population health engine or an agentic AI tool that assumes a clean, governed data layer already exists. Because the underlying plumbing isn’t there to support it, the integration team has to improvise and “duct-tape” brittle connections just to get the initial demo working for leadership. Fast forward eighteen months, and those same connections become the root cause of massive outages and cost overruns that someone eventually has to explain to the board. You cannot skip the foundational stages of maturity and expect a Stage 5 capability to survive contact with a Stage 2 reality; it will eventually break under the weight of its own complexity.
Given that the “middle stages” of refactoring and platform building are often invisible to non-technical leadership, how can IT teams better advocate for the funding of this “plumbing”?
The most successful organizations are the ones that are honest about which stage they are actually standing on, rather than where they wish they were. When evaluating an impressive vendor demo, leadership needs to ask if their current architecture can support what that tool takes for granted—usually clean, real-time, governed data. You have to frame the investment in refactoring not as a “tech project,” but as an insurance policy against the outages and overruns that never happen when the foundation is solid. It’s a difficult sell in a budget meeting because the payoff is essentially the absence of failure, but once you show the board the 18-month failure rate of “skipping ahead,” the value of doing the hard work of Stage 3 and 4 becomes much clearer.
What is your forecast for the future of healthcare cloud maturity?
I believe we are heading toward a period of “architectural reckoning” where the hype of AI will force health systems to finally confront their legacy technical debt. Over the next few years, the gap will widen between systems that treat the cloud as a mere data center replacement and those that treat it as an operating model for adaptive, real-time care. We will see more organizations move toward “adaptive operations” where infrastructure adjusts to clinical demand on its own and cost management runs as a continuous, automated process rather than a quarterly scramble. The winners won’t necessarily be the ones with the largest budgets, but the ones with the discipline to fund the unglamorous work of data governance and refactoring today, so they can actually run the agentic AI of tomorrow without a constant fire drill.
