(Updated May 25, 2026) Saga IT

Mirth Connect Alternatives 2026: OIE, BridgeLink & More

OIE vs BridgeLink vs commercial Mirth 4.6+ vs Rhapsody, Qvera & more — compare Mirth Connect alternatives by cost, migration, and security risk.

Mirth ConnectHealthcare InteroperabilityOpen Integration Engine

In March 2025, NextGen Healthcare ended the open-source distribution of Mirth Connect. Version 4.6 and everything after it is commercial-only. The integration teams that built years of institutional knowledge around the open-source model are now choosing between three doors: stay put on 4.5.2, pay NextGen, or migrate.

This guide walks every viable path — fourteen alternatives in total, scored by cost, migration effort, and risk. We have helped dozens of organizations through this transition, from single-hospital deployments to vendor products that embed Mirth as their integration layer.

TL;DR: Pick Your Path

If you don’t have time to read the full 7,000 words, here’s the decision matrix:

If you…ChooseEffortCost
Need to buy time before decidingStay on Mirth Connect 4.5.2 (max 6 months)None$0 — but growing security risk
Value vendor support and don’t mind payingCommercial Mirth Connect 4.6+Low (version upgrade)$$$/year (NextGen subscription)
Want open source + community governanceOIE (Open Integration Engine)Low (install + import channels)$0 + optional vendor support
Already engaged with Innovar HealthcareBridgeLinkLow (install + import channels)$0 + optional Innovar Healthcare services
Building greenfield or open to a platform changeQvera, Rhapsody, Cloverleaf, Corepoint, Azure, MuleSoft, GCP Healthcare API, 1upHealth, or InterSystemsMedium-high$$ to $$$$

Below we walk through each option in depth — what it costs, how migration works, who it’s best for. Jump straight to our recommendation if you want the short answer.

Decision tree showing the five paths forward from Mirth Connect 4.5.2 — stay, buy commercial, migrate to OIE (recommended), migrate to BridgeLink, or migrate to a non-Mirth engine

What Changed: The Mirth Connect Licensing Shift

Eighteen-year Mirth Connect license history timeline — WebReach founds Mirth (2006), QSI acquisition (2013–2019), 4.5.2 last open-source release (Sep 2024), commercial-only split and community forks (Mar 2025), present-day two-track era (2026)

Mirth Connect was open source for over fifteen years. Created by WebReach Inc. in 2006 — which renamed itself Mirth Corporation in 2009, was acquired by Quality Systems Inc. in 2013, and rebranded as NextGen Healthcare in 2019 — the integration engine was available under the Mozilla Public License (MPL): MPL 1.1 for the early 1.x and 2.x releases, MPL 2.0 from version 3.0 onward. This meant anyone could download, deploy, modify, and redistribute Mirth Connect at no cost. The open-source model fueled massive adoption: by some estimates, Mirth Connect powered integrations at over 1,600 healthcare organizations worldwide.

In March 2025, NextGen Healthcare announced that Mirth Connect version 4.6 and all subsequent releases would be available only under a commercial license. Version 4.5.2, released in September 2024, became the final open-source release.

The key changes:

  • No more MPL 2.0 license for new versions. Mirth Connect 4.6+ requires a paid subscription from NextGen Healthcare.
  • No more community downloads from the NextGen website for the commercial version without a license agreement.
  • Existing open-source versions remain available. Version 4.5.2 and earlier are still licensed under MPL 2.0, and that license cannot be retroactively revoked.
  • Source code for 4.5.2 and earlier is still on GitHub. Community forks can (and did) emerge from the last open-source codebase.

NextGen’s rationale centered on sustainability. Maintaining a complex integration engine while giving it away for free was, in their view, no longer viable. They pointed to the substantial R&D investment required for FHIR support, cloud-native features, and security hardening.

Regardless of the reasoning, the practical impact is significant. Organizations that relied on the open-source model need to reassess their integration strategy.

Impact Assessment: Who Is Affected

The licensing change does not affect everyone equally. Understanding where you fall helps determine the urgency of your response.

Directly Affected

  • Hospitals and health systems running open-source Mirth Connect. If you downloaded Mirth from the community site and run it without a commercial license, you are on 4.5.2 or earlier. You will not receive security patches, bug fixes, or new features unless you take action.
  • Health IT vendors embedding Mirth Connect. If your product bundles Mirth Connect as its integration engine (common in lab information systems, radiology solutions, and health information exchanges), the licensing change potentially affects your product licensing and distribution rights for new versions.
  • Managed service providers offering Mirth Connect hosting or administration. Your service model may need to change if you were deploying open-source Mirth for clients.

Less Directly Affected

  • Organizations already on commercial Mirth Connect. If you already pay NextGen for Mirth Connect licensing and support, the practical change is minimal. Your pricing may change at renewal, but you were already in the commercial ecosystem.
  • Organizations using other integration engines. If you use Rhapsody, IGUANA, or a cloud-native integration platform, this change does not affect your current operations (though it may influence your competitive landscape).

The Security Concern

The most pressing issue for organizations staying on 4.5.2 is security. Mirth Connect has shipped critical vulnerabilities before. CVE-2023-43208 was a pre-authentication remote code execution flaw affecting versions before 4.4.1, severe enough that CISA added it to the Known Exploited Vulnerabilities catalog. If a similar bug surfaces in 4.5.2, NextGen has no obligation to patch the open-source line — your only options will be a community-backported fix from OIE or BridgeLink, or a costly upgrade.

Stacked risk-band chart showing how unpatched-window risk on Mirth 4.5.2 grows over time across three categories — CISA KEV / RCE exposure, Java dependency CVEs, and HIPAA Security Rule drift. Forks (OIE, BridgeLink) and commercial Mirth 4.6+ branch off at March 2025 to patch; staying on 4.5.2 is the only path where risk accumulates indefinitely.

Option 1: Stay on Mirth Connect 4.5.2

The cheapest short-term option is doing nothing. Your 4.5.2 deployment keeps running. Channels keep firing. Messages keep flowing. Nothing breaks on day one — and the trap is precisely that nothing breaks on day one.

What Still Works

  • All existing channels, connectors, and transformations continue to function.
  • The Mirth Connect Administrator console works as before.
  • All community plugins and extensions compatible with 4.5.2 remain functional.
  • MirthSync and other version control tooling continues to work.
  • Your existing database (PostgreSQL, MySQL, SQL Server, Oracle) is unaffected.

The Risks

  • No security patches. As noted above, any newly discovered vulnerabilities will not be patched by NextGen. You are responsible for monitoring CVEs and either applying community patches or implementing compensating controls.
  • No new features. FHIR R4 enhancements, new connector types, performance improvements, and UI updates in 4.6+ are off-limits.
  • Growing compatibility gaps. As trading partners, EHR vendors, and payers upgrade their systems, you may encounter compatibility issues with older protocol versions or TLS requirements.
  • Compliance risk. Auditors and compliance officers may flag unpatched software as a risk finding, particularly for HIPAA Security Rule requirements around patch management.
  • Talent challenges. As the community migrates to OIE or commercial Mirth, finding developers experienced with the 4.5.2 codebase specifically becomes harder.

When This Makes Sense

Staying on 4.5.2 is a reasonable short-term holding pattern while you evaluate your longer-term options. It makes sense if:

  • You need 3-6 months to budget and plan a migration.
  • Your Mirth instance handles low-risk, low-volume integrations.
  • You have strong network segmentation that limits the blast radius of a potential vulnerability.
  • You have in-house Java developers who can apply community security patches.

This is a bridge, not a destination. Six months is the outer edge of reasonable.

Option 2: Commercial Mirth Connect 4.6+

The most straightforward path forward is purchasing a commercial license from NextGen Healthcare. You stay on the same platform, gain access to new features, and receive vendor support.

What’s in Mirth Connect 4.6 and Beyond

Mirth Connect 4.6, released in early 2025 as the first commercial-only version, introduced the licensing change rather than a major feature shift. NextGen has positioned subsequent 4.x releases as the path for enhanced FHIR support, cloud-native deployment options, and security hardening.

If you’re evaluating commercial Mirth Connect for the first time, what you’re paying for is:

  • Continued release cadence. Regular updates on the 4.x line with bug fixes and incremental features.
  • Enhanced FHIR R4 capabilities. New connectors, transformations, and resource support beyond what shipped in 4.5.2.
  • Cloud deployment improvements. Better support for containerized deployments and cloud-managed services.
  • Vendor support contracts. Tiered SLAs for issue triage, escalation, and patching.
  • Compliance documentation. Audit-ready artifacts that support HIPAA, SOC 2, and HITRUST requirements.

NextGen does not publish a public roadmap, so specific feature timing and version cadence require conversations with their sales team. For organizations that need vendor commitment with documented SLAs, this is the path of least friction.

What You Get

  • Continued access to new releases. Mirth Connect 4.6 and beyond, with all new features and enhancements.
  • Security patches and bug fixes. Official patches from NextGen, delivered on a regular cadence.
  • Vendor support. Access to NextGen’s support team for troubleshooting, configuration guidance, and escalation paths.
  • New features. Enhanced FHIR capabilities, improved monitoring, cloud deployment options, and performance improvements.
  • Compliance assurance. A supported, patched product is easier to defend in audits.

Cost Considerations

NextGen does not publicly list Mirth Connect pricing. Based on what we have seen across client engagements, commercial licensing is typically structured as an annual subscription. Pricing varies based on:

  • Number of Mirth Connect instances (servers)
  • Message volume
  • Support tier (standard vs. premium)
  • Whether you are embedding Mirth in a product (OEM licensing)

For a single production instance with standard support, expect annual costs in the low-to-mid five figures. Multi-instance deployments or OEM licensing can be substantially higher. Contact NextGen directly for a quote.

Migration Effort

If you are already running Mirth Connect 4.5.2, upgrading to 4.6+ is a standard version upgrade. Channel compatibility is maintained. The migration effort is primarily:

  1. Obtaining and applying the commercial license.
  2. Performing the version upgrade (backup, install, verify).
  3. Testing channels in a staging environment before production cutover.

This is typically a low-risk, well-understood process that takes days, not weeks.

When This Makes Sense

Commercial Mirth Connect is a strong choice if:

  • Your organization has the budget for ongoing licensing costs.
  • You value vendor support and guaranteed SLAs for issue resolution.
  • You want the simplest possible migration path with minimal disruption.
  • You are already in the NextGen ecosystem for other products.

Option 3: Migrate to OIE (Open Integration Engine)

OIE, the Open Integration Engine, is a vendor-neutral community fork of Mirth Connect stewarded by a non-profit Steering Committee. It was created in direct response to the licensing change, forking from the last open-source Mirth Connect codebase.

What OIE Is

OIE is not a new product built from scratch. It is the continuation of the open-source Mirth Connect codebase under active community development. Think of it as what Mirth Connect would have become if it had remained open source.

Key facts about OIE:

  • License: Open source (continuing the MPL 2.0 tradition).
  • Codebase: Forked from Mirth Connect’s open-source repository. Full channel and plugin compatibility with Mirth Connect.
  • Maintained by: A non-profit Steering Committee and multi-vendor Maintainers group, with contributions from the broader community. A list of independent vendors (including Saga IT) offers commercial support and professional services.
  • Active development: Regular releases with bug fixes, security patches, and new features.
  • Community: Growing community of healthcare IT professionals, many of whom are former Mirth Connect community members.

Channel Compatibility

This is the question everyone asks first, and the answer is reassuring: OIE maintains full compatibility with existing Mirth Connect channels. Your channel XML exports from Mirth Connect import directly into OIE. Transformers, filters, scripts, and connector configurations all carry over. The database schema is compatible, so you can even point OIE at your existing Mirth Connect database (after proper backup and testing).

Migration Path

Migrating from Mirth Connect to OIE is straightforward:

  1. Back up your existing Mirth Connect instance (database and application directory).
  2. Export your channels from Mirth Connect (or use MirthSync to pull them into version control).
  3. Install OIE on your target server.
  4. Import your channels into OIE (or use MirthSync to push them).
  5. Test in a staging environment.
  6. Cut over production traffic.

