Honest alternatives to iNTERFACEWARE Iguana

Once you decide that Iguana deserves a contingency plan, the next question is obvious: what would you replace it with?

The less obvious answer is that there is no universally correct interface engine. A twenty-bed clinic, a national laboratory network, and a software vendor embedding an engine into its product are not shopping for the same thing.

I have tried to look at the options the way I would look at a real interface project: what problem does each one solve well, and what inconvenience arrives in the same box?

Option one: keep Iguana 6 running for now

This is a real option, not an absence of courage.

If the current version is stable, licensed for your environment and supported by people who understand your channels, keeping it in place while you prepare may be the lowest-risk short-term decision. It avoids a rushed rewrite and gives you time to export, document and test properly.

The weakness is that it does not answer the longer-term questions around vendor capacity, security updates, licensing or deployment restrictions. I would only choose this path with a dated review point, a tested restore, clear support contacts and a migration proof already underway.

Option two: wait for Iguana X

The proposed direction for Iguana X has some attractive ideas. iNTERFACEWARE says it intends to remove the license system, release the source under MPL 2.0, reduce external dependencies and allow fully on-premises operation.

Open code can reduce one kind of vendor lock-in, but it does not manufacture maintainers, support cover or production maturity. The same roadmap says important work remains on the queue, security model, and platform dependencies. For a technically strong team that likes Iguana's architecture, it may be worth evaluating. I would not make an unfinished roadmap my only continuity plan.

Option three: Open Integration Engine

Open Integration Engine is the community fork that continued after NextGen moved Mirth Connect 4.6 to a proprietary commercial license. It will feel familiar to anyone who already knows Mirth: channels, JavaScript transformations, connectors, queues and the usual Java-based operational model.

The project is moving. Version 4.6.0 was released in July 2026; it has a public governance model, and it is pursuing Eclipse Foundation stewardship. That makes it considerably more credible than a forgotten fork with one enthusiastic maintainer.

Its strength is control. It is open source, deploys wherever the JVM runs, and has a large amount of inherited Mirth knowledge around it. Its trade-off is also control: your team owns more of the patching, plugins, deployment engineering and support arrangement. “Free” interface engines have a habit of sending their invoices in hours rather than currency.

Option four: Rhapsody or Corepoint

Rhapsody and Corepoint remain the reassuring enterprise choices. They cover the healthcare standards people expect, provide on-premises, SaaS and managed deployment options, and can wrap the engine with 24x7 support, high availability and a substantial services organization.

If your procurement team wants a mature vendor, formal support commitments and an architecture that has already been used at very large scale, these belong on the shortlist.

The trade-offs are cost, training and weight. A large enterprise platform can solve problems you genuinely have, but it can also bring processes and complexity that a smaller integration team did not ask for. Get the full price: licenses, non-production environments, high availability, training, migration and ongoing support.

Option five: Qvera

Qvera is a credible healthcare-specific commercial engine with broad standards and protocol support. It can run on-premises, in cloud environments and in containers, and its visual approach may suit teams that want less code than Iguana normally involves. It also has an established support and services model.

I would assess it in the same way as any other commercial replacement: prove a difficult channel, confirm how source control and environment promotion work, test the operational dashboard, and obtain firm figures for licensing and migration. A long feature list is useful, but the difficult five percent of your interfaces normally makes the decision.

Option six: Integration Soup

This is the option I keep coming back to for my own work.

Integration Soup sits in a useful middle ground. It has the workflow designer, dashboard, queues, logging, alerts, scheduling, transformations and code extension points I expect from a proper interface engine. It works with HL7, FHIR, JSON, XML, CSV, databases, files, web services and DICOM, with AWS and Azure extensions where cloud services are part of the workflow.

At the same time, it is unusually easy to reason about. The current browser interface still feels like the full product, not a text editor wearing an interface-engine badge. Receivers, transformations, routing and destinations remain visible as one operational workflow. When code is the clearest answer, C# and the .NET ecosystem are there; when code would just be showing off, the visual activities do the job.

The honest caveat is that Integration Soup is a smaller vendor than the large enterprise incumbents. That should prompt proper questions about support cover, releases and continuity, just as it should for every vendor after the events at iNTERFACEWARE. The useful difference is that the team is offering a concrete Iguana migration service, price-matched licensing for approved migrations and hands-on conversion support rather than simply saying “our engine can do HL7 too”.

What I would put in the evaluation

I would give each shortlisted supplier the same representative channel. Not the easy ADT relay. Give them the one with shared Lua modules, a VMD, a database lookup, two destinations, a custom ACK rule and the failure case everyone is frightened to touch.

Then score the result against the things that matter after the demo:

• Can we deploy it where our organization permits?
• Can we export and version everything needed to rebuild it?
• Can support staff see why a message failed without becoming developers?
• Can developers use code cleanly when the mapping stops being simple?
• Are queues, retries, alerts, certificates and audit history part of the product?
• What does high availability actually include?
• Who answers a production support case, and when?
• Can the vendor prove the migrated output against the current Iguana behavior?

My direction

If I were advising a large hospital that valued enterprise scale above simplicity, I would evaluate Rhapsody or Corepoint. If retaining an open-source Mirth-style model was the main requirement, I would test Open Integration Engine. Qvera deserves a place in a commercial shortlist.

For teams that liked Iguana because it made powerful integration work approachable, I think Integration Soup is the most natural place to start. It covers the whole operational job without making every interface feel like a software-development project, but it does not trap you in a toy environment when proper code is needed.

The deciding factor, though, is not my preference. It is whether your own ugliest channel can be rebuilt, replayed, and shown to behave correctly. That is what the final post in this series will cover.