Oracle bought Cerner, and Cerner customers inherited a cloud strategy

The week

On December 20, 2021, the Monday before Christmas, Oracle announced an agreement to acquire Cerner for approximately $28.3 billion in cash. For a mid-sized health system on Cerner, the software that holds every patient’s chart, every medication order and every bill the hospital sends had just been sold. Nothing on the screens changed. Nurses still charted, doctors still ordered, the billing office still billed. But the company behind all of it now answered to someone new.

The timing made the news easy to miss inside hospitals. The Omicron variant was spreading fast across the United States that week, and many health systems were short of staff and filling beds. Chief information officers were also still working through the Log4j software flaw disclosed earlier in December. A vendor acquisition announced on the eve of the holidays went to the bottom of a long list.

Cerner was one of the two largest electronic health record vendors in the United States. An electronic health record, or EHR, is the core clinical system of a hospital: the digital version of the paper chart, plus the ordering, scheduling, documentation and billing machinery wrapped around it. Cerner was founded in Kansas City in 1979, and its main hospital platform, Millennium, ran in hospitals of every size, from small community facilities to large academic centers, in the United States and abroad.

The company had been through a period of change before the deal. Its chief executive, Brent Shafer, announced in May 2021 that he would step down. In October 2021 David Feinberg, a physician who had run the Geisinger health system and then led Google Health, took over as chief executive. Two years before that, in July 2019, Cerner had named Amazon Web Services its preferred cloud provider. Customers who followed Cerner’s strategy had been told that their record’s future lay on a cloud run by a company other than the one now buying it.

Oracle is best known for databases, the engines that store and retrieve an organization’s data. It also sells cloud infrastructure, meaning computing power and storage that customers rent from Oracle’s data centers instead of running their own. Oracle was open about how it saw the deal. It said it would accelerate the modernization of Cerner’s systems and run them on its own cloud infrastructure. It was buying a health software business and, with it, a large and loyal set of customers for its infrastructure.

The structure was a cash tender offer at $95 per share. In a tender offer, the buyer offers to purchase shares directly from the target’s shareholders, and the deal completes once enough of them accept and the regulatory approvals are in hand. The announcement set out that path. It did not set out a product roadmap, a hosting timetable or new contract terms for hospitals. Those were left for later.

Those customers included many US hospitals and health systems, and two of the largest public health operations in the country. The Department of Veterans Affairs had signed a contract with Cerner in May 2018, with a ceiling of about $10 billion over ten years, to replace its homegrown VistA record. It went live at its first site, in Spokane, Washington, in October 2020. In March 2021 Secretary Denis McDonough paused further deployments for a strategic review after problems at that site, and the program resumed after the review ended that summer.

The Department of Defense was a customer too. Its record, MHS GENESIS, was built on Cerner’s platform and was being rolled out wave by wave across military hospitals and clinics. For both departments, a supplier decision made years earlier had just become a relationship with a different company. The same was true for every county hospital and multi-state system that had signed with Cerner.

The deal did not complete overnight. The acquisition closed in June 2022, and the business later operated as Oracle Health. But the questions for customers began the day of the announcement. What would happen to the product they depended on? Where would it run? And what would the contract say when it came up for renewal?

Acquisitions of enterprise software vendors are common, and customers often experience them as little more than a new logo on the invoice. This one differed in scale and in kind. Oracle was buying a health record vendor and, with it, a large and durable customer base for its database and cloud infrastructure. It said so publicly. For a health system on Cerner, the relationship with its most important software supplier would increasingly be about infrastructure as well as clinical software.

That shift changes who inside a hospital has to pay attention. A software sale is usually the business of the CIO and the procurement office. A change in infrastructure strategy reaches further. The CISO owns security controls and the general counsel owns the contracts. The CFO owns the long-range capital plan, and the chief medical information officer owns the clinical safety of any change to workflows. Each needed a view of the deal, and each would see a different part of it.

