The empty house problem: vendor migrations and healthcare breach risk

You can outsource the server. You cannot outsource the liability.

On October 9, 2026, Fierce Healthcare reported, citing Bloomberg and an October 2 filing by the Texas attorney general, that the 2025 breach of legacy Cerner servers exposed data on nearly 20 million people. The exposed records included Social Security numbers, addresses, and medical information. Oracle, which acquired Cerner, has not published a total of its own.

Two details in that report matter for every health system running a platform migration.

The entry point was a house no one had emptied

Oracle's early notice to customers said attackers reached patient data through legacy servers that had not yet moved to Oracle Cloud. The organization had moved into the new house. The back door of the old one was still unlocked. That is the shape of most migration breaches: the data that hurts you is rarely in the system you are watching. It is in the one you have half-left.

The court will not let you contract the risk away

In June 2026, a federal judge allowed the consolidated class action to proceed against eight health systems as well as Oracle. The judge rejected the argument that the breach was the vendor's problem alone, and the reasoning is the part to sit with: a provider is not absolved of liability by contracting it out to a third party. You can delegate the operation. You keep the duty.

Why mid-migration systems are the weak point

A system in the middle of a migration is in the worst possible state. It is still full of data, no longer the focus of the team's attention, and often no longer clearly owned. Patching slows. Monitoring thins. Everyone assumes it is someone else's last week of work. That gap, measured in weeks or months, is exactly where this breach lived.

What to require in the contract

The protections that matter are the ones written down before cut-over, not improvised after a notice letter.

• A named owner for the legacy system through its final day, and for the cut-over itself.
• An inventory of what data stays behind and a firm date for its destruction.
• A destruction certificate, not a verbal assurance, when that date passes.
• Breach-notification deadlines and audit rights written into the business associate agreement.
• The right to verify decommissioning yourself, rather than take it on faith.

How we handle migrations

Before any cut-over on a client build, we take a full data inventory, set a decommission date for the system being retired, and keep a destruction log against it. The old system gets an owner and an end date in writing. The window between platforms is treated as its own risk, with its own controls, because that is the window where the data actually sits exposed.

When your last migration ran, you can probably name who stood up the new platform. The harder and more important question is who was watching the old one on its final day.

Sources: Fierce Healthcare.