For most organizations, this migration takes 1-3 days for a single instance, plus a testing period that depends on the number and complexity of your channels.

When This Makes Sense

OIE is a strong choice if:

  • You want to remain on an open-source platform with no licensing costs.
  • You have existing Mirth Connect expertise on your team.
  • You value community governance and transparency in development.
  • You want a smooth migration with minimal channel rework.
  • Your organization’s procurement process makes commercial licensing slow or difficult.

BridgeLink is a second open-source fork of Mirth Connect, maintained by Innovar Healthcare. Like OIE, it preserves the MPL 2.0 license and the Mirth Connect codebase. The practical difference between OIE and BridgeLink is which vendor stewards the project and which services ecosystem you want to draw on.

BridgeLink is a free, open-source fork of Mirth Connect — not a commercial product. Innovar Healthcare publicly launched BridgeLink in 2025, following NextGen’s commercial-license change. Development happens on public GitHub with an active Slack community and public issue tracker. For teams that want vendor-backed services on top of an open-source engine, Innovar Healthcare sells paid offerings separately.

Key facts about BridgeLink:

  • License: MPL 2.0 (open source), same as the original Mirth Connect and OIE.
  • Codebase: A direct fork of Mirth Connect, with ongoing Innovar Healthcare-led development.
  • Maintained by: Innovar Healthcare, Inc. (Montgomery, Alabama). BridgeLink is a trademark of Innovar Healthcare.
  • Release history: Innovar Healthcare publicly launched BridgeLink in 2025 and ships regular releases — see innovarhealthcare.com for the current version list.
  • Deployment options: Self-managed on-premises or in any cloud. Innovar Healthcare publishes an official BridgeLink Docker container and offers managed deployment services.

Channel Compatibility

BridgeLink maintains full compatibility with Mirth Connect channels. The core channel model (sources, destinations, transformers, filters) is preserved, and custom plugins built against the Mirth Connect Plugin API should continue to work.

Innovar Healthcare’s Commercial Services

BridgeLink itself is free, but Innovar Healthcare offers optional paid services around it for teams that want vendor backing:

  • BridgeLink Health Check — a paid review/assessment service for your BridgeLink deployment.
  • AWS Marketplace support activation — purchase support through your existing AWS contract and billing.
  • Certification program — Innovar Healthcare runs a BridgeLink certification track for engineers.
  • Add-on products — Innovar Healthcare offers BridgeLink add-ons such as BridgeLink WebAdmin and Enlighten (alerting and monitoring).
  • Integration consulting and managed services — data migrations, custom integration work, and managed deployment.

Cost Considerations

The BridgeLink engine has no licensing fee — it is free under MPL 2.0. Your platform costs are infrastructure (typically $200–$500/month for a single cloud instance). If you choose to purchase Innovar Healthcare’s services (Health Check, support, certification, custom work), those are priced per engagement.

OIE and BridgeLink are technically similar — both are MPL 2.0 forks of Mirth Connect with the same core feature set and channel compatibility. The reasons to choose one over the other come down to community preference and which vendor you want as a services partner. OIE is stewarded by a non-profit Steering Committee and has a broader multi-vendor community (including Saga IT); BridgeLink is stewarded by Innovar Healthcare and is the natural choice when you’ve already engaged Innovar Healthcare as a consulting partner. For a deeper head-to-head — features, licensing, support, and total cost — see our OIE vs BridgeLink vs Commercial Mirth Connect comparison.

When This Makes Sense

BridgeLink is a strong choice if:

  • You have already engaged Innovar Healthcare (or plan to) for integration consulting, data migrations, or managed services.
  • You want to buy support through AWS Marketplace rather than a direct contract.
  • You want Innovar Healthcare’s specific service offerings — BridgeLink Health Check, certification, or custom plugin development.

For most organizations evaluating an open-source Mirth fork for the first time, OIE’s broader community and multi-vendor ecosystem make it the more flexible default, but BridgeLink is equally viable technically.