Three areas needed fresh thinking, each on its own clock: the product roadmap, the hosting model, and the commercial terms. Roadmap questions mattered first, because projects were being scheduled. Hosting questions mattered next, because a migration takes years to plan. Commercial questions mattered at each renewal date, which differs for every customer. First, though, why a health record is so different from most software a hospital buys, and why a change in who owns it ripples so far. After the three areas, we look at whether to switch, at the risks a sale hands to the board, and at how the better-prepared systems responded.

More than a digital chart

Most executives think of software as something you can swap out. If the expense system is clumsy, you buy a better one. A hospital’s electronic health record does not work like that.

At its simplest, the record stores each patient’s history: diagnoses, allergies, test results, medications, notes from every visit. But most of its value lies in everything built on top of that history. An electronic health record embeds order sets, which are pre-built bundles of tests and treatments a doctor can select for a common condition. It holds documentation templates that shape how nurses and physicians write up their work. It runs clinical decision support, the alerts that warn a prescriber about a dangerous drug interaction or a missed screening. It carries revenue cycle rules, the logic that turns clinical activity into accurate bills and insurance claims. And it is connected, through hundreds of interfaces built up over years, to laboratory systems, pharmacy systems, imaging, devices at the bedside and outside partners.

An interface, in this sense, is a pre-agreed pipe between two systems. When a lab machine finishes a blood test, an interface carries the result into the patient’s chart. When a doctor signs an order, another interface sends it to the pharmacy. Each pipe was configured, tested and tuned for that hospital. A large health system may have hundreds of them.

All of this means a health system’s investment in configuration, training and integration usually far exceeds what it paid in licenses. The license is the price of the house. The configuration is the decades of renovation, wiring and furnishing that make it home. When the ownership of that house changes, the owner’s plans for the foundations start to matter a great deal.

Why the switching cost keeps growing

The cost of leaving a health record rises every year a hospital stays on it. Each new order set, each tuned alert and each new interface adds to the work any replacement would have to redo. Clinicians build habits around the screens. Reports used by quality teams, finance and regulators are written against the record’s data model, the way its tables and fields are organized. Even the hospital’s downtime procedures, the paper forms and read-only copies used when the system is unavailable, are designed around it.

That accumulation gives the vendor pricing power that grows with time, whoever owns it. An acquirer buys that position along with the code. A buyer that pays a premium for a vendor with a loyal installed base is, in part, paying for the fact that customers are expensive to lose. Customers should read the purchase price that way too.

How the installed base differed

Cerner’s customers were not one group, and the deal touched them differently. Large academic medical centers ran heavily customized systems with research, teaching and specialty workflows layered on top. Their concern was whether years of local build would survive a modernization.

Community hospitals and smaller systems often ran a more standardized version, frequently hosted by Cerner in its own data centers. For them, hosting was already outsourced, so the question was where that hosting would go and on what terms. Some rural and critical access hospitals bought the record as a bundled service that included hosting, support and parts of the revenue cycle. They had the least internal staff to assess any change and the most to lose from a disruption.

Federal customers had their own rules. The VA and the Department of Defense buy under federal acquisition law, and any hosting environment for their data has to be authorized under federal security requirements before it can be used. Customers outside the United States, including hospitals in Canada and the United Kingdom, had data protection laws that could limit where patient data may be stored. One announcement started a different conversation in each of these places.

The product roadmap

A vendor’s roadmap is its plan for what the product will do next: new features, updates to meet new regulations, improvements to existing functions, and eventually the retirement of older pieces. Because a health system has built so much on the platform, that roadmap is a strategic dependency, and an ownership change puts it in question.

After the announcement, customers needed to know whether Oracle would evolve the existing platform, rebuild it on new technology, or both, and on what timeline. These are very different futures.

A rebuild might bring a modern platform, but it would also bring a migration. Migration in this context means moving the hospital’s data, configuration and workflows onto the new system, then retraining staff and revalidating workflows. Revalidating means checking, clinic by clinic and unit by unit, that the order sets still fire correctly, the alerts still appear when they should and the bills still go out right. For a hospital, that is clinical safety work rather than an IT chore, and it consumes the time of nurses, pharmacists and physicians who are already stretched.

