Why Cloud PACS Has a Reputation for Being Expensive, and What’s Actually Behind It

Cloud got a reputation for being expensive in healthcare. That reputation is deserved, just not for the reasons most people think.

For many radiology IT managers and hospital decision-makers, the hesitation around cloud PACS comes from a very real place. Teams that moved to cloud-hosted systems found their costs did not drop as promised. In some cases, they went up.

The cloud felt like a different address for the same problem. That experience is valid. But the source of it is not cloud itself. It is a specific deployment approach called lift-and-shift.

When the major PACS vendors moved to the cloud, most re-hosted their existing platforms inside a virtual machine on AWS or Azure. The vendor called it cloud. The architecture stayed the same.

This is lift-and-shift. And it is the primary reason cloud PACS developed a reputation for high cost without the corresponding benefit.

Here is what that looks like in practice:

• Paying for capacity, not usage. VMs are sized for peak demand. You pay for headroom whether you use it or not, and costs grow with infrastructure, not with imaging volume.
• Upgrade projects still on the calendar. Legacy architecture was not designed for continuous deployment. Major upgrades still require planned downtime and budget every time they occur.
• IT team still managing infrastructure. Server sizing, patching, and availability monitoring often remain the responsibility of the healthcare organisation, not the vendor.
• Admin burden follows you to the cloud. Manual workflows and complex integrations that existed on-premise persist in lift-and-shift environments. The location changed. The complexity did not.

None of this is cloud’s fault. It is what happens when legacy architecture is deployed in a cloud environment and expected to deliver cloud-native outcomes.

Cloud-native means the platform was built from the ground up to run in a cloud environment, not adapted for it after the fact.

That distinction matters because the architecture determines the cost structure, the operational model, and what your team is responsible for.

A genuinely cloud-native PACS platform removes the costs that lift-and-shift carries over:

• No hardware to procure, size, or refresh. Infrastructure is fully managed by the platform provider. Your team has no server responsibility.
• Costs tied to imaging volume, not infrastructure. Pay-as-you-go pricing moves in line with actual clinical activity. Growth is predictable, not capital-intensive.
• Continuous delivery, no downtime. Updates deploy automatically. No maintenance windows, no upgrade projects, no clinical disruption.
• Open architecture. Standard APIs replace proprietary connectors, making it easier to connect to your wider clinical and enterprise ecosystem

The table below shows how the two approaches differ across the cost categories that matter most to Radiology IT and hospital decision-makers. 

For C-suite decision-makers, PACS cost conversations tend to focus on the contract value. But the real number includes IT staff time, planned downtime, upgrade projects, and the indirect cost of slow clinical workflows.

A lift-and-shift platform moves some of these costs off-site. It rarely eliminates them.

The right comparison is not cloud vs. on-premise. It is cloud-native vs. lift-and-shift, and that gap compounds significantly over a three-to-five year horizon.

These questions will quickly reveal whether you are evaluating a cloud-native platform or a lift-and-shift:

• Was this platform purpose-built for cloud, or migrated from an on-premise codebase?
• How are major version upgrades delivered, and do they require planned downtime?
• Who is responsible for infrastructure sizing, patching, and availability?
• Is pricing tied to imaging volume or to infrastructure capacity?
• What does the five-year total cost look like when IT overhead, upgrade projects, and downtime are factored in?

A cloud-native vendor should answer these directly. If the conversation steers toward infrastructure specs rather than operational outcomes, that is a signal worth taking seriously.

At AdvaHealth Solutions, we have spent years making the case for true cloud-native infrastructure in healthcare imaging. We kept seeing the same pattern: organisations that moved to cloud PACS and found the costs and complexity came with them.

AdvaPACS was built cloud-native on Amazon Web Services from the ground up. Not a virtualised legacy system. A platform where the cost structure of traditional PACS simply does not apply.

The fear of expensive cloud is understandable. It came from real experience with the wrong kind of cloud. The answer is not to avoid the cloud. It is to understand what truly cloud-native looks like, and hold vendors to that standard.

Explore how AdvaPACS approaches total cost of ownership differently.

Learn more about the financial and operational model behind a truly cloud-native PACS: