Comparing HL7 Integration Engines: 2026 Review

Updated July 2026

Last year I compared some of the main HL7 interface engines and ended up choosing HL7 Soup Integration Host. A lot has changed since then. Mirth has completed its move away from open source, iNTERFACEWARE has taken a rather unusual new direction, and HL7 Soup Integration Host has a new name: Integration Soup.

My own thinking has changed a little as well. I used to give code-led engines extra credit simply because anything could be coded. After spending more time inside some of our older Lua interfaces, I am less convinced that writing everything ourselves is an advantage. Modern graphical engines are far more capable than they used to be, and they can remove a lot of repeated logging, connection, security and error-handling code without limiting the business logic.

Integration Engine	License & Cost	Ease of Use	Standards & Connectivity	Scalability & Deployment	2026 View
Integration Soup Previously HL7 Soup Integration Host	Commercial subscription with workflow, site and enterprise options. Pricing is by quote. A 30-day trial is available.	Very high. Visual workflows, drag-and-drop transformations and readable message views cover most ordinary work. C# remains available when code really is the clearest answer.	HL7 v2, FHIR, JSON, XML, CSV and now DICOM. MLLP/TCP, HTTP/S, REST/SOAP, OAuth, files and broad database support. Extension libraries add cloud, SFTP, validation, document and encryption activities.	On-premise or cloud deployment, with Windows and .NET Core builds. Azure and AWS extensions, Git-based workflow deployment and product, site and enterprise licensing options.	Strengths: The easiest product here to understand quickly. Version 4.0 added useful depth without losing the simple workflow model. HL7 Soup Web is becoming an excellent browser companion, and the migration tooling is a real advantage. Weaknesses: Smaller vendor and installed base than the enterprise incumbents. I would like to see more of the full Integration Soup experience move into the browser.
Infor Cloverleaf	Commercial enterprise product with quote-based pricing.	Medium. GUI tools and wizards are improving, but complex work can still require specialist Cloverleaf and TCL knowledge.	HL7 v2, FHIR, CDA, X12 and broad legacy connectivity. Includes API gateway, FHIR and Da Vinci capabilities.	Very high scalability and high availability. Available on-premise, in the cloud or as a hybrid deployment, including container options.	Strengths: Proven at large healthcare organisations, broad standards support and strong operational reliability. Weaknesses: Enterprise cost and complexity. It remains a product that benefits from experienced specialists rather than occasional interface developers.
iNTERFACEWARE Iguana / IguanaX	Commercial. Published pricing starts at US$10,000 per year for two integrations, with larger packages by quote.	Low to medium. IguanaX has a more visual component model, but Lua and code remain central to building and maintaining the interfaces.	HL7 v2, FHIR, JSON, XML, REST, databases, files and other formats through components, libraries and custom Lua.	Cross-platform deployment with cloud options. IguanaX development is active, with high availability and SSO identified as current areas of focus.	Strengths: Fast, flexible and still extremely capable when you have strong developers and want complete control. Weaknesses: My experience of the older codebase has exposed how much repeated plumbing the customer can end up owning. More importantly, the company now describes itself as being largely run by its founder. Whatever the theory behind that decision, it creates a support and business-continuity concern for a production interface engine.
Rhapsody Corepoint	Commercial enterprise pricing based on organisation size, deployment model and requirements.	Very high. Its graphical, analyst-friendly approach remains one of the strongest in the market, and Rhapsody Axon now adds integrated AI assistance.	HL7, FHIR, REST APIs and other healthcare formats, with reusable actions, testing, monitoring and alerting.	Enterprise scale with high-availability options. Available as SaaS, on customer infrastructure or as an iPaaS deployment.	Strengths: Excellent GUI, support and enterprise record. It was named Best in KLAS again in 2026 and is no longer fairly described as simply Windows-only. Weaknesses: Premium pricing and a closed platform. It can be more product than a smaller integration team needs.
Mirth Connect by NextGen Healthcare	Mirth Connect 4.6 and later are commercial and proprietary. Version 4.5.2 remains available as the final open-source release but is no longer maintained by NextGen.	Medium. The channel GUI is familiar to a very large community, but JavaScript or Java is still needed for a lot of real mapping and workflow logic.	HL7 v2, X12, JSON, XML, REST, SOAP, DICOM and commercial FHIR capabilities.	Cross-platform and cloud-agnostic, with commercial clustering, security extensions and central monitoring through Mirth Command Center.	Strengths: Huge installed base, a great deal of existing knowledge and very flexible scripting. The commercial product continues to be developed and supported. Weaknesses: The maintained free edition is gone. The dated development experience and amount of scripting are harder to excuse once commercial licensing is part of the decision.
Qvera Interface Engine (QIE)	Commercial with flexible subscription licensing and pricing based on requirements.	High. A browser-based visual channel editor handles the main workflow, with JavaScript available for more complex requirements. Qvera now also promotes an AI Companion for help, mapping and troubleshooting.	HL7 v2, FHIR, CDA, X12, DICOM, ASTM, databases, JSON, XML and web services.	Cloud-optimised and container-friendly, with AWS, Azure and Google Cloud deployment and orchestration options.	Strengths: Modern web interface, strong standards coverage, credible cloud deployment and a good reputation for support. It remains one of the strongest alternatives in this list. Weaknesses: Smaller market share than the major enterprise platforms, quote-based pricing and some scripting for complex work.