Evolution, the gradual improvement of the existing platform, might be smoother but slower. Either path would shift where the vendor’s development effort went, possibly away from features a given customer was waiting for. A health system counting on a new revenue cycle capability next year, for example, might find the engineers who would have built it reassigned to the bigger modernization effort.

Early on, much of this was unknown, and that uncertainty was information in itself. Health systems approaching a major upgrade, a new module or a large integration project had reason to sequence carefully. Committing millions to a project built on a component whose future was unclear was a risk worth pausing to weigh.

A practical step was to list the roadmap items the health system depended on over the next three years and ask the vendor to confirm each in writing. Typical items were regulatory updates, interoperability features and revenue cycle functions. Interoperability here means the ability to exchange patient information with other hospitals, clinics, insurers and public health agencies, which is increasingly expected by regulators and patients alike. Where confirmation was not forthcoming, the health system knew where its plan carried risk.

Regulatory items no owner can skip

Some roadmap items are not optional for the vendor, and they make a useful anchor. Federal certification rules for health IT, run by the Office of the National Coordinator for Health Information Technology, set functions that certified records must support. Hospitals rely on certified technology to take part in Medicare programs that reward the use of electronic records. A vendor that falls behind on certification puts its customers’ payments at risk, so even a vendor in the middle of a rebuild has strong reasons to keep those updates on schedule.

The 21st Century Cures Act rules then in force made this concrete. They required certified developers to deliver new functions on fixed dates. One of the most relevant to an acquisition was electronic health information export. It lets a provider pull out all of the electronic health information the product stores, for one patient or for a whole patient population. Certified products had to offer it to users by December 31, 2023.

A hospital that tracked these dates could separate two kinds of roadmap risk. Regulatory items carried a deadline the new owner could not move. Discretionary items, the features a customer wanted but the law did not require, were the ones an acquirer could reprioritize. The second list was where written confirmation mattered most.

Reading signals from an acquirer

Customers also had public signals to read. Oracle’s announcement said it would modernize Cerner’s systems and run them on Oracle’s cloud. That told customers two things. Engineering effort would go toward the platform underneath the product. And the hosting arrangement would be part of the commercial relationship, not a side issue.

Statements made on earnings calls, at user conferences and in regulatory filings are the best evidence available before a deal closes. They are made to investors and are hard to walk back. A CIO who collected them in one place, with dates, could later hold the account team to them. Statements made only in sales meetings carry less weight unless they are written into the contract.

Testing the roadmap in writing

Suppose a regional health system has four hospitals and forty clinics on Cerner. In the month after the announcement, its chief information officer pulls together a one-page list of eleven roadmap items the organization’s plans depend on. They include required regulatory updates for the coming year, a patient-portal improvement the board has already promised the community, and a billing feature the finance team needs to reduce claim denials. She sends the list to the account team and asks for written confirmation of each item and its expected timing.

Eight come back confirmed. Three come back with polite language about “evaluating priorities.” The health system has not lost anything yet, but it now knows exactly which parts of its strategy are exposed. It delays one integration project, builds a workaround for another, and raises the third at its next renewal discussion. That is a modest amount of effort for a much clearer view of risk.

The case for carrying on as planned

There is a fair argument against this caution. Roadmaps slip under any owner, and an independent Cerner would also have had to reprioritize. An acquirer with Oracle’s balance sheet might invest more in the product, not less. A health system that froze every project for a year while waiting for clarity would lose a year of improvements its clinicians needed, and the cost of that delay falls on patients and staff.

That argument is right about freezing everything. It is weaker against targeted sequencing. The useful distinction is between projects that depend on a specific component staying as it is and projects that deliver value under any plausible future. Training, documentation cleanup, alert tuning and data quality work pay off whatever the vendor does. A large new integration built on a module the vendor might replace is a different bet. Health systems that sorted their project list along that line kept moving without staking much on unknowns.

The hosting model

