Who Owns Your Clinical Trial Software When The Vendor Leaves?
By Lukasz Lazewski, CEO and cofounder, LLInformatics
Every sponsor can describe what their clinical trial software does. Far fewer can say what they actually own of it. The contract says license, the source code sits with the vendor, the documentation lives in the vendor's internal wiki, and the validation evidence is split across two companies' quality systems. In the daily running of a study, none of this matters. On the day the vendor is acquired, retires the product, or stops answering the phone, it is the only thing that matters.
I have spent much of my career on the delivery side of software for regulated industries, and the pattern repeats: organizations know their systems' features in great detail and their ownership position hardly at all. The same gap shows up for banks when a core vendor is acquired and for insurers when a policy platform is retired. This piece is about what it looks like in clinical research, where the sponsor carries the accountability long after the vendor is gone.
This Is The Market You Are Buying In
In March 2026, Thermo Fisher completed its $8.875 billion acquisition of Clario, whose endpoint data platform has supported roughly 70% of FDA and EMA novel drug approvals over the past decade. For customers, critical trial software is now under a new owner's control, with future platform decisions in its hands.
Or, take a market leader in excellent health. Veeva stopped functional releases for its Salesforce-based CRM in December 2023 and will end support in December 2029. Every customer, whatever their preference, is on a migration clock the vendor set.
Neither of these is a failure story, and that is the point. Acquisitions, product retirements, and strategy changes are the normal life cycle of a software company. That is true in every industry that runs on vendor software; clinical research is no exception. What is not normal is how rarely the people buying these systems have planned for that life cycle to intersect with a running trial.
The Accountability Stays With You
The regulatory ground has also firmed up recently. ICH E6(R3) came into effect in the EU in July 2025, was adopted as FDA guidance in September 2025, and is still rolling out, with its second annex taking effect in January 2027. It requires that the sponsor remains accountable even when trial activities are outsourced, and it expects computerized systems to be validated, with audit trails and data governance that hold up over time.
The vendor's obligations end when the contract ends. The sponsor’s run for the length of the study and the archive period after it. If the system changes hands twice and the original vendor no longer exists, an inspector will still ask the sponsor, not them, how the data was generated, changed, and protected. Regulation follows the sponsor, not the vendor.
What You Think You Own
When I look at how these relationships are actually papered, the gap usually sits in five places:
- The code. A license to use software is not ownership of it, and a "perpetual" license is only as durable as the company that granted it. For custom-built systems, the stakes are higher: Many sponsors assume that paying for development means owning the result, and many development contracts say otherwise.
- The documentation. Architecture decisions, configuration records, and operational runbooks often live in the vendor's internal tools. If it is not named as a deliverable, it is not yours.
- The validation evidence. Your validation package is tied to specific versions and configurations of the software. If the vendor holds the supporting validation and change records and you hold only the certificates, you may not be able to demonstrate or reconstruct the system’s validated state.
- The data. Not whether you own it, which you do, but whether you can get it out in a standard, complete form, with its audit trail, without the vendor's help.
- The know-how to operate the system. This is the least contractual and the most real. Somewhere, there must be a team that can take the system over or manage a transition to another provider. If the honest answer is that nobody can, that is a potential risk.
A word on escrow, since it is the standard reassurance offered at this point in the conversation: Escrow arrangements, where a third party holds the source code for release if the vendor fails, are only as good as what sits in the box. Code alone is not enough. Without the documentation and the instructions to build and run it, nobody can take what the escrow agent releases and stand the system back up. You end up with the legal right to software that no one can operate.
What A Gap Costs
One of the recent peer-reviewed estimates from Tufts CSDD puts a day of delay in a Phase 3 program at over $55,000 in direct costs, and the same research values a day of lost sales for a marketed product at roughly $800,000. That is the unit these risks should be priced in. A forced migration mid-study, a system nobody can patch, a data export that takes a quarter to negotiate — each convert into delay days with unpleasant arithmetic.
Scale matters here, too. Research sites already work across as many as 18 separate systems on a single study. Each one of those is a contract, and each contract is a separate answer to the ownership question.
What To Secure Before You Sign
The encouraging part is that almost all of this is cheap to fix at signing and painful to fix later.
Ask for the intellectual property and license terms to survive an acquisition of the vendor, in writing. Ask what happens at exit: a defined transition assistance obligation, with a duration and a price, agreed before it is ever needed. Ask for your data's exit route to be demonstrated, not just described: a real export, in an agreed, usable format, with the relevant audit-trail information preserved and accessible, run as part of acceptance testing.
On the technical side, make documentation a contractual deliverable that is updated with each release. Ask where the validation evidence lives, which versions it binds to, and what of it you hold in your own quality system. If there is an escrow clause, ask what exactly is deposited and whether an independent engineer could use it to restore or maintain the system, where technically feasible.
And organizationally, name the successor before you need one. It does not have to be an internal team, but it has to be a real answer.
None of this makes you a difficult customer. The vendors worth keeping will have heard every one of these questions before, and the way a vendor reacts to them is useful information itself.
The Question That Outlasts The Product
The software your trial runs on today will, at some point, be sold, retired, or replaced. That is not pessimism. It is the industry's track record, even for its healthiest companies. Knowing what your systems do is table stakes. Knowing what you own of them, and what you could operate without the people who built them, is what survives the vendor. The best time to find out is before the signature, while the answer can still be negotiated.
About The Author:
Lukasz Lazewski is a software engineer and entrepreneur with nearly two decades of experience advising technology companies across Europe and the United States. He began his career as a software engineer at AOL and Advertising.com before moving into CTO and senior leadership roles at companies including Viewlabs, AUPEO! (acquired by Panasonic), and Zenloop. In 2012, he co-founded LLInformatics, a software consultancy of 130+ senior specialists, where he now serves as CEO, helping enterprises modernize legacy systems and deliver compliance-ready software on time and on budget.