Mirth Connect migration services
Move from Mirth Connect without rebuilding every interface
Give us your channel exports and representative messages. Our established conversion process creates Integration Soup workflows, translates custom logic, and keeps the shape of each interface familiar to the people who support it.
- Converter-assisted first pass
- Recognisable workflow structure
- Tested before cutover
Converter-led, expert-guided
Start with what you have
We do not begin with a blank designer. We inventory your exported channels, code templates, configuration maps, global scripts, connectors, libraries, schedules, certificates, and sample messages. Our Mirth Connect converter then builds the first Integration Soup version for our specialists to review with you.
Where a channel uses JavaScript, we translate it into maintainable C# code activities and transformers. Function boundaries, variable names, and business rules stay recognisable wherever practical, so your team can follow the converted logic instead of learning an unrelated implementation.
A controlled migration
From exported channel to proven workflow
We can convert one representative channel first or plan an entire interface estate. Either way, every step produces something you can inspect and approve.
-
01
Discover and export
Collect channel XML, code templates, maps, libraries, connection details, dependencies, de-identified samples, volumes, and operational requirements.
-
02
Convert and review
Generate the receiver, ordered activities, filters, transformers, and C# translations. We flag anything that needs a deliberate design decision.
-
03
Replay and compare
Run representative and edge-case messages through both engines. Compare payloads, destinations, ACK behaviour, errors, and expected side effects.
-
04
Stage and cut over
Configure environments and secrets, run a pilot or parallel service, agree rollback steps, then move interfaces in manageable groups.
A familiar destination
How Mirth concepts map to Integration Soup
The platforms use different file formats and runtime APIs, but their interface-engine concepts line up well.
| Mirth Connect | Integration Soup | Migration approach |
|---|---|---|
| Source connector | Receiver | Transport, endpoint, message type, response, and processing settings are mapped into the workflow entry point. |
| Destination connectors | Ordered activities and senders | Destinations are created in channel order with their connection, retry, and routing intent retained. |
| Filters and transformers | Filters and transformers | Simple rules map directly; more involved logic becomes a code transformer. |
| JavaScript and code templates | C# code activities and transformers | Logic is translated while keeping functions, names, and control flow recognisable where practical. |
| Channel and configuration maps | Workflow variables and environment configuration | Values are separated by purpose and sensitive settings are prepared for the target environment. |
| Custom libraries and extensions | Built-in activities, Extension Libraries, or custom .NET | Each dependency is matched to an existing capability or given a focused replacement. |
Proof before production
Testing is part of the conversion
We define acceptance criteria with you, then produce evidence for each migrated interface. Your team can see what was tested, what matched, and what was intentionally changed.
Show us a Mirth channel- Structure: receiver, destinations, filters, dependencies, and configuration are accounted for.
- Message behaviour: outputs, field values, routing decisions, ACKs, and error paths are compared.
- Operational behaviour: throughput, retries, alerts, certificates, schedules, and restart behaviour are checked.
- Cutover readiness: owners, monitoring, fallback, and sign-off are documented before traffic moves.
Practical answers
Questions about moving from Mirth
We will happily guide your team through the technical and operational decisions.
Do we have to stop Mirth Connect during conversion?
No. The normal approach is to convert and test away from production, then pilot or run in parallel before a controlled cutover.
What should we provide for an assessment?
A channel or server export, shared code templates, a list of extensions and external libraries, environment dependencies, and representative de-identified messages are the most useful starting point.
What happens to complex JavaScript?
We translate it to C# using Integration Soup's message and workflow APIs. We keep the structure and naming familiar where practical, then test the translated behaviour against the source channel.
Can we start with one channel?
Yes. A representative channel is a useful way to demonstrate the process, identify organisation-specific patterns, and produce a reliable estimate for the remaining interfaces.
Bring us one channel
See what your Mirth migration could look like
Request a demo and tell us a little about your interface estate. We will get in touch to plan the right first step.