Hosting is the question of where the software physically runs and who operates the machines underneath it. A health system might run its record in its own data center, pay a third party to run it, or have the vendor run it. Many Cerner customers already used vendor-hosted arrangements.

Oracle’s stated plan to run the platform on its own cloud meant hosting choices would likely narrow over time. For a health system, that had consequences beyond cost. Security responsibilities, disaster recovery design, data residency and integration with the health system’s other environments would all follow the vendor’s infrastructure decisions. Disaster recovery is the plan for getting systems back after a serious failure, such as a fire, a power loss or a cyberattack. Data residency is about where data is physically stored, which can matter for legal and contractual reasons.

What changed from the 2019 cloud story

The plan also reversed a story customers had already heard. In July 2019 Cerner had named Amazon Web Services its preferred cloud provider. Some health systems had read that as a signal about where their own cloud estate should go, and had built analytics or integration work on the same provider. The acquisition replaced that direction with Oracle’s cloud.

No customer had been promised a specific hosting outcome by that 2019 announcement, and nothing obliged an acquirer to honor a predecessor’s partnership strategy. But it shows why a vendor’s cloud direction should not drive a customer’s own architecture unless the contract does. Vendor strategies change with ownership. A customer’s data center contracts, network circuits and staff skills do not change as quickly.

When your systems live on different clouds

Health systems with a cloud strategy built around another provider faced a concrete issue. Many organizations have chosen one of the large public cloud providers as their main home for analytics, identity and productivity platforms. Those are the systems that analyze data, control who can log in to what, and run email and documents. If the health record moved to Oracle’s cloud, the organization’s largest and most critical application might end up on a different cloud from almost everything else.

That is manageable, but it carries a cost. It affects network design, the private connections that link the two environments. It affects latency for interfaces, meaning the small delays when data travels farther, which can matter for systems that expect instant answers. It affects the cost of moving data out for analytics, because cloud providers often charge “egress” fees when data leaves their environment. And it affects the tooling that operations teams use to monitor and recover systems, which may need to work across both environments.

Planned, this is an architecture decision. Discovered at migration time, it is an unbudgeted project. The difference between those two outcomes is mostly whether someone asked the question early.

What a hosting move involves

A move of a hosted record from one data center to another cloud is a project with clinical stakes, even if the software itself does not change. The interface engine, the hub that routes messages between the record and other systems, has to be pointed at new addresses. Firewall rules and allow-lists that name specific servers have to be rewritten. Certificates that secure the connections have to be reissued. Third-party applications that call the record directly have to be retested.

The cutover itself usually means a planned outage. During that window the hospital runs on downtime procedures, with read-only copies of recent records on designated workstations and paper for new orders. Afterward, staff enter the paper orders back into the system, and someone reconciles medication records to make sure nothing was missed. The work falls on nursing, pharmacy and the laboratory as much as on IT.

A health system planning for this would want to know several things well in advance. Among them were the expected date range, how many outages would be required and how long each would last, and who would pay for interface rework. It would also want to know how performance would be measured before and after. Response time inside the record is a clinical issue: a slow screen at a busy nursing station costs minutes that add up across a shift.

Who is responsible for security

The hosting shift also changed the shared-responsibility line for security. In any hosted arrangement, some security duties belong to the provider and some to the customer. On a self-hosted or third-party-hosted record, the health system controls much of the stack, the layers of hardware, operating systems, databases and applications that make the record work. On the vendor’s cloud, it relies on the vendor’s controls, logs and incident response.

Logs are the detailed records systems keep of who did what and when. After a suspected breach, they are the security team’s main evidence. Incident response is the process of detecting, containing and recovering from an attack or failure. If those rest with the vendor, the health system needs contractual assurance it can see what it needs to see, quickly.

Contracts and business associate agreements needed to reflect that. A business associate agreement is the contract, required under federal health privacy rules, that binds a vendor handling patient information to protect it. These agreements should say what logs the health system can access and how quickly it is told of incidents affecting its environment. They should also say how recovery time and recovery point objectives are tested and reported. The recovery time objective is how long the system can be down before it must be back. The recovery point objective is how much recent data the organization can afford to lose, measured in time. A promise of a four-hour recovery that has never been tested is a hope, not a control.