So... what do I choose in 2026?

The answer is still Integration Soup, although I think I have better reasons for choosing it this year.

In the past I tended to see a code-first engine as the more powerful option. If everything is code, then surely nothing is out of reach. The problem is that you also take responsibility for everything you code. Looking through our existing Iguana libraries, a surprising amount of the Lua is there to manage connections, logging, errors, security and cleanup. It is important work, but it is also repeated work, and every copy becomes another place for a mistake or an old security decision to survive.

Modern graphical engines do not have the same limitations that put people off them years ago. A good workflow designer can handle the normal integration work while still allowing code where it is genuinely useful. That leaves the developer concentrating on mappings, transformations and the rules that are actually different for that interface.

Integration Soup 4.0 has moved a long way in that direction. It now has broader database support, DICOM, Azure and AWS extensions, stronger source-control deployment and tools for converting existing channels. The rename from HL7 Soup Integration Host also makes sense: this is now much more than an HL7 utility with an engine attached.

I particularly like what is happening in the browser. HL7 Soup Web is already a very good way to inspect, understand and share a message, and Integration Soup is beginning to take over from there when that message needs to become a real workflow. I would definitely like to see more of the Integration Soup experience move into the browser, but the direction looks right.

Corepoint and Qvera remain very credible alternatives, and Cloverleaf is still difficult to argue with at true enterprise scale. For the sort of work I actually want to build and maintain, though, Integration Soup gives me the best balance: a proper interface engine, a modern GUI, code when I need it, and far less code that I have to own simply to keep an interface safe and running.

I’ve just found a very handy feature in HL7 Soup Online for sharing an HL7 message with someone else.

Right-click on any message in the list and select Copy message as link. This puts a hyperlink onto your clipboard which you can then paste into an email, support ticket or chat message.

Right-click on your message and select Copy message as Link

When the other person clicks the link, the exact message opens for them in HL7 Soup Online. They can see the readable description of the message, click through the fields, and find out what the values mean without having to install anything.

Take a look at this link to see it in action.

This is particularly useful when the person you are sending it to doesn’t work with HL7 every day. Pasting the raw message into an email normally gives them a block of text full of pipes and carets. Sending the link lets them see that it is a patient registration, which details are for the patient, what sort of visit it is, and where each value sits in the message.

I can see this being useful when asking a software vendor about a particular field, adding an example to a support ticket, or explaining a message to someone who understands the workflow but not necessarily HL7.

There is one important thing to remember. The message is included in the link, so you should treat that link in exactly the same way as you would treat the original message. Don’t copy a live message containing patient information and send it as it is.

HL7 Soup Online has an Anonymize menu at the top of the screen. If you are starting with a real message, anonymize it before creating the link. I would still have a quick look through the result afterwards to make sure that any local identifiers or unusual fields have also been dealt with. If possible, a synthetic test message is always the safest one to share.

That’s really all there is to it. Right-click the message, copy the link and send it. The recipient gets the actual message in a tool that helps them understand it, rather than having to work it out from the raw HL7 themselves.

Moving an Iguana Database Interface

Take a fairly normal Iguana interface that receives a message and writes some of it to a database.

The useful part is quite small. Read a few values from the message, convert them into the format the database expects, and insert or update the record.

But that isn’t all the Lua we ended up with.

We also need to open the database connection, make sure it is still available, handle the error if it isn’t, log enough information to work out what happened, and make sure everything is closed properly afterwards. If the interface needs to retry, that needs to be dealt with as well.

None of this is unusual code. In fact, that is really the point. It is code for exactly the same problems that every database interface has.

