Strangler Fig Migration: Moving Off Rhapsody Without Downtime

Most integration engine migrations fail before they start. The plan usually looks like this: spend three months rebuilding 50+ interfaces in the new engine, pick a weekend, flip the switch, hope nothing breaks. When something does break (and it will), you flip everything back and start over.

This is called big-bang migration. It doesn't work. Here's what does.

The Big-Bang Problem

Big-bang migrations fail for predictable reasons.

First, you can't test 50 interfaces in a weekend. Each one connects to a different healthcare organization with its own HL7v2 dialect. One hospital puts patient race in PID-10, another uses PID-22, a third uses both fields depending on which EMR system generated the message. You won't discover these quirks until real traffic hits production.

Second, rollback is as risky as the cutover. You've spent three months building parallel infrastructure. Now you're switching back to the old engine, which hasn't processed live traffic in days. Did you remember to sync the database? Are the VPN tunnels still configured correctly? Your team is exhausted, it's 2 AM, and you're making decisions about which version of broken to run.

Third, the timeline always slips. Month one is fine. Month two, the team realizes half the channels have undocumented transformations that only work because someone added a custom Java class five years ago. By month three, morale is shot and you're debating whether to push the go-live date or cut scope.

We've seen this pattern repeat across a dozen healthcare organizations. The ones that succeed don't do big-bang migrations. They use the strangler fig pattern.

The Strangler Fig Pattern

The strangler fig is a tree that grows around a host tree. It starts as a seed in the canopy, sends roots down to the ground, and gradually envelops the host. Eventually the host tree dies and the fig stands alone. The host tree stays functional the entire time.

In software, the strangler fig pattern means wrapping the old system with the new one, migrating one piece at a time, and keeping the old system as the rollback until you're done.

For healthcare integration engines, it works like this:

Step 1: Put the new engine in front of the old one. Install MedHook and configure it to pass every message through to Rhapsody unchanged. Nothing breaks because nothing changes. You're just adding a layer.

Step 2: Move one interface at a time. Pick an interface, rebuild it in MedHook, and run both engines in parallel. Compare the outputs field by field until they match. When you're satisfied, route traffic through MedHook. Keep the Rhapsody route as a backup.

Step 3: When the last interface moves, retire the old engine. Until then, any interface can be routed back to Rhapsody with a single configuration change. No separate rollback plan needed because the old engine is always the rollback.

The key insight is that you never commit to the new engine until it's proven with production traffic. Each interface is a small bet, not an all-or-nothing decision.

How This Works with MedHook

MedHook is designed to sit as a front door for all inbound HL7v2 traffic. Every message hits MedHook first. What happens next depends on whether that interface has been migrated.

For interfaces not yet migrated, MedHook acts as a passthrough. The message arrives, MedHook logs it, and forwards it to Rhapsody unchanged. Rhapsody processes it exactly as it did before MedHook was installed. The healthcare organization on the other end sees no difference.

For migrated interfaces, MedHook processes the message through its own workflow engine. It validates the message structure, runs any transformations, routes it to the destination system, and handles the acknowledgment. Rhapsody never sees it.

During migration, both engines run in parallel. MedHook processes the message and sends the output to a comparison queue. Rhapsody processes the same message and sends its output to the same queue. A comparison script runs every hour and checks for differences.

The comparison is field-level. Not just "do the outputs match," but "which fields are different and by how much." Did Rhapsody normalize a phone number that MedHook left raw? Did MedHook drop a trailing space that Rhapsody preserved? These details matter because downstream systems are fragile.

Match rate is the gate. You define what percentage of messages must match before cutover. Most organizations start at 98%, then tighten to 99.5% after the first few interfaces. If match rate drops below the threshold, the cutover doesn't happen.

This parallel run can last a day or a month. It depends on message volume. A high-volume ADT feed might hit the threshold in 24 hours. A low-volume lab results feed might take two weeks. Either way, you don't cut over until the data proves it's safe.

The Migration Timeline

Here's what the timeline looked like for CareMessage, a patient engagement platform that routes messages between healthcare organizations.

Weeks 1-8: Technical discovery and MedHook install. Map every Rhapsody channel, tunnel, and endpoint. Document the undocumented. Install MedHook as a passthrough and verify nothing changes. Pick the first interface to migrate. Usually something low-risk like a lab results feed with good documentation. Build it in MedHook, run the parallel comparison, cut over when outputs match. This first interface takes the longest because you're learning the pattern.

Weeks 9-14: Pilot at 1-3 interfaces per week, then ramp to 3 per week. By week 14, 14 interfaces are live. The team is comfortable with the workflow. Each interface follows three gates: parallel run to match rate, off-hours cutover, 48-hour hypercare period where the team watches for anomalies. The Rhapsody route stays configured as a rollback for the first month.

Weeks 15-23: Ramp to 5 interfaces per week. The team knows the failure modes now. Most interfaces cut over smoothly. A few require custom transformations that weren't documented in Rhapsody. By week 23, 55+ interfaces are live.