Hub-and-spoke ecosystem map showing the Mirth Connect 4.5.2 source repository at the center splitting three ways — NextGen Healthcare on the right continuing as commercial Mirth 4.6+, OIE community fork on the upper-left under a non-profit Steering Committee, and BridgeLink vendor-led fork on the lower-left under Innovar Healthcare, with MirthSync spanning all three as shared CI/CD tooling

Option 5: Alternative Integration Engines

Five tilted cards covering the major commercial integration engine alternatives to Mirth Connect — Lyniate Rhapsody (cloud-native, JS+Lua, medium migration), Qvera QIE (visual+JavaScript, low-medium migration), Infor Cloverleaf (TCL, high migration), Corepoint Health (visual, medium-high migration), and InterSystems IRIS / Ensemble (ObjectScript, high migration), color-coded by migration effort

If you are open to moving away from the Mirth Connect ecosystem entirely, several other healthcare interface engines — integration engines from outside the Mirth ecosystem — deserve consideration. These are not Mirth-compatible (your channels will not migrate directly), so the effort is substantially higher, but they may be the right choice for greenfield projects or organizations ready for a platform change.

Qvera Interface Engine (QIE)

Qvera Interface Engine (QIE) is the most direct commercial alternative to Mirth Connect’s technology stack — Java, JavaScript, and SQL-based with a similar channel/transformer model. Many integration teams familiar with Mirth find the QIE migration path the smoothest of any non-Mirth platform, with channel concepts mapping cleanly between the two.

QIE includes a visual channel editor, version control integration, and a published Mirth-to-QIE migration guide. It is commercially licensed by Qvera with both on-premises and cloud deployment options.

Best for: Mirth Connect teams that want a non-Mirth commercial platform without retraining on a fundamentally different model.

Cloverleaf (by Infor)

Cloverleaf is a battle-tested enterprise integration engine widely deployed in large hospitals and health systems. It is heavily GUI-driven and excels at HL7 v2 message parsing, transformation, and routing at scale. Cloverleaf is commercially licensed by Infor with on-premises and managed cloud deployment options.

The Cloverleaf scripting model uses TCL (Tool Command Language) rather than JavaScript, which means existing Mirth scripts do not carry over without rework. Migration effort is substantial.

Best for: Large enterprises that need a proven commercial platform at scale across thousands of interfaces, and teams comfortable with TCL scripting.

Corepoint Integration Engine (by Rhapsody Health)

Corepoint Integration Engine, now part of the Rhapsody Health product family following Lyniate’s consolidation, is known for an intuitive graphical interface and strong customer support. Like Cloverleaf, it is heavily GUI-driven and supports HL7 v2, FHIR, and X12 with pre-built actions for common healthcare workflows.

Corepoint and Rhapsody are now sold together by Rhapsody Health, with Corepoint positioned for organizations that prioritize ease-of-use and Rhapsody positioned for enterprise scale.

Best for: Teams that prioritize a guided, GUI-driven editor over script-heavy customization and value premium customer support.

1upHealth

1upHealth is a cloud-native, FHIR-first health data platform — not a traditional integration engine. It is designed for organizations building modern healthcare applications that consume FHIR APIs rather than route HL7 v2 messages between systems. 1upHealth provides managed FHIR storage, patient consent, and data aggregation services.

If your integration needs are primarily “fetch FHIR data from EHRs and route it to apps” rather than “process HL7 v2 messages between legacy systems,” 1upHealth is in a different product category from Mirth Connect — but it solves an overlapping problem for modern use cases.

Best for: Digital-health startups and patient-facing app builders whose integration story is FHIR API-first, not HL7 v2 routing.

InterSystems Ensemble / HealthShare

InterSystems Ensemble (the integration platform) and HealthShare (the health-information-exchange application on top of it) form one of the most established healthcare integration ecosystems. Ensemble has been deployed in healthcare for over two decades, with deep roots in EHR vendors (notably Epic, which runs on InterSystems’ IRIS database).

Ensemble’s strength is its end-to-end vertical integration with InterSystems’ database, application framework, and analytics tools. The tradeoff is that Ensemble is a much larger commitment than swapping in an integration engine — it is typically a platform-level decision, not a Mirth migration target.

