Mirth Connect 4.6: What It Means for Open-Source Users and Next Steps

Mirth Connect 4.6, launched on March 19, 2025, marks a major shift in healthcare interoperability as it moves to a fully commercial model. This change has left many open-source users uncertain about the future of their integrations and looking for alternatives.

At KPi-Tech, we understand the concerns of healthcare organizations relying on Mirth for seamless data exchange. With years of expertise in interoperability and Mirth integration, we’re covering everything you need to know, from what’s changing and why, to how it impacts you and the best next steps for your organization.

What’s the big change with Mirth Connect 4.6?

The most significant shift with Mirth Connect 4.6 is its transition from a dual-licensing model (where both open-source and enterprise versions coexisted) to a single, commercial-only license. As of March 19, 2025, NextGen Healthcare has ceased releasing open-source updates, making all future enhancements, security patches, and support exclusive to the enterprise edition.

According to NextGen, this change is intended to create a more secure and reliable platform while enabling greater investment in innovation and compliance with evolving regulations like HIPAA and ONC certification. However, for open-source users, this presents a critical decision:

For open-source users, this does not mean immediate disruption. Organizations can continue using their current version, though ongoing maintenance and updates will require internal management. Alternatively, those looking for continued updates and official support can explore the enterprise model. While this change requires careful consideration, there are viable paths forward, whether through maintaining existing setups, transitioning to the enterprise version, or exploring alternative solutions.

What Does the Licensing Shift Mean for Existing Open-Source Mirth Users?

From our expertise in healthcare interoperability, we view this transition as both a challenge and an opportunity for organizations relying on Mirth Connect. Until version 4.5.2, Mirth remained open source, giving healthcare IT teams the flexibility to build, customize, and manage their integration infrastructure. However, with NextGen’s move to a commercial-only model, official support for the open-source version has ended.

That said, open-source users still have viable options:

• Continue using their current version – Organizations can remain on their existing setup while taking responsibility for maintenance and security.
• Upgrade to the last stable open-source version (4.5.2) – This ensures access to the most stable open-source release.

All previously released open-source versions will remain available under their respective Mozilla 1.0 or 2.0 licenses, with release notes, upgrade documentation, and source code still accessible on GitHub. However, ongoing security and compliance for these versions will now be the responsibility of the users.

Starting from version 4.6, Nextgen offers three Mirth subscription plans: Enterprise, Gold, and Platinum. For most healthcare entities, the Enterprise plan (the base version) is sufficient to meet their needs. However, those who require advanced clustering and alerting systems may opt for the Platinum subscription.

The strength of Mirth’s open-source editions has always been their high level of customization and configurability, allowing organizations to tailor the platform to their unique integration needs. While this licensing change brings new considerations, open-source users still have the flexibility to make informed decisions that align with their operational goals.

What Does the End of Open-Source Support Mean for Users?

With NextGen shifting Mirth to a commercial-only model, open-source users may wonder about the future of their environment. The good news is, as the commercial version offers vendor-managed security, advanced monitoring, and built-in version control, open-source users still have reliable ways to maintain and enhance their Mirth environments.

How Can Security Be Managed?

For security, open-source users will need to take ownership of patching vulnerabilities, but this isn’t new; many healthcare IT teams already manage security updates for other open-source tools. For instance, if a new vulnerability like CVE-2023-43208 (remote code execution, which Nextgen later corrected in 4.4.1 or later versions) emerges, organizations will need to implement their security patches.

What About Monitoring and Analytics?

While Mirth 4.6 introduces the Mirth Command Center, users can achieve similar monitoring with Grafana or Kibana using REST APIs. Version control for channels can also be managed by integrating Mirth with Git repositories. Channel statistics and logs can be extracted from Mirth’s database (e.g., PostgreSQL) to create customized analytics and monitoring solutions.

How Can Users Maintain Version Control?

Although the enterprise edition includes built-in channel versioning, open-source users can integrate Mirth with Git repositories to track changes, collaborate, and ensure streamlined deployment.

While vendor support is beneficial, open-source users are not left without options. With the right technical expertise, organizations can maintain, optimize, and even enhance their existing Mirth instances. At KPi-Tech, we help clients sustain open-source Mirth environments by integrating them with analytics tools, security frameworks, and automation solutions, ensuring efficiency, compliance, and long-term sustainability.

What does it take for organizations to migrate to Mirth Connect 4.6 or later?

A successful migration requires compatibility checks, security enhancements, and infrastructure adjustments to prevent disruptions.

Understanding the Licensing Shift

The key consideration is licensing, as Mirth Connect 4.6 is no longer open source. Organizations must choose between Enterprise, Gold, or Platinum plans, which introduce proprietary features like the Mirth Command Center, SSL Manager, and Channel History. These enhancements improve monitoring, compliance, and security but come at an added cost. NextGen has not released the pricing on their website, its available upon request.

