What Happens When Your PACS Vendor Sunsets Your System
Your PACS vendor just announced end-of-life. Here's what actually happens next, the real risk data, and how managed support bridges the gap safely.
The email is usually short and almost apologetic. Effective a date roughly twelve months out, your PACS version will reach end of general availability; support and security updates will cease; please contact your account manager to discuss migration options. Nothing breaks that day. Nothing breaks the next month either. That is exactly what makes an end-of-life notice dangerous — the consequences arrive on a delay, and by then the cheap options have expired. What actually happens next depends almost entirely on one thing: whether the environment moves into managed PACS support while there is still time to choose, or drifts unmanaged until an incident chooses for you.
By Trisha Seal — September 3, 2026. RAD365 runs vendor-agnostic managed PACS support with real engineers on shift nights, weekends and holidays, flat monthly pricing, and legacy and deprecated imaging system support as a named specialty — including keeping end-of-life environments running safely while a migration is planned and executed.
What Is PACS, and Why Does End-of-Life Support Matter?
PACS — Picture Archiving and Communication System — is the software and storage layer that receives imaging studies from CT, MRI, X-ray, ultrasound and other modalities in DICOM format, archives them, and serves them back to diagnostic workstations with their priors. It sits between every modality and every radiologist, which is why it is rarely the loudest system in the estate and always one of the most load-bearing.
End-of-life matters because a PACS is not a standalone application. It is a web of interfaces to the RIS or EHR, DICOM routing, storage and archive tiers, and modality worklists. When vendor support ends, every one of those seams loses its owner of last resort — and the studies in the archive still have to be retrievable for years.
Why Vendors Declare a PACS End-of-Life
It is almost never about your facility. Three forces drive most sunset announcements. Consolidation: after an acquisition, no vendor maintains two overlapping products indefinitely, so the smaller install base is retired. Cloud-native replacement: supporting an ageing on-premise architecture in parallel with a newer cloud platform doubles engineering cost, so the older line is sunset to force convergence. Dependency expiry: when the operating system or database underneath the PACS loses its own vendor support, certifying the application on it stops being viable.
That last one is more common than most IT leaders expect. Censinet's healthcare cybersecurity risk research reports that 73% of healthcare providers still depend on outdated or legacy IT systems — with 20% still running Windows XP, unsupported since 2014, and 35% on Windows Server 2008. Clinical imaging environments are heavily represented in that population precisely because they are stable, validated and expensive to disturb.
Average cost of a single PACS/imaging-system downtime incident (imaging downtime study reported via AuntMinnie)
Cost range for a typical 3.5-hour imaging system outage (AuntMinnie)
Annual downtime loss for a medium-sized 200-bed facility (AuntMinnie)
Estimated healthcare losses to system downtime, 2018–2024 (Censinet)
What an Unplanned Gap Actually Costs
The reason an end-of-life PACS is a financial problem and not just a technical one is that imaging is disproportionately revenue-bearing. The imaging downtime analysis reported via AuntMinnie puts the average PACS or imaging-system downtime incident at more than $94,000, with a typical 3.5-hour outage running between $55,000 and $132,716, and a medium-sized 200-bed facility losing almost $300,000 a year to downtime — against imaging representing roughly 37% of total hospital system revenue.
Layer the security picture on top. Censinet reports that 81% of healthcare data breaches in 2024 involved hacking or IT-related incidents, and that healthcare organisations lost an estimated $21.9 billion to system downtime between 2018 and 2024. An unpatched, unsupported PACS is simultaneously the system most likely to fail and the one whose failure costs the most per hour.
Your Three Options When PACS Goes EOL
Every facility that receives a sunset notice picks one of three paths, whether deliberately or by default.
| Option | Cost profile | Risk profile | Timeline |
|---|---|---|---|
| Do nothing — run it unmanaged until something forces the issue | Zero up front; unbounded on the day of an incident, at $94K+ per event | Highest. No patches, growing published-vulnerability exposure, likely audit and insurance findings | Indefinite until an incident sets it — and incidents set brutal timelines |
| Rush a full migration — replace inside the vendor's notice window | Highest immediate capital and project cost; weak negotiating position under time pressure | Elevated. Compressed data migration, thin validation, priors and hanging protocols at risk | Whatever the vendor's notice allows, which is rarely what the archive needs |
| Bridge with managed legacy support — stabilise now, migrate on your schedule | Predictable flat monthly fee; migration cost deferred to a properly scoped project | Lowest. Compensating controls, monitoring and tested recovery in place; documented for audit | 12–24 months of stability, migration planned in quarters rather than weeks |
How a Managed Partner Bridges the Gap
- Environment discovery and documentation. Interfaces, DICOM routing, storage tiers, hanging protocols, integration points, known workarounds. Most end-of-life environments are undocumented because the knowledge lives with one long-serving administrator — capturing it is the first risk reduction, before anything technical changes.
- Continuous monitoring and staffed response. Archive health, interface queues, storage headroom and study-flow anomalies watched around the clock, with engineers on shift at nights, weekends and holidays rather than an alert waking someone who then starts from scratch. This is the core of day-to-day radiology IT support on an unsupported system.
- Compensating security controls. Network segmentation, tightened access paths, hardened endpoints, verified backups with tested restores, and documented evidence that each control is operating — the artefacts that turn an unsupported system from an audit finding into a managed, defensible risk.
- Vendor and third-party coordination. Whatever residual support exists gets chased on your behalf, alongside modality vendors, storage providers and integrators, so your team is not brokering between four companies during an incident. This is where interim PACS support earns its place.
- Parallel running through cutover. When the replacement is selected, the legacy environment stays fully supported while data moves, and both run in parallel until priors are proven retrievable in the new system. A structured PACS migration retires nothing before its replacement is validated, and the DICOM gateway layer is what keeps studies flowing to both during that window.
- Reporting against a defined framework. Incidents, response times against SLA, patch and control status, backup verification — reported on a set cadence to IT and clinical leadership. The RAD365 PACS support framework exists so this is a standing report, not an annual scramble before a committee meeting.
The Question Behind the Notice
A sunset announcement is not really a question about software. It is a question about whether your imaging environment has an owner when the manufacturer stops being one. Facilities that answer it early buy themselves a normal migration: scoped properly, tendered competitively, validated thoroughly, executed on their own calendar. Facilities that answer it late buy the same migration at a worse price, under time pressure, with an unpatched archive carrying the risk in the meantime.
The notice sets a date. What it does not set — and what is entirely yours to decide — is whether the twelve months between now and then are managed or merely survived.
Facing an end-of-life notice on your PACS?
RAD365 provides vendor-agnostic managed PACS support with real engineers on shift nights, weekends and holidays, flat monthly pricing, and legacy and deprecated system support as a named specialty — including keeping your current environment stable while a migration is properly planned.
Request a PACS environment review →PACS End-of-Life and Managed PACS Support: Frequently Asked Questions
Recognizing an End-of-Life Situation
How do I know if my PACS vendor is planning to sunset our system?
The formal end-of-life notice is usually the last signal, not the first. Earlier indicators include feature releases that stop arriving for your product line while a newer platform gets them, support tickets increasingly answered with workarounds rather than fixes, renewal quotes that rise sharply without added scope, the vendor being acquired or acquiring a competing product, and account conversations that repeatedly steer toward 'migration planning'. If your named support engineer changes three times in a year and documentation stops being updated, treat that as a planning trigger rather than an inconvenience.
What typically triggers a vendor to declare a PACS product end-of-life?
Three drivers dominate. Consolidation: after an acquisition, a vendor rarely maintains two overlapping products indefinitely and retires the smaller install base. Cloud-native replacement: maintaining an on-premise architecture alongside a newer cloud platform doubles engineering cost, so the older line is sunset to force convergence. Underlying dependency expiry: when the operating system, database or middleware a PACS was built on loses vendor support, continuing to certify the application on it becomes commercially untenable. None of these are about your facility — which is precisely why the timing is rarely convenient.
Can a hospital keep running a discontinued PACS safely, and for how long?
Yes, safely and for a defined period, but only with compensating operational controls rather than by default. That means active monitoring, tightened network segmentation and access control, verified and tested backups, a documented incident and rollback plan, and engineers who know the environment well enough to intervene without vendor escalation. Under those conditions many facilities bridge 12 to 24 months while a migration is planned properly. Without them, the environment is not being run — it is being hoped over, and the risk curve rises every month.
What happens to vendor security patches once a PACS reaches end-of-life?
They stop, and that is the operative change. New vulnerabilities in the application, or in the operating system and database beneath it, continue to be discovered and published — but no fix arrives for your version. The exposure is not static; it grows with every disclosure cycle. Mitigation shifts from patching to compensating controls: segmentation, restricted access paths, hardened endpoints, continuous monitoring for anomalous behaviour, and a tested recovery plan. Those controls are the core of what managed legacy support is for.
Risk & Compliance
What compliance risks does an unsupported PACS create for a hospital?
The core risk is that a known, published vulnerability with no available patch is difficult to defend as reasonable and appropriate safeguarding. Auditors and cyber insurers increasingly ask specifically about unsupported software in clinical systems, and an unmitigated end-of-life PACS holding protected health information is a finding waiting to be written. The defensible position is a documented risk assessment, a written compensating-control set, an approved remediation timeline, and evidence the controls are actually operating — not merely specified.
Does running an end-of-life PACS affect our HIPAA security risk assessments?
It changes what the assessment has to demonstrate. The system must be recorded as unsupported, the resulting risks analysed specifically rather than generically, and each risk paired with a compensating control and a remediation plan with dates. What generally fails review is an assessment that carries the PACS forward unchanged from the prior year as though vendor support were still in place. A managed support partner's monitoring logs, patch-status reporting and incident records are usually the evidence that makes that section of the assessment defensible.
What certifications should a managed PACS support provider hold?
Look for evidence of an audited security posture rather than a logo collection. HITRUST certification is the credential most often asked for in healthcare IT diligence because it maps controls to HIPAA and other frameworks and is independently assessed; HIMSS-related credentials and demonstrable HIPAA compliance programmes also come up consistently in evaluations. Beyond certificates, ask for the practical artefacts: signed business associate agreements, documented access-control and offboarding procedures, evidence of staff background screening and security training, and a written incident-response plan you are allowed to read before you sign.
How does an unsupported PACS increase cybersecurity exposure?
Legacy clinical systems are a well-documented weak point. Censinet's healthcare cybersecurity risk research reports that 73% of healthcare providers still depend on outdated or legacy IT systems, with 20% still running Windows XP — unsupported since 2014 — and 35% on Windows Server 2008. The same analysis found 81% of healthcare data breaches in 2024 involved hacking or IT-related incidents, and that healthcare organisations lost an estimated $21.9 billion to system downtime between 2018 and 2024. An unpatched PACS is both a high-value target and a lateral pivot point into the wider clinical network.
Bridging the Gap
What is interim or bridge PACS support, and when is it needed?
Bridge support is operational engineering that keeps an existing imaging environment stable and defensible for a defined window when vendor support is unavailable or insufficient. It is typically needed in four situations: a vendor has declared end-of-life, a migration is planned but not yet funded or scheduled, a sole PACS administrator has left, or two systems must run in parallel during a consolidation. Its purpose is to remove time pressure so that migration decisions are made on clinical and commercial merit rather than under duress.
Can a managed PACS partner keep a legacy system running while we plan a migration?
That is one of the most common reasons facilities engage RAD365, and legacy and deprecated system support is a named part of our service. In practice it means 24/7 monitoring of the archive, interfaces and storage; incident response by engineers who have documented your specific environment; management of backups and recovery testing; coordination with the outgoing vendor and any third parties for whatever residual support exists; and running the legacy and replacement environments in parallel during cutover so nothing is retired before the replacement is proven.
How long does a typical PACS migration take once a vendor sunset is announced?
Data migration is the long pole and it is driven by archive size, study count, the state of the metadata and how much cleanup the legacy data needs — not by how urgent the sunset notice feels. Realistically most facilities should plan in quarters, not weeks, with parallel running through cutover and a validation period afterwards to confirm priors are retrievable and hanging protocols behave. The bridge exists precisely so that this timeline can be honest instead of compressed into whatever window the vendor's notice happened to allow.
What SLAs should a managed PACS support company guarantee during a vendor transition?
Ask for commitments on the things that actually hurt during a transition: response and resolution targets by severity, with a defined severity matrix; guaranteed coverage hours that explicitly include nights, weekends and holidays; a named escalation path with human contacts rather than a shared queue; uptime or availability commitments for the environments under management; defined backup and restore verification cadence; and reporting frequency to your IT and clinical leadership. Equally important is what the SLA excludes — get the exclusions in writing before the transition, not during it.
Choosing a Managed PACS Partner
How do I evaluate managed PACS support companies before signing a contract?
Test four dimensions. Independence: do they resell a PACS product, and would that shape their advice on your migration? Depth: are there named engineers with imaging-specific experience, or a generalist service desk that escalates everything? Evidence: can they show documented experience with legacy and end-of-life environments and with your specific vendor's systems? Commercials: is pricing a predictable flat monthly fee, or does every incident become a change request? Then ask for references from facilities that went through a vendor sunset, and ask those references specifically about the 2 AM incidents.
What's the difference between vendor-direct support and vendor-agnostic managed PACS support?
Vendor-direct support covers one manufacturer's product and, understandably, has a commercial interest in where you go next. It stops at the product boundary — interfaces, gateways, third-party integrations and everything between systems are usually somebody else's problem. Vendor-agnostic managed support covers the imaging environment as a whole regardless of which logos are in the rack, coordinates the vendors on your behalf, and has no financial stake in which platform you migrate to. During an end-of-life transition, that neutrality is the point.
Can a managed PACS provider work across multiple imaging modalities and vendors at once?
Yes, and a mixed estate is the normal case rather than the exception. Most facilities run CT, MRI, X-ray, ultrasound and mammography from different manufacturers, feeding an archive from one vendor through interfaces built by another. A vendor-agnostic managed model treats the DICOM and HL7 pathways between those systems as the primary object of support, which is exactly where multi-vendor environments break and exactly where single-vendor support declines to look.
What does managed PACS support typically cost compared to hiring an in-house PACS administrator?
RAD365 does not publish rate figures, but the structural comparison is straightforward. An in-house administrator is a fully loaded salary plus benefits, recruitment and training, and delivers coverage for roughly one shift, five days a week, with a single-person dependency for every hour outside that. Managed support is a flat monthly fee covering a team across nights, weekends and holidays, with documented environment knowledge that does not resign. Build both models over a three-year horizon and include the cost of the coverage gaps in the in-house column — that column is usually left blank, and it is where the real difference sits.
Do managed PACS providers offer true 24/7 monitoring, or just business-hours support?
It varies more than the marketing suggests, and the distinction is worth interrogating. Some providers offer an on-call rota where an engineer is woken after an alert; others, RAD365 included, staff real engineers on shift overnight, at weekends and on holidays. Ask three questions: at 3 AM on a public holiday, is someone already working or being paged? What is the committed response time at that hour, in the contract? And is monitoring automated alerting only, or is a person actively reviewing the imaging environment's health?
What questions should I ask before renewing or switching PACS support providers?
Ask what the current provider actually did last year — incident counts, response times against SLA, problems prevented rather than tickets closed. Ask what is excluded from scope and how often those exclusions generated extra charges. Ask who holds your environment documentation and whether you would receive it on exit. Ask how they would handle an end-of-life announcement from your PACS vendor next quarter. And ask what happens at 2 AM on a holiday. Renewal conversations tend to focus on price; the answers that matter are about coverage and exit.