Key takeaways
- Legacy systems in MedTech carry years of validation evidence and audit history. Replacing them means rebuilding that evidence from scratch.
- Big-bang replacement projects fail far more often in regulated companies, because re-validation and retraining multiply every delay.
- A bridge layer can move data between old and new systems without touching the validated core.
- Replacement is sometimes the right call. There are clear criteria for when, and they rarely apply to a system that still does its job.
Somewhere in your building there is a system everyone complains about. It runs on a server nobody wants to touch, the vendor stopped issuing updates years ago, and the one person who understands its quirks is thinking about retirement. A consultancy has probably already told you the answer is to replace it, along with everything connected to it.
Before you sign that proposal, it helps to understand why so many replacement programmes in MedTech run over budget, stall halfway, or quietly get cancelled, and why connecting old systems often achieves the outcome you actually want at a fraction of the risk.
Why MedTech runs on old systems
Outside regulated industries, old software is just old. In a medical device company, an ageing system is usually something else: a validated part of your quality infrastructure with a decade of audit history behind it.
That PLM system holding your design files passed inspections. Your ERP feeds data into records that notified bodies have already reviewed. The clunky database tracking complaints has proven, year after year, that it does what your procedures say it does. Auditors trust it because you can show them how it has behaved over time.
Keeping systems like that in service is a rational decision, and treating their age as an embarrassment misses what they represent. The problem worth solving is usually different: the system can't talk to anything built in the last ten years.
What actually goes wrong with rip-and-replace
Replacement projects fail in regulated companies for reasons that have little to do with software quality.
Re-validation swallows the budget. Every replaced system must be validated again: requirements, risk assessments, IQ/OQ/PQ, updated procedures, retrained staff. In an unregulated business, switching an ERP is painful. In a device company, each of those steps produces documentation a notified body may ask to see. Teams routinely discover that validation and documentation cost more than the software licences.
Parallel running drains the team. For months, people maintain records in two systems at once while doing their normal jobs. Quality teams that were already stretched now do everything twice. This is exactly when complaint backlogs grow and CAPA deadlines slip, and an auditor won't accept "we were migrating" as an explanation.
History doesn't migrate cleanly. Years of records carry structures, naming conventions and workarounds that don't map neatly onto a new platform. Companies either spend heavily cleaning data or keep the old system alive read-only for years, which means they never really left.
Change fatigue is real. After a rollout of this size, an organisation has little appetite for anything else. Improvements that mattered get postponed for years because everyone is exhausted.
None of this means modern platforms are bad. It means the wholesale swap is the most expensive possible route to them.
When replacement genuinely makes sense
Integration is not always the answer, and a partner who claims otherwise is selling you something. Replacement deserves serious consideration when:
the vendor has ended support and the system poses a security risk you cannot mitigate the system fails at its core job, producing errors your team constantly corrects it cannot hold data you're now legally required to keep, in any workable form the licence and maintenance costs of keeping it exceed the full, honest cost of replacing it, re-validation included
Notice what's missing from that list: "it looks dated", "it has no API" and "nobody likes it". Those are integration problems, and integration problems have integration solutions.
The bridge pattern, in plain terms
Think of a legacy system as a building with no doors on one side. You could demolish it and rebuild. Or you could add a door.
A bridge layer is that door: a piece of software that sits alongside your existing systems, reads from them, writes to them where appropriate, and passes data to modern tools in a form they understand. The validated core stays exactly as it is, running the process it was validated to run. What changes is that its data now flows to the people and systems that need it, without anyone re-typing it.
In practice this means custom connectors built for how your systems actually store information, not how a vendor brochure assumes they do. Older platforms often lack proper interfaces, so the connector may work at the database level or through exports the system already produces. Done carefully, the legacy system doesn't even know it's being read, which matters enormously for validation, a topic we cover in detail in how to integrate without breaking validation.
The same pattern handles gradual migration. If you do eventually retire a system, a bridge lets you move one workflow at a time instead of betting everything on a single cutover weekend.
What "zero downtime" means for a quality operation
For a manufacturing or quality team, downtime has a specific cost: batches waiting on record approval, complaints logged on paper "temporarily", audit trails with gaps that need explaining later.
An integration built around your operating rhythm avoids creating those moments. Connections are added and tested alongside live systems, switched on for one data flow at a time, and designed so that if the bridge itself ever fails, your source systems keep working as they always did. The bridge carries copies and messages; it never becomes something your validated process depends on to function.
That last point is worth pressing any integration partner on. A bridge that becomes a single point of failure has recreated the problem it was meant to solve.
Where to start
Not with software. Start with a map: which systems hold which data, where information is re-typed by hand, and which of those handoffs creates real risk, whether audit findings, delayed submissions or engineers doing administration. The handful of connections that would relieve the most pressure usually becomes obvious, and it's almost never "all of them at once". Our guide to scoping an integration project walks through what that mapping exercise produces and what it costs.
ULAM LABS acts as a specialised integration partner for MedTech companies. We build data and workflow layers on top of existing validated platforms, so you get traceability, reporting and automation without the risk of replacing what already works. We've spent more than ten years connecting systems in regulated industries, and we map every system and data flow before we touch anything. If you're weighing replacement against integration, book a discovery call and we'll tell you honestly which one fits your situation, usually within a week. You can read more about how we approach this work on our integrations page.