Organizations must evaluate each plan based on their integration needs, budget, and long-term scalability. While the Enterprise plan provides essential compliance and monitoring tools, Platinum may be more suitable for large-scale environments needing advanced interoperability capabilities.

In addition to licensing fees, organizations should account for migration costs, which could be an additional cost if outsourced to NextGen or a certified partner. These costs cover infrastructure assessment, data migration, testing, and deployment support. Internal expenses for IT resources, staff training, and ongoing maintenance should also be factored in.

This marks a significant shift from the zero-cost open-source model to a structured, paid solution. Organizations must weigh the benefits of vendor support, enhanced security, and enterprise features against these new financial considerations.

Key Considerations for Migration

A successful migration requires compatibility checks, security enhancements, and infrastructure adjustments to prevent disruptions.

• Java & Infrastructure Readiness: Mirth 4.6 requires Java 11 or 17. Organizations running older Java versions (e.g., Java 8) must upgrade before migration. Also, Derby is no longer a preferred database; switching to PostgreSQL or MySQL ensures long-term stability.
• Custom Scripts & Libraries: Many open-source users rely on custom JavaScript transformers and Java libraries. Post-migration, some deprecated functions may break, requiring refactoring and revalidation of scripts.
• Configuration Backup & Testing: Back up channels, connectors, database configurations, logs, and scripts before migration. A controlled sandbox/testing environment is crucial to validate data flows before going live.
• API & Third-Party Integrations: If external APIs, custom REST/SOAP services, or vendor-specific adapters are in use, they must be tested thoroughly. Many migrations fail due to insufficient volume-based testing, so we recommend proactive validation, including load testing and data deduplication strategies. Changes in authentication, TLS settings, or endpoint structures could impact connectivity.
• Planned Downtime & Contingency Measures: Migration may require a 1–4 hour maintenance window, depending on channel complexity and data volume. Having a rollback plan (e.g., restoring backups of Mirth 4.5 or earlier) ensures quick recovery if unexpected failures occur.

While NextGen offers migration support for paid users, open-source users must handle these complexities independently. At KPi-Tech, we provide structured migration plans, custom script refactoring, API revalidation, and proactive monitoring to ensure a smooth transition without breaking critical integrations.

What’s the right choice: stick with open source, jump to 4.6, or switch to another engine entirely?

Deciding between staying on Mirth 4.5 (open source), upgrading to 4.6 (paid), or switching to another integration engine depends on several factors, including cost, long-term sustainability, feature needs, and organizational expertise.

• Stick with Open-Source (e.g., 4.5.2): Go this route if you’re cost-sensitive, have custom integrations you can maintain, or don’t need new features. You’ll rely on your team or certified partner for security updates and maintenance.
• Jump to 4.6 Upgrading to Mirth 4.6 is ideal for organizations that lack in-house capability to maintain and customize the open-source version and require official support, security updates, and access to proprietary features. It is particularly beneficial for large-scale healthcare systems that need advanced compliance and interoperability capabilities. Enterprises relying on NextGen’s bundled extensions, such as SSL Manager, Message Generator, and advanced clustering and alerting, will find value in making the transition.

However, moving to 4.6 may come with challenges. Since there is no automated migration path from 4.5 (at least not given on the Nextgen website yet), users must manually migrate channels, scripts, and configurations. Additionally, upgrading may require updating Java to version 17 and adjusting database configurations to align with the new system requirements. The transition may come with a potentially high cost, as organizations must purchase a commercial license, which may be a significant investment depending on the selected plan. Vendor lock-in is another factor to consider, as it limits flexibility compared to open-source alternatives.

• Switch Engines: Switching to another integration engine is a viable option for organizations looking to maintain control over their interoperability strategy without being tied to vendor licensing. Many healthcare organizations explore alternatives when seeking a more cost-effective, scalable, and flexible solution that aligns with evolving interoperability requirements. Open-source or commercially supported engines provide opportunities to build and customize integrations without the constraints of proprietary software.

However, migrating to a new engine requires significant planning, as it involves reconfiguring interfaces, testing compatibility, and ensuring minimal disruption to operations. Organizations must assess whether the long-term benefits, such as improved scalability, better FHIR/API support, or enhanced cloud-native capabilities, outweigh the transition effort. The decision ultimately depends on the organization's specific needs, budget constraints, and willingness to invest in migration and retraining efforts. With 25 years of steering interoperability at KPi-Tech, we have guided clients through all three paths.    

Need help navigating the transition? KPi-Tech can provide expert guidance to assess your best path forward. Reach out to us for a consultation.