Migrating from a legacy interface engine
Whatever you run today — Mirth Connect, Corepoint, Rhapsody, or another engine — moving to MessageFoundry is a staged, reversible process, not a big-bang rewrite. You re-express your interfaces as plain Python, validate them against live traffic, and cut over one at a time with a rollback path the whole way.
Migrations fail when they're all-or-nothing. This playbook is vendor-neutral and incremental: prove one interface, then the next, keeping the old engine running until each is trusted. MessageFoundry is a new, Early Access project — start with a sandbox install, and read where the project stands before you plan a cutover.
1. Inventory your interfaces
Catalog every channel before touching anything: its inbound and outbound connections, its routing and transforms, its filters, and its volumes. The inventory makes the scope explicit and surfaces the handful of interfaces that carry most of the risk.
2. Re-express each interface as Python
Map each channel to MessageFoundry's building blocks — Connections in and out, a Router, and Handlers — as plain Python in a config repository. The result is version-controlled and diffable, and AI-assisted migration can draft the Python from your existing channel logic to speed the work.
3. Validate and shadow
Validate the config with the commit gate (python -m messagefoundry check), then run the new interface in parallel against live traffic — shadowing the legacy engine — and compare outputs until they match. Nothing routes to production until you've seen it behave.
4. Cut over with rollback
Move traffic over in stages behind go/no-go gates, one interface at a time, keeping the legacy engine as a fallback until each is trusted. The Adoption & rollout guide lays out the staged plan; the Migration guide covers the interface-by-interface mechanics.
Why teams move off legacy engines. Interface-engine costs climb as budgets tighten, and channel-based config is hard to review and test. MessageFoundry is open-source and self-hosted, with no per-interface licensing — and interfaces become ordinary Python you can diff, test, and own. See the comparison →
Related guides
Frequently asked questions
Can I migrate to MessageFoundry from Mirth Connect, Corepoint, or Rhapsody?
Yes. MessageFoundry is a destination for moving healthcare interfaces off a legacy interface engine, whichever one you run today. You re-express each channel — its connections, routing, and transforms — as plain Python config, and migrate interface by interface rather than all at once.
Will I have to rewrite my interfaces?
Your interfaces are re-expressed as Python Connections, Routers, and Handlers — which makes them version-controlled, diffable, and unit-testable. AI-assisted migration can draft the Python from your existing channel logic to speed the work.
How do I de-risk the cutover?
Validate the config with the commit gate, run the new interface in parallel (shadow) against live traffic to compare outputs, then cut over in stages behind go/no-go gates — keeping the legacy engine as a fallback until you're confident.
Can I migrate from Infor Cloverleaf?
Yes. Cloverleaf interfaces are scripted in Tcl; with MessageFoundry you re-express them as plain Python — a far larger talent pool — and migrate interface by interface, validating each against live traffic before cutting over. There is no enterprise licensing or lock-in on the destination.
Can I migrate from InterSystems Ensemble or Health Connect?
Yes. With Ensemble reaching end-of-maintenance around Q1 2027 you face a migration regardless — so move the integration function to an open, Python engine on standard databases rather than deeper into ObjectScript and a proprietary IRIS database. You migrate in stages with the legacy engine as a fallback.