Healthcare application and interface modernization
We modernize legacy EHR, practice management and interface engine estates without a big-bang cutover. A FHIR facade or anti-corruption layer goes in front of the old system, new services take over one workflow at a time under the strangler pattern, HL7 v2 feeds move to FHIR R4 where it pays, data migrates with reconciliation reports, and the old component is retired only after a parallel run proves the new one matches. The same approach moves teams off Mirth Connect after the 4.6 commercial license change.
Plan your healthcare modernizationFor CTOs and engineering leaders at EHR, practice management and RCM vendors, and provider IT teams running legacy clinical systems. Updated September 26, 2026.
Modules, interfaces, data stores, reports and who depends on each
A FHIR API or anti-corruption layer in front of the legacy system
One workflow moves to new services; traffic is routed and compared
Parallel run, reconciliation reports, cutover and decommission
Illustrative workflow · scope tailored to your environment
The short answer
Healthcare legacy system modernization replaces or re-platforms aging clinical, billing and integration software while the organization keeps using it. Typical targets are home-grown or end-of-support EHR and practice management systems, VB6, PowerBuilder, Delphi or .NET Framework applications, on-premise databases, and interface engines carrying hundreds of HL7 v2 feeds. The safe method is incremental: put an API facade in front of the old system, move one workflow at a time to new services, migrate the data behind it with reconciliation, and retire each legacy piece only after a parallel run.
Read our FHIR facade guide to modernizing legacy healthcare systemsStart with the real problem
A legacy EHR or billing system holds years of clinical history, undocumented business rules in stored procedures, and interfaces that other hospitals, labs and payers depend on. A rewrite that switches over on one weekend has to get every rule, report and feed right at once, with no way back. Incremental modernization keeps the old system answering while new services take over workflow by workflow, and every step can be compared, reconciled and rolled back.
What we build
Most programs combine two or three of these. We sequence them so each release retires something.
Home-grown or end-of-support EHR and PM systems replaced module by module: scheduling, charting, orders, billing, reporting.
Custom EHR development servicesADT, ORM, ORU, SIU and DFT feeds kept where partners need them and exposed or converted to FHIR R4 resources where new consumers need APIs.
Our HL7 v2 to FHIR migration guideMirth Connect 4.6 and later require a commercial NextGen license. We move channels to Open Integration Engine, Interoply, Rhapsody or Iguana, or license Mirth deliberately.
Mirth Connect integration servicesDemographics, problems, medications, allergies, results, notes, documents, claims and balances moved with mapping specifications and reconciliation.
Healthcare data migrationOn-premise servers and databases moved to HIPAA eligible services on AWS, Azure or Google Cloud under a BAA, then containerized and automated.
Healthcare cloud architecture guideVB6, PowerBuilder, Delphi, classic ASP and .NET Framework applications moved to supported stacks, with tests written around current behavior first.
Healthcare quality engineeringYour starting point
The EHR or PM system runs on an unsupported stack, only a few people understand it and every customer asks for APIs. We add a facade, then replace modules in business-priority order.
Mirth Connect licensing changed with 4.6, or your engine is out of support. We inventory every channel, pick the target and migrate with side-by-side comparison.
Payers, patients or partner apps need FHIR R4 while the core system speaks HL7 v2. We add a FHIR facade now and move the source of truth later, if at all.
The Engineering Engagement
Workstreams are selected around your priorities. Each comes with an output your team can inspect, test and own.
Inventory modules, databases, stored procedures, reports, batch jobs, interfaces and users. Rank each by business value, risk and coupling to decide what moves first.
Before changing anything, capture what the system does today: API responses, report outputs, HL7 messages and claim files for a representative set of scenarios.
Put a FHIR R4 API or domain API in front of the legacy system so new consumers never bind to the old schema, and new services can take over behind it.
Move one workflow at a time to new services, route traffic through the facade, compare outputs against the legacy path and switch when they match.
Map v2 segments to FHIR resources using the HL7 v2-to-FHIR guidance, migrate engine channels, and replay recorded production traffic through old and new paths.
Use change data capture to keep old and new stores in step during coexistence, then run trial loads and reconciliation until counts and sampled fields match.
Move workloads to HIPAA eligible cloud services under a BAA with infrastructure as code, encryption, centralized logging without PHI leakage, and tested backups.
Retire legacy components once parallel runs pass, keep a read-only archive for retention obligations and release-of-information requests, and shut down licenses and servers.
Compare your options
The right approach depends on how much of the legacy system is still valuable and how much risk the business can take at once.
| Incremental strangler | Big-bang rewrite | Lift and shift to cloud | Replace with a commercial product | |
|---|---|---|---|---|
| Best for | Core systems that must keep running while they change | Small systems with few users and interfaces | Hardware or data center exits with little code change | Standard workflows a vendor product already covers |
| Clinical disruption | Low: one workflow at a time with rollback | High: one cutover for everything | Low, but nothing improves in the app | Medium to high: retraining and data conversion |
| Interfaces | Kept working through the facade | All rebuilt and retested at once | Unchanged | Rebuilt to the vendor's interfaces |
| Data migration | Per slice, with CDC during coexistence | All at once | Database moves as is | Full conversion to the vendor model |
| Time to first value | The first slice | The final cutover | The move itself | Go-live |
| Main risk | Coexistence complexity | Missed rules and no way back | Carrying technical debt to the cloud | Workflow fit and vendor lock-in |
Many programs combine them: lift and shift first to exit a data center, then strangle the application from the cloud.
Expertise is in the decisions
Pick a workflow with clear boundaries, real users and visible value, such as scheduling or results inbox. The first slice builds the facade, routing and reconciliation tooling that every later slice reuses.
HL7 v2 remains the working standard for most hospital ADT, lab and scheduling feeds. Convert to FHIR where new consumers need APIs or US Core, and keep v2 on partner-facing edges until they move.
Staying on Mirth 4.6 means a commercial license; staying on 4.5.2 means no patches. Compare license, support, staffing and migration effort for Open Integration Engine, Interoply, Rhapsody and Iguana before choosing.
For each patient, encounter, order and claim entity, decide which system owns writes in each phase. Dual writes without a declared owner are the most common cause of drift.
Engine, EHR and cloud licenses and exit terms are between you and the vendor. We document what each option requires and prepare the technical side of the exit.
How long legacy records are kept and in what form follows your records policy and state rules. We build the archive and access path to meet it.
Timeline
Programs are planned as a series of releases, each of which retires something. Estate size and interface count set the total.
Typically 3 to 5 weeks for estate mapping, characterization tests and the target architecture.
Typically 2 to 4 months including the facade, routing, reconciliation tooling and one workflow.
Repeating 6 to 10 week waves, each moving a workflow, a group of interfaces or a data domain.
Final parallel run, archive and shutdown once all dependents have moved.
Delivered work
Client names are withheld; each is a real engagement. Our open-source healthcare engineering is public on GitHub.
Took over a shipped app that had passed through several vendors, closed security gaps first and modernized it while releasing to the app stores without disrupting existing users.
Scheduling, charts, care plans and billing on a FHIR server with no private database, so the record can be exported and moved without conversion.
Deployed and integrated a specialist openEHR clinical data repository with identity, template validation, audit and observability for a research university.
Hardened an inherited clearinghouse integration for a behavioral health EHR: claim validation, acknowledgement handling and remittance reconciliation.
Our integration platform for HL7 v2, FHIR and X12 workloads, and a migration target for teams leaving legacy interface engines.
A reference FHIR R4 record and SMART on FHIR API that passed 47 of 47 ONC (g)(10) SMART App Launch standalone patient tests in Inferno, used as a facade and target pattern.
From discussion to delivery
Estate map, dependency graph, characterization tests and a ranked modernization backlog.
Facade, routing, CDC and reconciliation tooling, proven on the first workflow.
Workflows, interfaces and data domains moved wave by wave with parallel runs and rollback.
Legacy components decommissioned, records archived, and the new platform supported under SLAs.
We agree the scope, dependencies, acceptance criteria and commercial model before implementation. Your existing team can stay involved throughout.
Find the right starting point ↗Before you commit
The strangler pattern replaces a legacy system gradually. A facade routes each request either to the old system or to a new service; workflows move to new services one at a time until the old system handles nothing and can be retired. In healthcare it keeps clinicians working and every step reversible.
Cost depends on the number of modules and interfaces, data volume and quality, the number of parallel-run cycles clinical and billing teams need, and license and hosting changes. We price the assessment as a fixed scope, then each migration wave separately so spend tracks retired legacy.
We put a facade in front of the EHR, move one module at a time, keep both systems in sync with change data capture during coexistence, compare outputs in a parallel run and cut over a module only when it matches, with a rollback switch ready.
Not wholesale. HL7 v2 still carries most hospital ADT, order, result and scheduling traffic. Add FHIR R4 where new consumers need APIs, US Core or certification, often through a FHIR facade over existing v2 feeds, and move partner-facing v2 only when partners are ready.
Versions 4.5.2 and earlier remain open source but receive no patches. From 4.6, NextGen ships Mirth Connect under a commercial license. Teams either license 4.6, move to the community fork Open Integration Engine, or migrate to another engine such as Interoply, Rhapsody or Iguana.
We export and inventory every channel with its connectors, filters, transformers and code templates, map dependencies, convert channels to the target engine, then replay recorded production messages through old and new channels and compare outputs before switching each wave.
Mapping specifications per entity, trial loads into a staging environment, record-count and field-level reconciliation reports, clinician spot checks on sampled charts and a rehearsed cutover. Data that cannot map cleanly is flagged for review rather than dropped.
Yes. We build a landing zone on HIPAA eligible AWS, Azure or Google Cloud services under your BAA with the provider, move databases and applications with infrastructure as code, and prove backups with timed restores before cutover.
The assessment takes 3 to 5 weeks and the facade with the first workflow typically 2 to 4 months. After that, migration waves of 6 to 10 weeks each retire a module, a group of interfaces or a data domain until the legacy system is gone.
Yes, and it helps. Your engineers know the undocumented rules. We pair on characterization tests and each slice, and hand over ADRs, runbooks and the reconciliation tooling.
Records that were not migrated go to a read-only archive with search and export, so you can meet retention obligations and release-of-information requests without keeping the legacy system running.
A useful first conversation
Tell us what exists today, who uses it and where the workflow breaks. We’ll discuss the scope, access dependencies and the next practical step.
A product overview and a de-identified workflow are enough to start. No patient records or credentials are needed.
These are independent reference sources, not endorsements. Applicability, platform access and current requirements are confirmed for your project.