The evidence an auditor would ask for

The HIPAA Security Rule requires a covered entity to conduct an accurate and thorough risk analysis and to keep it current. A change in where the record runs is a change worth reflecting in that analysis. An auditor or an investigator from the HHS Office for Civil Rights, after an incident, would expect to see that the hospital had considered the new environment and documented its conclusions.

The practical evidence file is short but specific. It should hold the current business associate agreement and any amendment covering the new hosting. It should hold the vendor’s independent assurance reports, such as a SOC 2 Type II report, which an outside auditor writes after testing a provider’s controls over a period of months. It should hold the results of the most recent disaster recovery test, with the recovery times actually achieved. And it should hold a dated note of who in the hospital reviewed those materials and what follow-up they asked for.

Migrations also create temporary risk that permanent controls do not cover. Data is copied to staging servers, credentials are shared among migration teams, and old environments linger after cutover. A hospital should ask how long old copies will be kept, who can reach them, and when they will be destroyed. Those questions sound procedural. They became much more pointed after 2025, as the hindsight section below describes.

The commercial terms

Acquisitions change the negotiating dynamic. The acquirer has paid a premium and has targets to meet. Customers can expect changes to pricing, bundling and support structures over time. Bundling means packaging several products together, which can be convenient but can also make it harder to compare prices or leave one piece behind.

Yet the period right after an acquisition is often when the acquirer most wants to retain customers. A new owner wants to show that the customer base it paid for is staying put. That creates a window.

Health systems with renewals approaching could seek protections that would hold through a transition. These included price caps, support for current versions for a defined period, data access and export rights, and clear terms for any hosting migration, including who pays. Those with long remaining terms needed to read change-of-control and assignment clauses to see which protections carried over. A change-of-control clause sets out what happens to a contract when one party is bought; an assignment clause governs whether the contract can be transferred to another company. Organizations should review these terms with counsel and procurement specialists who know health IT contracts.

How the window works

The window has a shape. Before a deal closes, the target’s account teams generally keep operating as before, and the buyer cannot direct their commercial decisions. After closing, integration planning starts, and pricing policy tends to be set centrally. Customers who renewed in the first months after closing were often dealing with account teams whose incentives favored retention over price increases.

The bargaining power in that window has limits. A hospital that cannot credibly leave has less of it, and the vendor knows that. What it can do is trade time for terms. A longer renewal, which gives the vendor revenue certainty, can be exchanged for price caps on future years, defined support for the versions in use, and a commitment on hosting migration costs. Hospitals that took a short renewal to preserve flexibility kept their options but gave up some of that trade.

Terms that matter most in a hosting migration

If the vendor will move the record to new infrastructure during the term, the contract should say how. Useful provisions included the notice period before any migration, the customer’s right to approve the cutover window, and a commitment to performance at least equal to the current service. They also included credits if service levels slip, and allocation of the costs of interface rework, testing and staff time. Without these, a migration the customer did not choose can arrive on the vendor’s schedule and at the customer’s expense.

Service level agreements deserve their own reading. Many measure availability of the vendor’s infrastructure, not the response time a clinician experiences at a workstation. A record that is technically up but slow to open a chart can still meet its availability target. Health systems that negotiated measures closer to the clinical experience, and that required regular reporting against them, had a better basis for any later dispute.

What the federal contract showed

The VA’s experience is the most public example of contract terms being reset after problems. In May 2023, after pausing new deployments, the department renegotiated its contract. The remaining five-year option was converted into five one-year terms, and the new terms added performance metrics and larger credits if the vendor failed to meet them. That structure let the VA review progress each year rather than committing to the full period at once.

A private health system does not have the VA’s scale or its congressional oversight, and few will get the same terms. But the structure is instructive: shorter commitments tied to measured performance, with money at stake when targets are missed. A hospital negotiating after any vendor sale can ask for a smaller version of the same thing. Examples are service credits that actually bite and a renewal date that falls after a planned migration rather than before it.