I have been looking at this while starting to move our Iguana channels to Integration Soup. When I create the database step there, the connection and the normal failure handling belong to the engine. I configure what I want to do and concentrate on the values I want to write.

The result is that most of the old Lua doesn’t need to be converted at all. It wasn’t business logic. It was just everything we had written around the business logic to make it safe to run.

I must admit, the large Lua libraries had always made the interfaces feel quite powerful. If we needed something, we could code it. That is still useful, but it also meant we took responsibility for a lot of things that would probably have been better handled by the integration engine.

It also makes later changes harder than they need to be. We have some old TCP interfaces where TLS now needs to be added. With our own implementations, each one has to be checked and updated. In Integration Soup it is a connection setting, so the same tested implementation is used throughout.

There will still be places where I use code. Some mappings and unusual rules are simply easier that way. But I would much rather use code for the bit that makes an interface different, and let the engine look after the bits that are the same every time.

That is probably the biggest improvement I have seen from the conversion so far. I’m not losing the useful code. I’m finding out how much of the other code I no longer need.

How Much Iguana Code Did We Actually Need

I’ve now started looking through some Iguana channels to see what will be involved in moving them to Integration Soup.

One of the first things I noticed was just how much Lua we have. I already knew some of the libraries were quite large, and I suppose I had always taken some comfort from that. All the code was there, we could see what it did, and if we needed the interface to do something different then we could change it.

What I hadn’t really considered was how much of that code had nothing to do with the actual interface.

There is code for logging, opening and closing database connections, handling errors and making sure that a failure doesn’t leave anything in a bad state. We have also written code around TCP connections, certificates and all the other things needed to keep an interface running properly.

Obviously these are all important. The problem is that they are important for every interface, and we have ended up writing much the same code over and over again.

If it is written again for every channel, there is always the chance that one version is going to be slightly different or have a mistake in it. If it is copied from another channel, that helps at the time, but it also means the same code is now scattered everywhere. When something needs to be improved later, every copy has to be found and changed.

You can move it into a common Lua library, and we have done that where it made sense, but then you have a large library that also needs to be maintained and tested. It is better than having lots of copies, but it is still our code and our problem.

This has been particularly noticeable with security. Some of our older TCP interfaces were created without TLS. That is not a situation they should still be in, but adding it means working through the old implementation and making sure the change is made correctly everywhere it is needed.

In Integration Soup the secure TCP/MLLP connection is already part of the product. I still need to configure the certificate and make sure the other system is set up correctly, but I am not having to write or maintain the code that provides the secure connection.

The same thing is happening with the rest of the conversion. Once Integration Soup is handling the connection, logging and normal error behaviour, a surprising amount of Lua is simply no longer required.

What I am left with is mostly the part I am actually interested in: which fields need to be mapped, what needs to be converted, and any business rules that are particular to that interface.

I can still use code when code is the best way to do something. The difference is that I am using it for the unusual part of the interface, rather than using it to provide all the normal features that I would expect the integration engine to handle.

I don’t think there was anything wrong with having Lua available in Iguana. It certainly meant we could get things working. I just don’t think the size of the codebase gave us quite the advantage I had assumed it did.

So far the converted work is smaller and much easier to follow. More importantly, there is less of our own code sitting between a message arriving and it getting where it needs to go.

Iguana to Integration Soup migration

 Migration brochures have a soothing habit of turning a working interface estate into three boxes and an arrow.

Export. Convert. Go live.

Anyone who has supported real HL7 channels knows there is usually rather more hiding inside the arrow. There are Lua modules shared by six channels, a VMD last edited by somebody who has left, environment variables with misleading names, certificates, special ACK rules and sample messages that explain more than the documentation.

The good news is that an Iguana migration does not have to begin from a blank page. Iguana's code-led structure gives us useful source material, and Integration Soup now has a practical process for turning that material into testable workflows.

What do you actually export from Iguana?

The short answer is: the channel exports are the start, not the whole package.

I would collect:

• Git channel exports or Translator project archives. These provide the channel structure and project files.
• All Lua code. Include local modules, shared modules, and any common libraries used across channels.
• VMD files. These often contain message definitions and mapping knowledge that is not obvious from the Lua alone.
• Channel and instance configuration. Source, filter and destination settings, environment variables, queue behavior, web settings and notification rules all matter.
• External dependencies. Record databases, APIs, file locations, certificates, custom executables, plugins and scheduled jobs.
• The channel topology. Document From Channel and To Channel relationships, fan-out, shared queues and any processing split across several channels.
• Representative test data. Include de-identified successful messages, known failures, unusual variants, ACKs and boundary cases. Do not put patient information into a migration repository.