Best for: Organizations already committed to the InterSystems ecosystem (notably large Epic deployments), or those building large-scale HIE infrastructure where Ensemble + HealthShare is the established standard.

Rhapsody

Rhapsody is a mature healthcare integration engine with a strong market presence, particularly in larger health systems and government health organizations. It supports HL7 v2, FHIR, CDA, DICOM, X12, and other healthcare standards. Rhapsody is a commercial product with on-premises and cloud deployment options.

Best for: Large enterprises that need a battle-tested commercial integration platform with comprehensive healthcare standard support and vendor support.

IGUANA (by iNTERFACEWARE)

IGUANA is a healthcare integration engine known for its developer-friendly approach, with Lua scripting and a visual channel editor. It supports HL7 v2, FHIR, CDA, X12, and custom formats. IGUANA is commercially licensed.

Best for: Development teams that value a clean scripting environment and rapid channel development, and who are comfortable with Lua rather than JavaScript.

Microsoft Azure Integration Services

Azure Integration Services (Logic Apps, API Management, Service Bus, Event Grid) provides a cloud-native integration platform that can handle healthcare workloads. It is not a healthcare-specific integration engine, but with the FHIR service in Azure Health Data Services, it can address many healthcare integration scenarios.

Best for: Organizations heavily invested in the Microsoft Azure ecosystem who want a cloud-native approach and are willing to build healthcare-specific logic on top of general-purpose integration services.

MuleSoft (by Salesforce)

MuleSoft Anypoint Platform is an enterprise integration platform with a Healthcare Accelerator that includes pre-built connectors for HL7 v2, FHIR, and X12. It is a premium commercial product within the Salesforce ecosystem.

Best for: Organizations already using Salesforce Health Cloud who want a unified integration and CRM platform, and who have the budget for enterprise-tier pricing.

Google Cloud Healthcare API

Google Cloud’s Healthcare API provides managed services for healthcare data including FHIR, HL7 v2, and DICOM. It is a cloud-native, API-first approach to healthcare interoperability.

Best for: Organizations building cloud-native healthcare applications on Google Cloud who want managed FHIR and HL7 v2 services without operating their own integration engine.

Comparison Table

The following table summarizes the key differences across your Mirth-ecosystem options:

FeatureStay on 4.5.2Commercial Mirth 4.6+OIEBridgeLink
LicenseMPL 2.0 (open source)Commercial (proprietary)MPL 2.0 (open source)MPL 2.0 (open source)
CostFreeAnnual subscription ($$$)FreeFree (+ optional Innovar Healthcare services)
Channel CompatibilityN/A (same platform)FullFullFull
Security PatchesNone (community only)Yes (vendor-provided)Yes (community-driven)Yes (community-driven; Innovar Healthcare paid support available)
Active DevelopmentNoYesYesYes
New FeaturesNoYesYes (community roadmap)Yes (public GitHub roadmap; Innovar Healthcare-led + community contributions)
FHIR SupportLimited (4.5.2 level)EnhancedStandard Mirth FHIRStandard Mirth FHIR
HL7 v2 SupportFullFullFullFull
DICOM SupportFullFullFullFull
Cloud DeploymentSelf-managedSelf-managed + optionsSelf-managed (any cloud)Self-managed (any cloud); managed deployment via Innovar Healthcare available
Vendor SupportNoneNextGen supportCommunity; multi-vendor (including Saga IT)Community; Innovar Healthcare (incl. AWS Marketplace)
Monitoring/AnalyticsBasic (built-in dashboard)EnhancedBasic (built-in dashboard)Basic (built-in dashboard)
CI/CD Tooling (MirthSync)YesYesYesYes
Migration EffortNoneLow (version upgrade)Low (install + import)Low (install + import)
Long-term ViabilityPoorStrongStrong (community-dependent)Strong (vendor-dependent on Innovar Healthcare)

The table answers feature-by-feature questions. The next three visuals answer the bigger ones — what will this actually cost, where do the alternatives sit on cost vs. risk, and how close is the feature parity:

Stacked horizontal bar chart of 3-year total cost of ownership across six alternatives — OIE and BridgeLink ~$80–90k, commercial Mirth 4.6+ ~$210k, Qvera QIE ~$265k, Lyniate Rhapsody ~$490k, Infor Cloverleaf ~$650k, with each bar broken into license, migration, hosting, and internal engineering ops time

2D scatter matrix positioning every Mirth Connect alternative by 3-year cost of ownership (x-axis) and migration risk (y-axis). OIE and BridgeLink occupy the sweet spot (bottom-left, low-cost and low-risk). Cloverleaf and InterSystems IRIS sit in the danger zone (top-right, high-cost and high-risk). Mirth Connect 4.6+ sits mid-cost, mid-risk.

Seven-spoke radar chart comparing OIE, BridgeLink, and commercial Mirth 4.6+ across channel API parity, MirthSync CI/CD compatibility, JavaScript engine, REST + SOAP connectors, HL7 v2 + FHIR support, vendor support, and roadmap clarity. The three polygons overlap perfectly on the first five spokes (shared 4.5.2 codebase) and diverge on the last two — commercial Mirth scores higher on vendor support and roadmap clarity.

How MirthSync Helps With Every Option

Regardless of which path you choose, MirthSync is a critical tool in your migration and ongoing operations toolkit. MirthSync works with all Mirth-based platforms, including OIE, BridgeLink, and commercial Mirth Connect.

During Migration

MirthSync simplifies migration by enabling you to:

  • Export all channels from your current Mirth Connect instance into version-controlled files (XML).
  • Track every configuration change in Git, giving you a complete audit trail.
  • Push channels to a new platform (OIE, BridgeLink, or a new Mirth Connect instance) with a single command.
  • Compare configurations between your old and new environments to verify migration accuracy. To confirm a transformer produces identical output on both engines, you can parse each engine’s output and compare the segments field by field.

A typical migration workflow with MirthSync:

Terminal window
# Pull channels from your existing Mirth Connect instance
mirthsync -s https://old-mirth:8443/api -u admin -p admin pull
# Commit to Git for version control
git add -A && git commit -m "Export from Mirth Connect 4.5.2"
# Push channels to your new OIE (or BridgeLink) instance
mirthsync -s https://new-oie:8443/api -u admin -p admin push

Three-stage MirthSync migration flow — existing Mirth Connect 4.5.2 instance on the left exports channels via mirthsync pull into a Git repository (center), then pushes them into a new destination platform (OIE, BridgeLink, or commercial Mirth 4.6+) on the right via mirthsync push. Same CLI, same channel XML, and same Git workflow works identically across all three destinations.

Ongoing Operations

After migration, MirthSync provides:

  • Version control for all channel configurations, code groups, and global scripts.
  • CI/CD pipelines using GitHub Actions, GitLab CI, or any CI/CD platform to automate deployments.
  • Environment promotion from dev to staging to production with confidence.
  • Rollback capability through Git history if a deployment causes issues.

The MirthSync Plugin integrates directly into the Mirth/OIE Administrator console, and the MirthSync VS Code Extension provides IDE-based channel management for developers who prefer a code-first workflow.

Our Recommendation

After helping organizations through this transition over the past year, here is our general guidance:

For Most Organizations: OIE

We recommend OIE as the default choice for most healthcare organizations. It provides the closest experience to what Mirth Connect was before the licensing change: a capable, open-source integration engine with an active community. The migration effort is minimal, there are no licensing costs, and you gain access to ongoing security patches and community-driven features.

OIE is particularly well-suited for:

  • Small to mid-size hospitals and clinics.
  • Health IT vendors who embedded open-source Mirth Connect in their products.
  • Integration teams that value open-source flexibility and community support.
  • Organizations with limited budgets for integration platform licensing.

For Organizations That Want Vendor-Backed Support

If your organization values vendor-backed support with contractual SLAs, commercial Mirth Connect 4.6+ is the path of least resistance. You stay on the same platform, get a smooth upgrade path, and gain access to NextGen’s support organization and new features.