Why data rights matter most

Data rights deserved the most attention. A record holds decades of clinical history, and the ability to extract it in complete, documented, usable form is a health system’s last line of protection against any vendor’s decisions. If the relationship ever sours, or the product heads in a direction that no longer fits, the data is what makes leaving possible.

Contract language on export format, completeness, cost and timeline is worth more than many price concessions. “Export format” asks whether the data comes out in a form another system can read. “Completeness” asks whether everything comes out, including notes, images and audit history, or only a summary. “Cost” and “timeline” ask what the vendor will charge and how long it will take.

The federal information blocking rules, in effect since 2021, strengthened expectations about access to electronic health information. They discourage practices that unreasonably interfere with the access, exchange or use of patient data. The certified export function due by the end of 2023 added a technical floor. But neither replaces clear contractual rights. The export function is defined by what the certified product stores, not by everything a hospital has built around it, and population-level export can involve the developer’s help. Regulation sets a floor; the contract has to do the rest.

How terms differ by organization

The negotiating priorities are not the same for everyone. A large multi-hospital system with its own data center and a strong integration team may care most about keeping the right to host the record itself or with a third party. A small community hospital on a bundled hosted service is unlikely to run the record itself, so its priorities are service levels, migration protections and a price cap. An academic medical center may focus on research data access and the right to keep its local build. A federal agency is bound by its acquisition rules and appropriations, and its bargaining power comes through contract structure and oversight rather than the threat of leaving.

Whether to switch

Some health systems used the moment to evaluate alternatives. That is a reasonable instinct, but it needs to be grounded in realism. Replacing a record is among the most expensive and disruptive projects a health system can undertake, measured in years and significant capital, and an ownership change alone rarely justifies it.

A structured review still had value. It asked how well the platform serves clinicians and patients, what it will cost over ten years under plausible scenarios, and what a move would take. The output strengthened the health system’s hand in negotiation whether or not it led to a switch. A vendor negotiates differently with a customer who has done the homework on leaving, even if that customer never intends to go.

A ten-year view matters because the costs of a health record are long-lived. Licenses, hosting, support, upgrades, staff time and the inevitable integration work all accumulate. Modeling a few plausible scenarios, such as stable pricing, a forced hosting migration, or a significant price increase at renewal, turns vague unease into numbers a board can discuss.

What a replacement actually involves

A replacement is several projects at once. The new record has to be selected, contracted and built, with order sets, templates and rules recreated for the hospital’s services. Every interface has to be rebuilt or retested. Staff need training before go-live and support afterward, often with extra people on the floor for weeks. Revenue typically dips while billing teams learn new workflows, so finance plans for a cash cushion.

The old record does not disappear on go-live day either. Clinical and billing history that is not converted has to stay readable for legal retention periods, often through an archive that holds legacy data in read-only form. Accounts receivable from before the switch still have to be worked to completion on the old system. For a while, the hospital pays for two platforms.

When a review points toward leaving

Some circumstances strengthen the case. A health system whose regional partners and referral networks mostly run a different record may gain from sharing a platform with them. A system already planning a large merger may need to consolidate onto one record anyway. A hospital whose current version is near the end of its supported life faces a major upgrade either way, which narrows the cost gap between staying and leaving.

Other circumstances weaken it. A system that has just finished a large optimization project, has satisfied clinicians and stable costs, and has secured good terms at renewal has little to gain from a disruptive move. The structured review should be able to say which of these situations the organization is in, with the evidence written down.

Five risks a vendor sale passes to the hospital

A change in who owns the record can change its price, where it is hosted and who controls its recovery. Each of those flows into a risk the board oversees. Naming an owner and a measure for each makes the oversight specific.

Patient safety. Any forced change to clinical workflows, whether from a rebuild or a migration, carries safety risk until it has been carefully validated. Boards should know when such changes are coming. The natural owner is the chief medical or nursing informatics officer. A useful measure is the number of validated workflows against the number affected by a planned change, reported before go-live.

