Integration platform modernization for MedTech, built on what migration actually involves: replicating behaviour nobody documented, for customers who cannot pause.
Integration estates accumulate over a decade or more. The engineers who built them have moved on, the specifications were never updated, and the live traffic is the only reliable description of what each interface does. Migrating means reproducing that behaviour exactly, including the quirks, the workarounds and the defects that customers have since built their own processes around. Correcting a long-standing bug during migration is technically an improvement and operationally a breaking change.
Each interface moves to the new platform only when that customer agrees to it, schedules it with their integration team, tests it and accepts the cutover. That is a per-customer negotiation across an estate that may run to dozens or hundreds of connections, and a proportion of customers will not engage for a year or more. The result is an extended period operating two platforms, two support models and two sets of knowledge, which is the cost that makes modernization programmes overrun rather than the engineering itself.
Underneath that sits the harder problem: nobody can tell you precisely what the current interfaces do.
Specifications describe intent, not behaviour
The document says what was planned and the traffic shows what was built and then adjusted.
Customers depend on your
defects
Workarounds have been built around long-standing quirks, and fixing one is a breaking change to them.
Parallel running is the normal
state
Not a short overlap, and the double cost is where modernization business cases fail.
Clinical logic is hidden inside the middleware
Patient matching, order correlation and result mapping were frequently implemented in the integration layer rather than in the applications at either end.
The people who understand the estate are leaving
Institutional knowledge is the real asset being lost and it is rarely captured before it goes.
Clinical operations cannot
stop
A migration window measured in hours still means patient data in flight that has to be accounted for.
An undocumented interface is not necessarily a simple interface. It is an interface whose complexity has not yet been measured, and the ones nobody can explain are reliably the ones carrying the most accumulated local behaviour.
The reliable sequence is to move each interface to the new platform behaving identically, prove it with production traffic, cut over, and only then make improvements as deliberate changes with their own testing and customer communication. Combining migration with improvement doubles the variables and makes every discrepancy during parallel running ambiguous.
Step 1
Determine whether replacement is needed, since upgrading, refactoring or retiring interfaces may deliver more for less.
Step 2
Inventory what exists, including the interfaces nobody has touched and the ones nobody can explain.
Step 3
Record live traffic per interface, since that is the specification and the test set at the same time.
Step 4
Reproduce legacy behaviour, including defects, and compare both platforms message by message.
Step 5
Sequence by risk and customer willingness, starting with the interfaces that fail quietly if wrong.
Step 6
Plan the in-flight data at cutover, because messages mid-transit are patient data that has to be accounted for.
Step 7
Keep rollback available per interface, not just for the programme, since the first failure is usually local.
Step 8
Capture institutional knowledge during the work, since the people holding it are the real migration dependency.
Step 9
Separate improvements into a second phase with their own change control and customer notification.
Step 10
Decommission deliberately, because a legacy interface left running is both a cost and a data flow nobody owns.
Do not fix the bug during the migration. A long-standing defect discovered during analysis is tempting to correct while the code is open. The customer has adapted to it, their downstream process may depend on it, and a corrected output arriving without warning is indistinguishable from a new defect at their end. Reproduce the behaviour, complete the migration, then raise the correction as a change with notice and testing. Programmes that bundle fixes into cutovers spend the parallel running period unable to tell an improvement from a regression.
HL7, FHIR and EHR integration engineering are covered on our interoperability pages. These are the capabilities specific to replacing an estate that is already in production.
Discover
Estate Inventory and Assessment
What exists, what it connects, what it does and who depends on it, including the interfaces nobody can currently explain.
Traffic Capture and Behaviour Analysis
Live message recording across a representative period, which produces the real specification and the migration test set together.
Dependency and Impact Mapping
Which customers, systems and clinical workflows depend on each interface, since that determines sequencing and risk.
Knowledge Capture
Documenting what the remaining engineers know before they leave, which is the dependency most programmes discover late.
Reproduce and Prove
Behaviour-Equivalent Migration
Interfaces rebuilt to produce identical output on identical input, defects included, so parallel running has one variable.
Parallel Running and Comparison
Both platforms processing production traffic with automated message-by-message comparison rather than sampling.
Discrepancy Investigation
A disciplined path for every difference found, since each is either a migration defect or an undocumented legacy behaviour.
Cutover and Rollback Engineering
Per-interface transition with in-flight data handling and a rollback that works after the first message has moved.
Modernize and Retire
Target Platform Engineering
Cloud-native integration, API management, event-driven patterns or iPaaS, selected against your operating model rather than fashion.
API Enablement
Exposing modern interfaces alongside legacy messaging, covered on our FHIR and API enablement page.
Hybrid Operation
Running old and new together for the years the transition actually takes, with consistent monitoring across both.
Decommissioning
Retiring legacy interfaces, credentials and infrastructure, which is where the business case benefit actually lands.
Migration order should follow consequence rather than convenience. The third column is what a defect does if it reaches production, and the interfaces at the bottom are the ones to move last, with the most parallel running behind them.
| Interface type | What it carries | What a migration defect does |
|---|---|---|
| Administrative and billing | Operational and financial data | Causes a reconciliation problem somebody will notice and correct |
| Laboratory orders and results | Specimens, tests and results | Delays or misroutes a result, which a clinician usually catches |
| Diagnostic equipment output | Structured results and files | Produces a partial record that looks complete |
| Patient monitoring observations | Continuous device readings | Attributes readings wrongly or loses them without an error |
| ADT and patient context | Identity, encounters, transfers, merges | Corrupts every interface downstream of it, silently |
The same HL7 message before and after migration must mean the same thing clinically. Structural similarity is not sufficient if patient context, result meaning, order association or workflow behaviour has shifted underneath an output that still validates.
Connect medical devices, healthcare applications, and clinical systems to enable secure, reliable data exchange across the healthcare ecosystem. From EHR integration and FHIR APIs to HL7 interfaces, device-to-cloud connectivity, and integration platform modernization, help MedTech companies improve interoperability, streamline workflows, and support connected healthcare experiences.
Platform selection is usually run as a feature comparison, and the features are broadly equivalent. The third column is what actually differentiates the options in a MedTech estate, which is operational and contractual rather than technical.
| Question | Why it decides the outcome | What to examine |
|---|---|---|
| Who operates it | Managed service against your own team changes the cost model entirely | Your actual operations capacity, not your intended one |
| Where can it run | Some customers require on-premise or regional processing | Customer contracts and data residency obligations |
| How does it handle legacy | The estate is HL7 v2 for years regardless of the target | Native messaging support rather than an API-first assumption |
| What does migration cost | Per-interface effort multiplied across the estate is the real number | Effort for one representative interface, measured not estimated |
| Can you leave | Proprietary transformation logic becomes the next migration | Export formats and how much logic is portable |
| Does it survive your scale | Volume grows with the installed base, covered on our Fabric page | Cost at three times current volume rather than today |
Preserve the external contracts. A receiving system should not be forced into an unapproved change because your internal platform changed, and a modernization that pushes work onto customers converts an internal programme into their problem.
The existing interfaces operate inside a validated state, and replacing the platform underneath them is a change to that state rather than a new build. What qualification the new platform requires, what evidence the transition must produce and whether behaviour equivalence is an acceptable validation argument are determinations for your quality function, and they shape the programme plan rather than following it.
Validation
- Treated as a change to a validated state, with the qualification approach agreed before the first migration rather than after
- Behaviour equivalence evidence produced from parallel running, which is frequently the strongest argument available
- Engineering controls capable of supporting the frameworks that apply, which may include FDA regulation, IEC 62304, IEC 81001-5-1 and ISO 13485
- Applicability, classification and validation strategy determined by your quality and regulatory functions rather than by us
Data integrity
- In-flight messages accounted for at every cutover, since these are patient records in transit
- Message archives preserved across the transition and retrievable after the legacy platform is retired
- Reconciliation across the cutover boundary, so nothing is lost in the handover window
- Rollback tested with real data rather than assumed to work
Security
- Credentials reissued rather than copied, since a migration is the opportunity to retire what should not persist
- Legacy platform access revoked at decommissioning rather than left dormant
- Both platforms monitored during the hybrid period, as the old one is still carrying patient data
- Patient data handled to the obligations your counsel defines, including HIPAA where applicable
Operations
- Customer notified and scheduled for each cutover, since their team has to be present and their testing has to pass
- Support model covering both platforms for the full transition, which is longer than the plan assumes
- Decommissioning executed deliberately, because the benefit only lands when the old platform is actually off
- Knowledge captured from departing engineers before it leaves with them
Parallel running produces differences, and each one has exactly two explanations: the new implementation is wrong, or the old platform was doing something nobody knew about. Both are valuable findings and they need different responses. Teams without a disciplined investigation path accumulate unexplained differences, lose confidence in the comparison and start sampling, which is where migrations go wrong quietly.
Discrepancy triage with an owner
Every difference investigated and classified rather than added to a list that grows.
In-flight message handling
Defined per cutover, since patient data mid-transit has to be accounted for explicitly.
Per-interface rollback
Tested, with real data, because the first failure will be one interface rather than the programme.
Customer scheduling and acceptance
Which is the longest pole and sits entirely outside your control.
Hybrid period monitoring
One view across both platforms, since two monitoring systems means two partial pictures.
Decommissioning with evidence
Confirming nothing still depends on the legacy interface before it is switched off.
Modernization programmes are usually reported as interfaces migrated. The outcomes that matter are whether behaviour was preserved, whether customers noticed, and whether the legacy platform was ever decommissioned.
| Category | What we measure | Why it matters |
|---|---|---|
| Explain one production interface | Which systems it connects, who owns it, what transformations occur, which mappings are customer-specific, which identifiers are modified, which filters determine routing, how errors are handled, what acknowledgment behaviour is expected, which clinical workflows depend on it, whether it can be tested independently and whether it can be rolled back safely | If these cannot be answered the first activity is discovery and documentation, not migration |
| Behaviour equivalence | Message-level comparison results across parallel running | The validation evidence and the proof the migration worked |
| Customer-detected issues | Problems reported by customers against problems found in comparison | If customers find them first, the parallel running was insufficient |
| Migration cost per interface | Actual effort against the estimate, trended across the estate | Reveals whether the business case holds as the programme proceeds |
| Cutover scheduling lead time | From ready to migrate to customer actually scheduling | The real constraint, and usually the one nobody planned for |
| Decommissioning completion | Legacy interfaces and infrastructure actually retired | The benefit only lands here, and programmes routinely stop short |
We will inventory the estate, capture live traffic on a representative interface to establish what it actually does, measure one full migration end to end, review your parallel running and comparison approach, and build a sequencing plan ordered by consequence rather than convenience.
CaliberFocus modernizes MedTech integration estates by reproducing how existing interfaces behave before making any improvements. We capture live traffic as the real specification, compare legacy and replacement platforms message by message, and plan customer-by-customer cutovers with in-flight data handling and per-interface rollback. This helps MedTech companies preserve clinical workflows, manage extended parallel running and retire legacy platforms without introducing unplanned changes for customers.
- Live traffic capture to establish actual interface behaviour
- Behaviour-equivalent migration with message-by-message comparison
- Per-interface cutover, in-flight data reconciliation and tested rollback
- Customer-led migration sequencing with hybrid platform monitoring
- Evidence-backed decommissioning, knowledge capture and legacy retirement
Security & Compliance