If you want to stay on open-source but still have a vendor to call, both BridgeLink and OIE work — both are MPL 2.0 forks, and either can be backed by paid vendor services. BridgeLink is led by Innovar Healthcare; see their site for the current catalog of paid services. OIE has a broader multi-vendor support ecosystem; many organizations get the vendor-backed experience they want by engaging an independent consultancy (including Saga IT) against an OIE deployment.

For Organizations That Don’t Want to Manage Infrastructure

If you want OIE or BridgeLink without standing up and operating the infrastructure yourself, our MDDS Console is a managed Mirth/OIE platform that handles the admin, monitoring, and peer-to-peer data exchange. Browser-based — no Java client, no VPN, no vendor lock-in (it’s still your channels, your data, your MPL 2.0 engine).

What We Advise Against

Do not stay on Mirth Connect 4.5.2 past six months. The security risk compounds. CVEs in Java dependencies alone — Log4j-class vulnerabilities in the underlying stack — accumulate quarterly, and you have no first-party patch path. If you are still on 4.5.2 today, start planning your migration this week.

Next Steps

Navigating the Mirth Connect licensing change does not have to be overwhelming. Here is how to move forward:

  1. Assess your current state. Inventory your Mirth Connect instances, channel count, message volume, and integration complexity.
  2. Choose your path. Use the comparison table and decision framework above to identify the best option for your organization.
  3. Plan your migration. Allocate time for staging environment setup, channel testing, and production cutover.
  4. Use MirthSync to automate. Pull your current configurations into version control before you start, and use MirthSync to push them to your new platform.

If you need help evaluating your options or executing a migration, our Mirth Connect consulting team has deep experience across all three platforms. We also offer specialized support for organizations moving to the Open Integration Engine.

Ready to start your migration? Contact us for a free assessment and we will help you chart the best path forward for your integration infrastructure.

Frequently Asked Questions

Is Mirth Connect still open source in 2026?

No. Mirth Connect 4.5.2 and earlier remain open source under the Mozilla Public License 2.0, but version 4.6 and later — released from 2025 onward — are commercial-only and require a paid NextGen Healthcare license. The open-source lineage continues in two MPL 2.0 community forks, Open Integration Engine (OIE) and BridgeLink.

Is Mirth Connect still free?

Mirth Connect 4.5.2, the last open-source release, stays free under the MPL 2.0 — and that license cannot be revoked. Newer versions (4.6+) require a commercial NextGen Healthcare license. For a free, actively maintained path, the open-source forks OIE and BridgeLink both continue under MPL 2.0.

When was the last open-source version of Mirth Connect?

Mirth Connect 4.5.2, released in September 2024, was the last version published under the open-source MPL 2.0 license. Version 4.6 (early 2025) moved to a commercial, closed-source model. The 4.5.2 source remains on GitHub and is the basis for the OIE and BridgeLink forks.

What is the best open-source alternative to Mirth Connect?

The two direct open-source forks are Open Integration Engine (OIE) and BridgeLink — both MPL 2.0 and fully channel-compatible with existing Mirth deployments. OIE is the flexible default for most teams (non-profit governance, multi-vendor community); BridgeLink is a strong fit if you are working with Innovar Healthcare. For a non-Mirth platform, commercial interface engines like Rhapsody, Corepoint, Iguana, and Cloverleaf are also options.

What is Mirth Connect used for?

Mirth Connect is a healthcare integration engine — also called an interface engine — used to translate and route messages between disparate systems such as EHRs, lab and radiology systems, pharmacies, and HIEs. It supports HL7 v2, FHIR, X12 EDI, and DICOM, with a visual channel editor for building, monitoring, and troubleshooting data flows.

How do I migrate off Mirth Connect?

Migrating to an open-source fork is low-effort: because OIE and BridgeLink share Mirth Connect's channel format and Java architecture, you export your channels and code templates and import them with little to no rework. Moving to a non-Mirth engine means rebuilding channels. Either way, Saga IT runs parallel-validation migrations with a documented rollback plan.

Need Help with Healthcare IT?

From HL7 and FHIR integration to cloud infrastructure — our team is ready to solve your toughest interoperability challenges.