Each interface follows the same pattern. Build in MedHook, run parallel until outputs match, cut over during an off-peak window, monitor for 48 hours, mark as stable. If anything goes wrong, route traffic back to Rhapsody and figure out what broke.

The math is straightforward. If you have 60 interfaces and you're migrating 5 per week, that's 12 weeks. Add eight weeks for setup and pilot. Call it 20 weeks start to finish.

Compare that to the big-bang approach where you spend 12 weeks rebuilding everything, then spend another 12 weeks fixing what broke after the cutover. The strangler fig approach is faster and lower risk.

VPN Tunnel Management

One detail that most migration guides skip: how do you manage VPN tunnels for 50+ healthcare organizations?

Each healthcare organization requires an IPsec VPN tunnel. The tunnel connects their network to yours. HL7v2 messages travel over the tunnel using MLLP (Minimal Lower Layer Protocol). You can't migrate the interface without migrating the tunnel.

MedHook manages tunnels from the UI. You create a tunnel by entering the healthcare organization's peer IP address, pre-shared key, and routing information. MedHook generates the configuration, monitors tunnel health, and handles automatic failover if a tunnel goes down.

When you migrate an interface, you also migrate its tunnel. MedHook creates a new tunnel to the healthcare organization's network. You provide them with a handoff packet containing peer configurations but no keys on screen (security teams appreciate this). Their network team configures their side of the tunnel. You test connectivity. When the tunnel is stable, you migrate the interfaces that depend on it.

The tunnel and its interfaces move together. If you need to roll back an interface, you route traffic back through the Rhapsody tunnel. Both tunnels stay active during the migration period. Once all interfaces for a given healthcare organization have migrated, you can decommission the Rhapsody tunnel.

The Escape Hatch

Here's the part where we tell you something most vendors won't: you can leave.

Any MedHook workflow exports to Mirth Connect XML. That means if you decide six months in that MedHook isn't the right fit, you're not locked in. Export your workflows, import them into Mirth Connect, and run Mirth side by side with MedHook during the transition.

We built this escape hatch because we've seen too many healthcare organizations stuck with integration engines they hate. The switching cost is too high, so they stay with a platform that's bleeding them dry. We don't want to be that vendor.

The export isn't perfect. Mirth and MedHook have different workflow engines, so some transformations require manual adjustment. But the structure, endpoints, and business logic are all there. You're not starting from scratch.

This also means you can run MedHook and Mirth side by side if that's your preference. Some organizations like having two engines for redundancy. Others want the option to compare performance and cost before fully committing. Either way, the architecture supports it.

For more on the cost implications of self-hosted versus managed integration, see our breakdown of TCO across different deployment models.

What Happens After Migration

Once the last interface migrates, you switch off Rhapsody. The team now runs MedHook for all integration traffic. Here's what ongoing support looks like.

Annual support and licensing at a flat rate. No per-message fees, no surprise charges when message volume doubles. You pay for the infrastructure and access to the engineering team.

Releases come as versioned bundles, installed during off-peak windows. We don't push updates without coordination. You schedule the maintenance window, we provide the release notes and rollback plan, you approve the install.

We don't have standing access to your production environment. Break-glass access only, and only when you grant it. Most of the time, our support team works from logs and metrics you share. If we need to dig deeper, you open a secure tunnel for the duration of the investigation, then close it when we're done.

The goal is to hand off operational control as quickly as possible. Some organizations want white-glove support for the first year. Others want a quick handoff after the first month. Both models work.

Comparing Migration Approaches

If you're evaluating alternatives to Rhapsody or Mirth Connect, the strangler fig approach applies regardless of which engine you pick. The pattern works with any integration platform that can sit in front of your existing infrastructure.

For a detailed comparison of how MedHook stacks up against Rhapsody and Mirth Connect, see our feature breakdowns. The short version: MedHook is faster to deploy, easier to manage, and costs less to operate. But the strangler fig migration approach is the same whether you're moving to MedHook, Mirth, or something else.

Getting Started

If you're running Rhapsody or Mirth Connect and considering alternatives, the first step is to map what you have. How many interfaces? What message types? Which healthcare organizations? What are the current failure modes?

We'll walk through your specific channels and volumes. We'll show you what the timeline looks like for your setup. We'll discuss match rate thresholds and rollback procedures. And we'll be honest about whether the strangler fig approach makes sense for your situation.

Some organizations are better off staying with their current engine. If you only have 10 interfaces and they're stable, the migration might not be worth it. If you have 100 interfaces and you're adding 20 more this year, the strangler fig approach can save you months of work and a lot of risk.

Talk to us about your specific integration challenges, or read more about MedHook to see how it handles complex healthcare workflows.

The strangler fig pattern works because it eliminates the big-bang risk. You migrate one interface at a time, with rollback at every step. The old engine stays live until you're ready to retire it. And when you're done, you have a proven system running production traffic, not a rebuilt system that you're hoping works.

That's the difference between a migration that succeeds and one that gets rolled back at 3 AM on a Sunday.