If that sounds like more than a single export button, it is. The point is not merely to preserve the Lua. The point is to preserve the behavior.

How the Iguana pieces map into Integration Soup

An Iguana channel normally has a recognizable flow: receive something, filter or transform it, and deliver it somewhere. Integration Soup expresses the same intent as a workflow.

• The Iguana source becomes an Integration Soup receiver: LLP, HTTPS, file, database or the appropriate input.
• Filters and Translator logic become visual transformers, filters and code activities in the same processing order.
• The destination becomes a sender or workflow activity with its endpoint, payload, retries and response behavior.
• Lua functions and modules are translated into C# and Integration Soup APIs, keeping function boundaries and names recognizable where that helps maintenance.
• VMD mappings become message templates, mappings or code transformers, whichever leaves the intent clearest.
• Environment values become deployment configuration rather than values buried inside a workflow.
• Channel-to-channel routing becomes explicit workflow output and connected activity flow.

I like this approach because it does not pretend the two engines are identical. Iguana runtime calls have to change, and some designs should be simplified rather than copied line for line. The aim is to retain the business rules while producing a workflow that looks native in its new home.

The migration is proven offline

This is the important part.

A converted channel should not be accepted because the diagram looks right or because one cheerful ADT message reached the destination. It should be tested as a regression exercise against what the Iguana channel already does.

Start with the exported samples and de-identified log cases. Feed the same inputs through the reference behavior and the new Integration Soup workflow, then compare:

• the parsed source values and validation results;
• the generated outbound payloads and encodings;
• which routes and destinations were selected;
• ACK content, timing and negative-ACK behavior;
• database writes and queries;
• file names, API requests and other external effects;
• ignored-message and error paths;
• retry, alert, queue and recovery behavior;
• throughput and resource use at representative volumes.

External systems can be stubbed or redirected in the offline environment, so the workflow can be exercised without sending test patients into a production EHR or emailing a thousand imaginary lab results to somebody.

Sometimes the output can be compared byte for byte. Sometimes fields such as timestamps, message control IDs or generated file names are expected to differ. In those cases the comparison should normalize only the agreed dynamic values and remain strict about everything else.

That is what “100% accurate” should mean in a migration: every agreed behavior and test case passes. It should not mean that someone looked at two messages and felt optimistic.

Prove one difficult channel first

I would begin with a representative channel that contains real transformation logic and at least one dependency. This is much more valuable than converting ten relays to make the progress chart look impressive.

The pilot tells you how your organization uses Lua, shared modules, VMDs, environment settings and error handling. Once those patterns are understood, the rest of the estate becomes easier to estimate and convert consistently.

It also gives the support team a chance to use the Integration Soup dashboard, inspect messages, search logs, follow the workflow and decide whether the new system makes operational sense. A migration succeeds when the people on call can support it at 2 a.m., not when the project team completes a spreadsheet.

Cut over in controlled groups

After offline acceptance, I would move a small group of interfaces at a time:

1. Freeze or carefully track changes to the Iguana channel during final testing.
2. Apply production endpoints, credentials, and certificates through controlled environment configuration.
3. Run in parallel or shadow mode where the surrounding systems allow it.
4. Agree the cutover step, monitoring window and rollback trigger before touching production.
5. Switch the listener, route, port or upstream destination during the planned window.
6. Compare live inputs, outputs, ACKs, queues and alerts closely.
7. Keep the old path available for the agreed rollback period, without letting both systems create duplicate downstream effects.

For many channels, the final switch is genuinely simple. The work that makes it simple is the inventory, conversion, and offline proof completed beforehand.

Why I think this is a sensible direction

Integration Soup gives me the things I want from a serious interface engine: visible workflows, queues, logging, monitoring, alerts, scheduling, environment configuration, code when needed, and support for the mix of HL7, FHIR, files, databases, APIs, cloud services and DICOM that turns up in real integration work.

It is also simple enough that the migration does not finish with all the old Lua hidden inside a generic coding window. The workflow remains understandable and operationally useful in the browser, while the translated C# is there for the logic that deserves code.

Most importantly, the Iguana migration service is built around evidence. Export the channels and their dependencies, rebuild the intent, replay the test pack, compare the behavior, then cut over in controlled groups. Approved migrations can also qualify for price-matched licensing and included conversion assistance, subject to the published terms.