Money. The record is typically among a health system’s largest technology costs, and its revenue cycle functions determine how reliably the organization gets paid. Changes in pricing, bundling or hosting flow straight into the operating budget. The CFO owns this one, with measures such as the ten-year cost under each scenario and claim denial rates before and after any system change.

Cyber and operational resilience. If the record goes down, care slows to paper and phone calls. Who controls recovery, and how well it is tested, should be reported to the board. The CISO and the head of infrastructure share ownership. The measures are the recovery times actually achieved in tests, the date of the last test, and the time it took the vendor to notify the hospital of incidents.

Regulators and reputation. Health systems remain accountable for protecting patient information and for giving patients access to it, regardless of where the software runs. A vendor’s failure becomes the hospital’s headline. Under HIPAA, a covered entity generally remains responsible for notifying affected patients of a breach, even when the breach happened at a business associate. The compliance officer and general counsel own this risk.

Staff. Clinicians already carry a heavy documentation burden. A poorly managed transition can deepen burnout and affect retention. The chief nursing officer and chief medical officer are the right owners, and measures such as time spent in the record after hours and turnover in affected units give early warning.

How the better-prepared systems responded

Organizations that handled this kind of transition well tended to do a few things consistently. They treated the announcement as the start of a planning cycle, not as news. They named an executive owner for the vendor relationship, rather than leaving it scattered across IT, finance and legal. They gathered their contracts in one place and read them, including the clauses nobody had looked at since signing. And they wrote down what they needed from the vendor, so that conversations with the account team had an agenda.

A cadence that kept going

The prepared systems also kept the work going after the first month. A quarterly review of the vendor relationship, with the roadmap list, the hosting timeline, open contract issues and recent service performance, kept the topic from fading once the news cycle moved on. They kept a short log of the vendor’s public statements with dates. And they took part in user groups, where customers compare notes and press the vendor collectively on shared concerns.

That cadence also helped with sequencing. A system that knew its renewal date, its likely hosting migration window and its own major projects could lay them on one timeline. It could then avoid scheduling a large go-live in the same quarter as a forced infrastructure move, and could aim its renewal for the period when it had the strongest hand.

The failures were just as consistent:

• Waiting for clarity. Assuming the new owner would explain everything in time, and losing the negotiating window that opens right after a deal.
• Pressing ahead on big projects regardless. Committing to a major upgrade or integration without asking whether the underlying component had a confirmed future.
• Treating hosting as a technical detail. Letting a move to the vendor’s cloud happen without modeling network, egress and monitoring costs, or without updating security and recovery terms.
• Trading data rights for discounts. Accepting a price concession while leaving export rights vague.
• Overreacting. Launching a full replacement on the strength of the ownership change alone, before doing the structured review.

Beyond health care

The pattern is not unique to hospitals. A credit union whose core processor is bought by a larger firm faces the same three questions about roadmap, hosting and terms. Its examiners also expect it to oversee that vendor under third-party risk management guidance, whoever owns it. A state agency whose case management platform changes hands faces them under procurement rules that may limit how quickly it can renegotiate. The specifics differ. The discipline of listing dependencies, reading the contract and using the window does not.

When a platform changes hands

If your organization depends on a major platform whose ownership has changed, or might, these questions are a useful starting point:

1. Which features or updates from this vendor do our plans for the next three years depend on, and has the vendor confirmed each one in writing?
2. Are any major projects about to start that assume a component will still be supported? Should we resequence them?
3. What logs can we see, how fast will we be told about an incident, and when were our recovery time and recovery point objectives last actually tested?
4. If we had to leave, could we get all of our data out, in what format, at what cost and over what timeline? Is that written down?
5. Who on the executive team owns this relationship, and how often does the board hear about it?

The questions need no technical background. They require someone to ask them early, and to keep asking until the answers are written down.

They also work as a standing review. Asked once a year about each platform the organization cannot easily replace, they show where the contract has drifted from the operational reality. Asked in the week an acquisition is announced, they set the agenda for everything that follows.

With hindsight

