Mirth Connect vs NextGen Connect — The Rebrand Explained

Mirth Connect was originally built by WebReach in the mid-2000s as an open-source HL7 integration engine. It quickly became one of the most widely deployed open-source integration engines in healthcare because it was free, well-documented, and capable of handling production workloads.

WebReach was acquired by Mirth Corporation, which continued developing the product. Mirth Corporation was then acquired by Quality Systems Inc — which subsequently rebranded the parent company as NextGen Healthcare.

After the acquisition, NextGen Healthcare consolidated branding across its product portfolio. The integration engine that everyone called "Mirth Connect" was officially renamed NextGen Connect Integration Engine.

The product itself — the codebase, the channels, the admin console — did not get rewritten. The rebrand was primarily a naming and corporate-identity change.

Beyond the name, a few things did genuinely change.

The product name in official documentation. NextGen Healthcare's official docs, support materials, and commercial product pages refer to it as NextGen Connect Integration Engine. The "Mirth" name persists in the community and in open-source materials but has been retired from official commercial branding.

The commercial support relationship. If you have a paid support contract, that contract is now with NextGen Healthcare under the NextGen Connect name. Pricing, contact channels, and support tiers reflect NextGen's commercial structure.

The product release cadence. Releases of the commercial version follow NextGen's product roadmap. New features tend to land in commercial releases first and propagate to the open-source version on a longer cycle.

The corporate-product certifications. When NextGen Connect is mentioned in vendor approval contexts (Epic Connection Hub registrations, partner directories, regulatory filings), the listed product name is NextGen Connect, not Mirth Connect.

This is the more important list for most teams.

The codebase is the same product. Your existing channels, transformers, deploy scripts, and integration logic continue to work. The rebrand was not a rewrite.

The open-source version still exists. The community open-source release is still available, still free, and still widely deployed. NextGen has not pulled it.

The admin console, the APIs, and the deployment model. All recognizable to anyone who's used Mirth Connect any time in the last decade. The user interface and the operational model are unchanged.

The community knowledge base. Years of forum posts, Stack Overflow answers, blog tutorials, and tribal knowledge written for "Mirth Connect" all still apply. Don't discard old documentation because it uses the old name.

The integration approach itself. Channels with sources, destinations, filters, transformers; MLLP listeners; JavaScript and Groovy transformers; the channel lifecycle. All identical. See how to build an HL7 interface in Mirth Connect for a walkthrough of the engine as it exists today under either name.

If you've been running Mirth Connect for years and you're worried that the rebrand obsoleted your skills or your deployment, it didn't. You're running the same engine with a different name on the box.

This is the part most people miss. There are effectively two products under the umbrella.

The open-source version. Available for free download. Maintained as an open-source project. Used by the majority of teams that aren't on a paid support contract. Most online tutorials and the broader community are referring to this version when they say "Mirth Connect." Still commonly called Mirth Connect in community discussion.

The commercial version. NextGen Connect Integration Engine as sold by NextGen Healthcare. Same core engine plus commercial support, certification, additional commercial-only features over time, and integration with NextGen's broader product suite. Used primarily by NextGen EHR customers and larger healthcare organizations that want a paid support relationship.

A common point of confusion: people see "NextGen Connect" in a vendor's marketing material and assume it's a different product than the "Mirth Connect" they're running. It's not. It's the commercial release of the same engine.

The reverse is also true: people running a recent download of "Mirth Connect" open-source are not running an outdated product. They're running the open-source release of the same engine that NextGen sells commercially.

If you're already running Mirth Connect in production, here's what the rebrand means for you.

If you're on the open-source version: Nothing urgent changes. You can keep running it indefinitely. New releases continue to be available. Your existing channels and deployments are not affected.

If you're on a paid NextGen support contract: Your contract is now described as NextGen Connect rather than Mirth Connect, but the support relationship continues as before.

