Mirth Connect to Open Integration Engine Migration

Your interface engine moves clinical messages all day, every day. We migrate it to Open Integration Engine while the messages continue to flow.

The Situation

In March 2025, NextGen Healthcare moved Mirth Connect to a commercial-only license, effective with version 4.6. Version 4.5.2 was the last open-source release, and it no longer receives updates or security patches. Organizations that run open-source Mirth now have three options. They can stay on an unpatched 4.5.2. They can buy a commercial license. Or they can migrate to Open Integration Engine (OIE), the community fork of Mirth Connect 4.5.2. OIE keeps the same open-source license, and it is designed as a drop-in replacement.

All three options are legitimate. For some deployments, no change, or paid support, is the correct choice. This page is for organizations that selected OIE, or that want help with the decision. The migration must not disrupt the HL7 feeds that clinical operations depend on.

What the Migration Involves

"Drop-in replacement" describes the software, not the project. The work is in the details around it.

Channel & Config Export

We export channels, code templates, configuration maps, and global scripts from Mirth through the Administrator, the CLI, or the REST API. We put the exports in version control, so the migration is reviewable and repeatable.

Infrastructure Provisioning

We set up new OIE hosts correctly the first time. Each host gets a Java 17 runtime and a production-grade database instead of the embedded default. We add service management that fits your operations.

Compatibility Review

Connectors and JavaScript transformers transfer, because OIE runs the same engine. Commercial NextGen extensions, keystores, and custom JVM options need deliberate handling. We find those items before they cause an incident.

Testing Strategy

We replay real production messages against the new engine, channel by channel, and compare the outputs with the Mirth outputs. Equivalence is demonstrated, not assumed.

Parallel Running

The old and new engines process the same feeds side by side. We move interfaces in controlled batches and monitor both engines.

Cutover Planning

We sequence the cutover per interface, rehearse the rollback, and keep the downstream system owners informed. No dropped messages, and no surprises.

We Do This Work Now

This service page is not speculation. We run Mirth-to-OIE migrations in production healthcare environments today. We provision AWS infrastructure for the new engines. We export and transform channel configurations with tooling we built for this purpose. And we do the live integration engineering (transformer review, message replay, parallel validation) that moves a deployment across without incident.

The same team that runs our healthcare software practice does this work. Every person holds a HIPAA certification, and the team has production HL7 and FHIR integration experience beyond the interface engine. Mirth-to-OIE is the most common case of our broader legacy system modernization work.

Three Ways to Engage

Migration Assessment

We inventory your channels, extensions, and integration points. We flag the compatibility issues specific to your environment. You get a migration plan with effort estimates, whether or not you use us to execute it.

Full Migration

End-to-end execution: infrastructure, export and import, compatibility fixes, message-replay tests, parallel running, and a sequenced cutover. Your team is involved as much or as little as you want.

Post-Migration Support

Ongoing care for the new OIE environment: monitoring, channel changes, version upgrades, and new interface builds as your integration needs grow.

Want the technical details first?

We published a vendor-neutral, hands-on guide to the migration: export steps, compatibility problems, the test approach, and the pitfalls we found in real migrations. It is written for the engineer who does the work.

Read the Migration Guide

Getting Started

Moving off Mirth Connect?

Tell us about your deployment: channel count, extensions, and hosting. We give you a direct read on what the migration involves. The first call is with an engineer who has done this migration, not a salesperson.