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.
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.
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.
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.
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. 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 →