There is no magic migration button, and I would be suspicious of one. There is something better: a repeatable path that lets you prove the new interface before the old one stops carrying the messages.

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.

Business continuity concerns with iNTERFACEWARE Iguana

I have been watching the iNTERFACEWARE situation for the last few weeks, and it has reached the point where I wanted to comment publicly.

Iguana is not a little utility sitting on somebody's laptop. For many organizations, it is the thing moving admissions, orders, results, referrals, documents, and billing data while everyone else gets on with providing healthcare. When the vendor behind that engine suddenly changes direction, the practical question is not whether the story is entertaining. It is whether the interfaces will remain supportable.

What can actually be verified?

There are plenty of colorful claims circulating online. I am not going to repeat the ones I cannot verify, and I do not know the circumstances under which any individual employee left.

The public record is concerning enough on its own.

An archived copy of the iNTERFACEWARE company page from 8 June 2026 listed five people in its leadership team: a VP of Finance, a VP of Sales and Marketing, Eliot Muir as founder and CEO, a lead developer and an HR manager. The page celebrated the company's people and workplace culture.

The current company page is startlingly different. It says that the company is now “mostly Eliot”. Engineering, sales and customer support are all assigned to Eliot, while human resources is marked vacant. It also says directly that the employees are gone and describes the one-person organization as an experiment whose results are still coming in.

That is not a rumor about a restructuring. It is the vendor's own description of itself.

There has also been a significant licensing statement. Eliot Muir has said that the next Iguana 6 release will be free, but that its new terms will prohibit running it on AWS, Google Cloud, Microsoft Azure or Oracle Cloud. He also said users of that release would need to sign the new terms.

Separately, iNTERFACEWARE now describes an intention to make Iguana X free under the Mozilla Public License 2.0. That direction may become interesting, but the same page says that the queue needs rewriting, the existing licensing system is to be removed, external dependencies are to be reduced, and the security model needs to be rethought. Those are plans, not a production support guarantee.

Why this matters even if Iguana is still running perfectly

The awkward thing about interface engines is that a healthy dashboard can make everything feel safe.

Your ADT feed can process every message today while the organization is quietly accumulating a very different sort of risk. Who answers a difficult support case? Who reviews and ships a security fix? Who can explain the licensing position to your legal team? Who maintains the build and release infrastructure? What happens if the one available person is ill, overloaded, or simply working on something else?

This is the old “bus factor” discussion, except it is no longer theoretical.

Healthcare interfaces also have unusually long lives. A channel created for a pathology system can still be running years later, complete with one strange Z-segment, a certificate that expires on a Sunday and a receiver that only accepts its own creative interpretation of HL7. The engine vendor does not merely provide an executable. It provides continuity around all of that accumulated behavior.

The proposed cloud restriction is another concern. Whether or not you agree with the security argument behind it, deployment location is normally a decision made by the customer's security, infrastructure and governance teams. A licensing change that rules out the major cloud providers can collide with an organization's approved architecture overnight.

Do not panic, but do not sit still

I would not turn off a working Iguana instance because of a dramatic webpage. Rushed interface-engine migrations are a splendid way to replace one risk with six new ones.

I would, however, do the following now:

• Export every channel. Put the Git exports or project archives somewhere controlled by your organization, not only inside the running engine.
• Collect the dependencies. Include Lua modules, VMD files, shared libraries, environment settings, certificates, connection details and a diagram of linked channels.
• Preserve safe test evidence. Keep de-identified examples of successful messages, failures, ACKs and edge cases. A channel without representative test data is only half an export.
• Get the commercial position in writing. Confirm the version you may run, where you may host it, what support remains available, and what happens at renewal.
• Test a restore. A backup that has never been restored is a comforting theory.
• Assess alternatives before there is an incident. The right time to prove a migration is while the existing system is still processing normally.

The engine is still only half the decision

Iguana became popular for good reasons. Its code-led approach is flexible, its live annotations are genuinely useful, and many teams have years of knowledge invested in it. None of that vanished in June.

But product capability is only one half of a platform decision. The other half is stewardship: support capacity, predictable licensing, security maintenance, release discipline and a migration path that does not depend on wishful thinking.

My conclusion is not “everyone must leave Iguana tomorrow”. It is that every Iguana customer now needs a documented continuity plan. Staying may be one option in that plan, but doing nothing is not a plan.

In the next post, I will look at the realistic alternatives, including the unglamorous option of staying put for a while, the emerging open-source choices, the large enterprise engines, and the newer systems trying to make this work less painful.