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. It draws on a decade of Mirth Connect work, 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 guide, here’s the decision matrix:
| If you… | Choose | Effort | Cost |
|---|---|---|---|
| Need to buy time before deciding | Stay on Mirth Connect 4.5.2 (short-term only) | None | $0, but carries unpatched CVEs |
| Value vendor support and don’t mind paying | Commercial Mirth Connect 4.6+ | Low (version upgrade) | $$$/year (NextGen subscription) |
| Want open source + community governance | OIE (Open Integration Engine) | Low (install + import channels) | $0 + optional vendor support |
| Want a specific vendor stewarding your fork | BridgeLink or another community fork | Low (install + import channels) | $0 + optional vendor services |
| Building greenfield or open to a platform change | Qvera, Rhapsody, Cloverleaf, Corepoint, Azure, MuleSoft, GCP Healthcare API, 1upHealth, or InterSystems | Medium-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.
One update since this guide first ran: OpenShare, our browser console and data-exchange layer for Mirth-family engines, is now live in open beta. It is not a fifteenth alternative; it runs on top of whichever fork you pick. Details below.
What Changed: The Mirth Connect Licensing Shift
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 2018), 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 across hospitals, labs, health information exchanges, and the health IT vendors who embedded it.
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. On the commercial line, 4.7.2 is the release that fixed the September 2026 CVEs; the open-source OIE line is at 4.6.0.
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. NextGen has no obligation to patch the open-source line, and in September 2026 that stopped being hypothetical: the Mirth Connect vulnerabilities disclosed in September 2026 reach 4.5.2, and NextGen’s fix is commercial-only. The open-source routes to a fix are a patched fork build, such as our OpenShare Engine 4.6.0-7, or the OIE patch release now in progress.
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, and since the September 2026 advisory it is a shorter one: 4.5.2 now carries disclosed vulnerabilities that NextGen will not fix. If you do not have in-house Java developers to backport community patches during this window, Saga IT’s Mirth Connect services cover interim security patching as well as the eventual migration.
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.
- FHIR and cloud work on NextGen’s roadmap. NextGen positions later 4.x releases around FHIR support and cloud-native deployment; confirm with them what has actually shipped.
- Vendor support contracts. Tiered SLAs for issue triage, escalation, and patching.
- A vendor patch path. Security fixes come from NextGen: 4.7.2, for example, fixed the September 2026 CVEs.
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, such as 4.7.2 for the September 2026 CVEs.
- Vendor support. Access to NextGen’s support team for troubleshooting, configuration guidance, and escalation paths.
- New features. Whatever NextGen ships on the 4.x line; it does not publish a roadmap, so ask before you count on one.
- 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:
- Obtaining and applying the commercial license.
- Performing the version upgrade (backup, install, verify).
- 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 Eclipse OIE
OIE, the Open Integration Engine, renamed Eclipse Open Integration Engine when it entered incubation on 2026-09-07, is a vendor-neutral community fork of Mirth Connect, hosted at the Eclipse Foundation and built by a multi-vendor group of committers. 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 compatibility with Mirth Connect; plugins built for open-source Mirth carry over, while NextGen’s commercial extensions are licensed products and do not.
- Maintained by: The Eclipse Foundation, under the Eclipse Technology PMC, with a multi-vendor group of committers and contributions from the broader community. A list of independent vendors (including Saga IT) offers commercial support and professional services.
- Active development: Releases and fixes from a multi-vendor committer group. For the September 2026 CVEs, an OIE patch release is in progress; a patched OIE-based build is available now.
- Community: Growing community of healthcare IT professionals, many of whom are former Mirth Connect community members.
Download OIE: It is the free, open-source continuation of Mirth Connect. Download the installer, Docker image, or Git plugin and import your existing channels. The downloads page notes which build carries the September 2026 security fixes.
Modernize the admin while you’re at it. OIE ships with the classic desktop Administrator client. If you would rather run and monitor it from the browser, our OpenShare platform (now in open beta) installs as a single plugin on the engine and adds a web console, real-time fleet monitoring, and outbound-only remote access with no open inbound ports. Your channels and your engine stay exactly where they are.
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:
- Back up your existing Mirth Connect instance (database and application directory).
- Export your channels from Mirth Connect (or use MirthSync to pull them into version control).
- Install OIE on your target server.
- Import your channels into OIE (or use MirthSync to push them).
- Test in a staging environment.
- 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.
Option 4: BridgeLink and Other Forks
OIE is not the only fork of the last open-source codebase. The best known of the others is BridgeLink, an MPL 2.0 fork maintained by Innovar Healthcare, Inc. (Montgomery, Alabama), publicly launched in 2025 with development on public GitHub. (BridgeLink is a trademark of Innovar Healthcare.) BridgeLink forks the same Mirth Connect 4.5.2 source, so its compatibility story matches OIE’s: channels, transformers, filters, and custom plugins built against the Mirth Connect Plugin API carry over, and the engine itself is free.
What actually differs between forks is stewardship and the services ecosystem around the code. OIE is governed by the Eclipse Foundation with a multi-vendor community. BridgeLink is vendor-led: Innovar Healthcare drives the roadmap and sells optional paid offerings around the open-source core (support, assessments, training, add-on products, and AWS Marketplace editions); see innovarhealthcare.com for the current catalog. Other, smaller forks of the 4.5.2 codebase exist on GitHub as well; before betting production traffic on one, check its release cadence and security-patch history.
When a Different Fork Makes Sense
- You have already engaged the fork’s steward as a consulting or services partner (for BridgeLink, that is Innovar Healthcare) and want the engine and the services from the same vendor.
- The steward’s commercial model fits your procurement: for example, buying BridgeLink support through AWS Marketplace.
For most organizations evaluating an open-source Mirth fork for the first time, OIE’s vendor-neutral governance at the Eclipse Foundation and broader multi-vendor ecosystem make it the more flexible default, and any actively maintained fork is technically viable. For a deeper head-to-head on features, licensing, support, and total cost, see our OIE vs BridgeLink vs Commercial Mirth Connect comparison.
Option 5: Alternative Integration Engines
If you are open to moving away from the Mirth Connect ecosystem entirely, several other healthcare 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 published Mirth comparison and migration material. 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, succeeded today by HealthShare Health Connect on InterSystems IRIS) 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
The Google Cloud 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:
| Feature | Stay on 4.5.2 | Commercial Mirth 4.6+ | OIE | BridgeLink & other forks |
|---|---|---|---|---|
| License | MPL 2.0 (open source) | Commercial (proprietary) | MPL 2.0 (open source) | MPL 2.0 (open source) |
| Cost | Free | Annual subscription ($$$) | Free | Free (+ optional vendor services) |
| Channel Compatibility | N/A (same platform) | Full | Full | Full |
| Security Patches | None (Sep 2026 CVEs stay open) | Yes (vendor-provided) | Community-driven (Sep 2026 fixes in progress) | Steward-driven |
| Active Development | No | Yes | Yes | Fork-dependent (BridgeLink: yes) |
| New Features | No | Yes | Yes (community roadmap) | Yes (steward-led roadmap) |
| FHIR Support | Limited (4.5.2 level) | Enhanced | Standard Mirth FHIR | Standard Mirth FHIR |
| HL7 v2 Support | Full | Full | Full | Full |
| DICOM Support | Full | Full | Full | Full |
| Cloud Deployment | Self-managed | Self-managed + options | Self-managed (any cloud) | Self-managed (any cloud) |
| Vendor Support | None | NextGen support | Community; multi-vendor (including Saga IT) | Fork steward (Innovar Healthcare for BridgeLink) |
| Monitoring/Analytics | Basic (built-in dashboard) | Enhanced | Built-in dashboard (+ optional OpenShare console) | Basic (built-in dashboard) |
| CI/CD Tooling (MirthSync) | Yes | Not targeted | Yes | Yes |
| Migration Effort | None | Low (version upgrade) | Low (install + import) | Low (install + import) |
| Long-term Viability | Poor | Strong | Strong (community-dependent) | Steward-dependent |
The table answers feature-by-feature questions. The next two visuals answer the bigger ones: what will this actually cost, and where do the alternatives sit on cost vs. risk.
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 any server that speaks the standard Mirth Connect REST API: open-source Mirth Connect through 4.5.2, OIE, and BridgeLink.
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:
# Pull channels from your existing Mirth Connect instancemirthsync -s https://old-mirth:8443/api -u admin -p admin -t ./mirth-config pull
# Commit to Git for version controlgit add -A && git commit -m "Export from Mirth Connect 4.5.2"
# Push channels to your new OIE (or BridgeLink) instancemirthsync -s https://new-oie:8443/api -u admin -p admin -t ./mirth-config pushOngoing 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
Based on a decade of Mirth Connect work, 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 fixes and features come from an active multi-vendor community (for the September 2026 CVEs, a patched OIE-based build is available while the upstream release is prepared).
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, any maintained fork can be backed by paid services. OIE has the broadest 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. Vendor-led forks like BridgeLink bundle the engine with their steward’s services catalog instead (see Innovar Healthcare for BridgeLink’s).
Whichever Fork You Pick: Add OpenShare
Since we first published this guide, we launched OpenShare, and it is now live in open beta. OpenShare is not another engine and not a migration target. It is a browser experience layer for the engine you already run: install one plugin on your OIE, Mirth Connect, or BridgeLink server and you get a web console for channel building and administration, real-time fleet monitoring, secure outbound-only remote access (no open inbound ports), and direct end-to-end-encrypted data exchange with partner organizations. No new engine, no channels to move, and it is still your data on your MPL 2.0 engine. Read the OpenShare launch announcement or try the open beta.
What We Advise Against
Do not plan around staying on Mirth Connect 4.5.2. Since September 2026 it carries disclosed vulnerabilities that NextGen will not fix in the open-source line, and the risk compounds from there. 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:
- Assess your current state. Inventory your Mirth Connect instances, channel count, message volume, and integration complexity.
- Choose your path. Use the comparison table and decision framework above to identify the best option for your organization.
- Plan your migration. Allocate time for staging environment setup, channel testing, and production cutover.
- 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 works across open-source Mirth Connect, OIE, and their forks. We also offer specialized support for organizations moving to the Open Integration Engine, and HL7 integration services for rebuilding and validating your interfaces on the new platform.
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.