Once an estate has decided to leave the commercial track, the next question is practical: what actually has to change to run the same channels on Open Integration Engine, and what will not come across? Open Integration Engine is a community fork of the Mirth Connect codebase, announced in April 2025 and derived from the last open-source release. BridgeLink is a second fork with the same lineage. Because both start from the same code, a channel export usually imports. "Imports" is not "works", and the gap between those two words is the whole project.
This post is the compatibility checklist we work through before quoting a fork migration. It assumes you have already made the buy, hold or migrate decision; if you have not, start with that post.
Start with an inventory, not an export
Before touching a target server, write down what the estate actually uses. For each channel:
- source and destination connector types (MLLP, HTTP, Web Service, Database, File, SFTP, JavaScript Writer, DICOM);
- data types in use (HL7 v2, XML, JSON, Delimited, DICOM, Raw) and any non-default serialization options;
- transformers, filters and response transformers that contain custom JavaScript;
- code template libraries each channel is linked to;
- external dependencies: custom JARs on the classpath, JDBC drivers, calls to Java classes, external databases, file shares, certificates;
- extensions and plugins, especially any commercial ones;
- channel dependencies and deployment order.
The inventory is the deliverable that survives the project. It also tells you, usually within a day, whether this is a two-week migration or a two-quarter one.
What usually moves without trouble
In the estates we have looked at, the following carry over with little or no change:
- standard connectors and their settings;
- HL7 v2 parsing and serialization behaviour;
- channel-level and destination-level queue settings;
- most transformer JavaScript, including the usual
msg,tmp,channelMap,globalMapandloggerusage; - code templates, provided the libraries are exported with the channels;
- alerts, as configuration, though their delivery targets need rechecking.
That is a large share of a typical estate, which is why the fork path is viable at all.
What needs checking, one item at a time
Commercial extensions. Anything that shipped only with a paid Mirth Connect tier has no equivalent in a fork. Advanced clustering, the FHIR extension in its commercial form, commercial connector packs and support-only tooling are the common cases. For each, decide: drop it, replace it with open components, or accept that the affected channels stay where they are. This is the single most common reason a fork migration turns out to be partial rather than total.
Custom JARs and Java calls. Channels that import Java classes directly will run only if the same classes are present on the target and the runtime version agrees. Check the Java version the fork release targets and compile targets of your own JARs. Old JDBC drivers are a frequent surprise.
The database. The backing database schema came from the same codebase, but do not migrate by pointing the fork at your live production database. Stand up a separate instance, restore a copy, and let the target do its own schema work there. Keep the original untouched so rollback stays real.
Server IDs and licensing artifacts. New installation, new server ID. Anything keyed to it — scripts, monitoring, inventory records, partner allowlists — needs updating.
Administrator access. The administrator client, launcher and any automation that drives the REST API should be tested against the target version. Scripts that parse API output are the ones that break quietly.
Certificates and keystores. TLS material does not migrate itself. Plan the keystore move, and verify mutual-TLS MLLP partners in a test window rather than at cutover.
Anything with the vendor name in it. Install paths, service names, log locations and config file names differ in a fork. Backup jobs, log shippers, monitoring checks and runbooks all reference those paths.
Build a target environment that mirrors production
Match the production operating system, Java version, database engine and version, memory settings and network path. A migration validated on a laptop proves that the export imports, nothing more. Give the test environment real interfaces where you can: a test MLLP listener per partner, test SFTP targets, a copy of any lookup database.
Prove it with replayed traffic
Import the channels, then replay captured production messages through both engines and compare outputs field by field. The method, including how to capture a representative message set and what to do about timestamps and control IDs, is in our post on parity testing with replayed messages. Two points specific to a fork migration:
- Compare the encoded outbound message, not just the destination status. A channel can report success and emit a subtly different message.
- Replay the error paths too: malformed messages, a destination that refuses the connection, a partner returning AE. Error behaviour is where small differences between builds show up.
Cut over in waves, with a rollback that was tested
Sequence by risk. A nightly reporting extract and a low-volume outbound feed make good first waves. ADT and results feeds go later, when the team has run the new engine for a few weeks.
A workable pattern per wave:
- Deploy the channels to the target, stopped.
- Stop the channels on the old engine and let queues drain.
- Start them on the target, with the partner's connection pointed at the new host or the same host repointed.
- Watch message counts, queue depth and errors against the prior week's baseline for a defined period.
- Keep the old engine installed, with the channels stopped, until the wave is accepted.
Rollback is simply the reverse, which is only true if the old engine is still there and its database was not modified. Write the rollback steps down before the wave, and rehearse them once in the test environment. The question to answer in advance is not "will we roll back" but "at what number do we".
What you take on
A fork removes an engine license fee. It does not remove responsibility. You are adopting a project's release cadence, its security-patch practice and its community support model, and you should check both forks' release history and issue activity before choosing between them. Budget for staying current: a fork you never upgrade recreates the position you left.
For a well-documented estate with few commercial extensions, this is an honest, workable path. For an estate with heavy commercial tooling and nobody who knows what half the channels do, the cheaper answer is often still to license and upgrade. We will tell you which one we think you are.
Where we come in
The inventory and compatibility review above are the Channel Estate and License-Exposure Assessment. The parity testing, cutover and rollback work is Upgrade or Fork Migration. We have no stake in either fork or in the commercial license.
Sources: the Open Integration Engine project announcement, April 2025, and the project's published release notes; NextGen Healthcare's March 2025 licensing announcement. Fork feature sets and release cadences change, so verify against current project documentation before planning a migration.
Chartferry is independent and is not affiliated with, endorsed by, or a reseller of NextGen Healthcare. Mirth Connect is a trademark of NextGen Healthcare, Inc.