What Happens to Your Data When Your Respiratory Software Vendor Gets Acquired - and Why It Matters
When a respiratory software vendor gets acquired, your lab's data can face real risks: access disruptions, format changes, policy shifts, and loss of continuity. Understanding what acquisition means for your data - and how to protect against it - is one of the most important decisions a respiratory or sleep lab can make when choosing a software platform.
TL;DR
Vendor acquisitions are common in health technology and can directly affect your data access, format, and long-term usability.
Key risks include data lock-in, forced migrations, system discontinuation, and changes to support and pricing.
Vendor-neutral, cloud-based platforms with transparent data policies offer significantly better protection.
Asking the right questions before signing a contract is your best defence.
Rezibase was itself built in response to vendor lock-in frustrations and is designed to keep labs in control of their own data.
About the Author: This article is written by the Rezibase team, respiratory scientists and health technology specialists with over 37 years of combined experience building and supporting clinical physiology software for hospitals and private labs across Australia, New Zealand, the UK, and Ireland.
Why Do Respiratory Software Vendors Get Acquired So Often?
Healthcare IT consolidation is accelerating. Larger technology companies routinely acquire smaller, specialised clinical software vendors to expand their product portfolios, enter new markets, or absorb a customer base quickly. Respiratory and sleep lab software is a niche segment, which makes it a frequent target.
The drivers behind acquisitions include:
Market expansion: Larger vendors want to enter the respiratory and sleep space without building from scratch.
IP acquisition: A smaller vendor may hold valuable algorithms, integrations, or established clinical relationships.
Customer consolidation: Buying the customer base is often faster and cheaper than competing for it.
Technology bundling: Acquirers often absorb niche tools into broader hospital information system (HIS) or EMR suites.
The problem is that your lab's priorities were never the acquiring company's primary motivation. Your data sits at the centre of this transaction - but it rarely drives the decision.
What Actually Happens to Your Data After an Acquisition?
Data outcomes after a vendor acquisition vary widely, but the most common scenarios are predictable and worth knowing in advance.
Scenario | What It Means for Your Lab |
|---|---|
Platform continuation | The product carries on, but ownership and support priorities may shift |
Platform sunset | The acquired product is discontinued; migration becomes mandatory |
Forced data migration | Your data must move to a new system, sometimes in formats you cannot control |
Pricing changes | New ownership may restructure fees or end existing agreements |
Support degradation | Key personnel familiar with your workflow leave post-acquisition |
Policy changes | Data access, storage location, and privacy terms can be rewritten |
The most immediate risk is not usually data loss. It is loss of control. When a new company takes over, they inherit your data but not your expectations about how it should be handled.
What Is Data Lock-In and Why Is It Particularly Risky for Respiratory Labs?
Data lock-in occurs when your clinical data is stored in a proprietary format that cannot be easily exported, accessed, or migrated without the vendor's cooperation or specific tools.
For respiratory and sleep labs, this is particularly dangerous because:
Historical test data has long clinical value. Spirometry trends, sleep study results, and longitudinal patient records are referenced over years or decades. Losing clean access to this data can disrupt patient care continuity.
Discrete data matters, not just PDFs. A respiratory lab needs raw values, flow-volume loops, and structured data points - not scanned documents. If your vendor only gives you a PDF on exit, you have lost the clinical utility of your records.
Accreditation depends on data integrity. Standards such as ISO 15189 and TSANZ/NATA requirements depend on audit trails, quality control records, and complete documentation. A disrupted migration can create gaps that affect compliance.
The critical question to ask any vendor is not just "can I export my data?" but "in what format, and can another system actually use it?"
What Questions Should You Ask a Vendor Before Signing a Contract?
Before committing to any respiratory software platform, these questions create a meaningful filter for evaluating long-term data safety:
On ownership and continuity:
Who owns the company, and has it been acquired or merged in the past five years?
What is the company's roadmap, and is it publicly documented?
What happens to my data if the product is discontinued?
On data access and portability:
In what formats can I export my data at any time?
Is discrete data (individual values, measurements) exportable, or only summary reports?
Do I need vendor assistance to run an export, or can I do it independently?
On contracts:
Is there a long-term lock-in contract, or is the agreement rolling?
What are the terms if I choose to leave?
Are there any data retrieval fees on exit?
On infrastructure:
Where is my data stored, and under which jurisdiction?
Who has access to my data, and under what conditions?
What is the disaster recovery and backup policy?
These are not aggressive questions. They are responsible ones. Any reputable vendor will answer them clearly.
How Should a Respiratory Lab Prepare for a Potential Vendor Change?
Even if you are satisfied with your current platform, proactive data hygiene is good clinical practice.
Steps to protect your lab's data independence:
Perform regular exports. Run and store structured data exports on a scheduled basis, not just when you plan to leave.
Document your data schema. Know what fields, values, and formats your data is stored in.
Test your exports. Exporting data is only useful if another system can actually import it. Verify this before you need it.
Review your contract annually. Particularly the data ownership and exit clauses.
Keep backups outside the vendor system. At a minimum, maintain a local or independently-stored archive of critical patient records.
If your current vendor makes any of these steps difficult, that difficulty is itself a signal worth taking seriously.
What Makes a Vendor Genuinely Low-Risk From a Data Perspective?
Low data risk comes from a combination of architecture, policy, and commercial structure. Look for:
Vendor-neutral, open data architecture: The system works with any device and stores data in accessible, standard formats.
No lock-in contracts: Month-to-month or short-term agreements signal confidence in product quality.
Transparent pricing: Hidden fees on exit are a common tool for trapping customers.
Established ownership with a clear future: A platform backed by a stable parent company with a documented track record.
Built-in migration support: A vendor who makes it easy to bring your data in should also make it easy to take it out.
Rezibase was built specifically in response to the frustrations that come from vendor lock-in in respiratory labs. Its Magic Import function allows data from any device manufacturer to be brought into the platform, and its no lock-in contract model reflects a commercial structure designed around customer confidence rather than captivity. Backed by Cardiobase with over 37 years of healthcare technology experience, Rezibase is not going anywhere.
Frequently Asked Questions
Is switching respiratory software platforms difficult?
It depends on your current vendor's data export capabilities. With the right support and a well-structured migration plan, the process can be straightforward. Rezibase provides guided onboarding to make transitions manageable.
Can I import historical patient data into a new system?
In most cases, yes, provided your data is in a structured, exportable format. The quality of the migration depends on how well your existing system allows data extraction.
What format should my respiratory data be in for a safe migration?
Structured, discrete data formats (not just PDFs) are essential. HL7, CSV with mapped fields, and DICOM are common standards worth confirming with both your current and future vendor.
Does cloud-based software reduce acquisition risk?
Cloud platforms can reduce some infrastructure risks, but cloud alone does not protect against data lock-in. The vendor's policies on data portability and contract terms matter more.
What happens to my accreditation records if I switch vendors?
Your accreditation records, including non-conformances, audits, and quality control history, need to migrate with your clinical data. Confirm that your new platform supports these record types before switching.
How do I know if my data is truly portable?
Ask your vendor for a full test export and attempt to open or import it into a neutral system. If the vendor resists or the output is unusable, portability is limited in practice.
What is the biggest mistake labs make when evaluating software vendors?
Focusing on features and price without reading the data ownership and exit clauses in the contract. These clauses determine what you actually control.
About Rezibase
Rezibase is Australia's most advanced cloud-based respiratory and sleep reporting platform, designed by respiratory scientists for respiratory scientists. Built to eliminate the frustrations of vendor lock-in, clunky interfaces, and systems that fail to keep pace with clinical standards, Rezibase is trusted by over 35 sites including the NHS in the UK and NSW Health in Australia. Backed by Cardiobase and 37 years of healthcare technology experience, Rezibase offers a transparent all-inclusive pricing model with no lock-in contracts, a 30-day free trial, and enterprise-grade deployment options tailored to the needs of public and private respiratory and sleep labs.
Ready to understand what your data freedom actually looks like in practice? Visit rezibase.com to explore the platform or speak with the team about your lab's specific needs.