Oracle obtained its last antitrust clearance, from the European Commission, at the start of June 2022 and completed the acquisition on June 8, 2022. The business went on to operate as Oracle Health. The day after closing, Oracle’s chairman, Larry Ellison, set out plans at a public briefing for a national health records database drawing on hospitals’ records. Data would be held in anonymized form until patients gave consent. The plan showed how far the new owner’s ambitions reached beyond running Cerner’s existing product.

The most visible story of the years that followed was not in private hospitals but at the Department of Veterans Affairs. The VA’s rollout ran into serious problems at its early sites. In April 2023 the department paused new deployments for what it called a reset, a deliberate stop to fix problems before going further. For a system serving veterans across the country, that pause was a reminder that replacing a health record is as much about people, workflows and safety as about software.

The contract changed during the pause. In May 2023 the VA and Oracle Cerner agreed to convert the remaining five-year option into five one-year terms, with performance metrics and larger credits if targets were missed. Later renewals were also short. In mid-2024 the department signed a brief extension followed by an 11-month term. In August 2026 trade press reported that the VA was seeking to extend the agreement through 2031 with additional one-year ordering periods. The federal government, with all its buying power, chose to buy the system a year at a time.

The Department of Defense took a different path to the same platform. Its MHS GENESIS rollout continued through the ownership change and was completed in March 2024, when the joint VA and Defense facility in North Chicago, the Captain James A. Lovell Federal Health Care Center, went live. The contrast between the two departments shows that the same software, under the same owner, can produce very different results depending on governance, sequencing and local preparation.

VA deployments restarted on April 11, 2026, when four Michigan medical centers went live. Sites in Ohio, Kentucky and Indiana followed by August, with more scheduled. The VA plans to reach all of its medical centers by 2031. Measured from the 2018 contract, that is a very long road, and it illustrates how long the consequences of a single platform decision can run.

On the product, the rebuild question was answered. In October 2024 Oracle said it would build a new health record, separate from the Cerner Millennium platform. In August 2025 it introduced a new EHR built on Oracle Cloud Infrastructure, first for ambulatory providers in the United States, with acute care functions to follow. Meanwhile, existing customers began moving to Oracle’s cloud. In April 2025 Oracle announced that North York General in Ontario had become the first hospital in Canada to migrate its record to Oracle Cloud Infrastructure.

The hosting risks also became concrete. In early 2025 BleepingComputer and Bloomberg reported that an intruder had used compromised customer credentials to reach legacy Cerner data migration servers and had copied patient data. According to that reporting, Oracle Health told affected hospitals that it would not notify patients directly, leaving them to determine their own obligations under HIPAA. The incident was a working demonstration of two points made above: migration environments carry risk of their own, and the hospital keeps the regulatory duty even when the vendor holds the servers.

The cross-cloud worry eased somewhat for databases, if not for applications. In September 2024 Oracle announced Oracle Database@AWS and expanded similar services inside Microsoft Azure and Google Cloud. That made running Oracle databases next to other cloud workloads easier, though it did not by itself change where an Oracle Health record runs or what moving data between environments costs.

Regulation moved in the direction customers needed. Certified health IT products had to offer full electronic health information export by the end of 2023. From September 1, 2023, the HHS Office of Inspector General could impose civil money penalties of up to $1 million per violation for information blocking. That authority covers certified health IT developers, health information networks and exchanges. Those rules did not replace contract terms, but they gave hospitals a firmer floor in any dispute about getting their data out.

By this point in 2026, Oracle Health remains a major vendor with a large installed base. For its customers, the hosting, support and data terms they secured during the transition still set how much room they have to maneuver. Organizations that used the window after the announcement to pin down version support, export rights and hosting terms have more options today than those that let renewals pass without changes.

The same applies well beyond one vendor. Any platform your organization cannot easily replace, whether a health record, a core banking system or a case management system in government, can change owners. When it does, the most valuable protections are the ones already in the contract: the right to get your data out, clear terms on where the system runs, and a defined period of support. Those are best negotiated before you need them, and the period right after an ownership change is often the best time to ask.