If you're documenting your integration architecture: Update internal documentation to mention both names (or at least to note that they refer to the same product). New engineers joining your team will encounter both names and benefit from clarity.

If you're hiring integration engineers: Job postings should mention both names. "Mirth Connect experience required" is well-understood by candidates. "NextGen Connect experience required" is less recognized in the talent market — many capable Mirth engineers don't know that's what NextGen calls it. We've seen this mistake cost teams qualified candidates. If you'd rather not run that risk in-house, we place senior Mirth Connect developers on fractional or embedded engagements.

If you're presenting to procurement, finance, or compliance: Use NextGen Connect as the official product name in formal documentation. Mention "previously known as Mirth Connect" parenthetically. Procurement teams and auditors increasingly want to see the official commercial product name.

If you're choosing an integration engine for a new deployment, the rebrand does not meaningfully change the product evaluation. You're evaluating the same engine that's been deployed in thousands of healthcare environments for over a decade. Background context lives in our Mirth Connect guide and the broader HL7 integration guide.

The decision you actually need to make is which version — open source or commercial.

Choose open source when:

• You have in-house engineers who can install, configure, and support the product.
• Your message volume and uptime requirements don't demand a commercial SLA.
• You want the lowest possible license cost (zero, since it's open source).
• You're comfortable getting support from the community, consultants, or an independent provider.

Choose commercial when:

• You're already a NextGen Healthcare EHR customer and want vendor-bundled support.
• You want a single throat to choke for product issues.
• You have procurement or compliance requirements that need a formally licensed commercial product.
• You want commercial-only features as they become available.

For the vast majority of healthcare organizations we've worked with, the open-source version plus paid Mirth Connect support from an independent provider is the most cost-effective option. You get senior engineering support without the vendor lock-in that comes with a NextGen-bundled relationship.

Across this site we use "Mirth Connect" as the primary name because:

The community still uses it. The vast majority of search traffic uses the older name. Most existing documentation, tutorials, and community knowledge uses it. The open-source version — which is what most teams actually run — is still referred to as Mirth Connect within the community.

Where the official product name matters — vendor certifications, formal documentation, contract language — we use NextGen Connect Integration Engine.

We treat the two names as interchangeable when describing the engine itself. Any time you see "Mirth Connect" in our docs or guides, it applies equally to NextGen Connect.

NextGen Healthcare has indicated continued investment in the product. The release cadence has been steady. The open-source version continues to be maintained.

The trajectory we see in the market:

More cloud-native features. Container support, Kubernetes-friendly deployment patterns, and managed-service offerings are evolving in both the commercial and open-source releases.

Continued FHIR investment. As FHIR adoption accelerates across US healthcare, the engine is getting better FHIR-native features. The HL7 v2 capabilities aren't going anywhere — they're getting complemented by stronger FHIR tooling. See our FHIR Bulk Data implementation guide for an example of the kind of work that's now natively supportable in the engine.

Better observability. Newer versions ship with better metrics, monitoring, and admin tooling than the versions most teams are still running.

If you're on a version more than 2 years old, plan an upgrade in the next 12 months. Not because the older version is broken, but because the newer versions have meaningful operational improvements and the upgrade gets harder the longer you wait. The NextGen Connect Upgrade Sprint exists to handle exactly this work as a fixed-price, fixed-scope project.

If you're running Mirth Connect and want a current-state assessment, our free Mirth health check covers exactly this — including identifying whether you're running an outdated version, what would be involved in upgrading, and whether your current setup is configured for your actual workload.

If you're evaluating Mirth Connect / NextGen Connect against alternatives, our pillar guides on Mirth Connect, HL7 integration, and healthcare interoperability give the broader context.

If you need engineering capacity to support, upgrade, or extend a Mirth deployment, we place senior Mirth engineers on fractional, project, or embedded engagements.

For pricing on any of the above, run our pricing calculator — it covers both the open-source and commercial versions equivalently since the engineering work is the same.