Before you start: the two questions that decide the timeline
Two things determine how long this takes, and neither is technical.
Does a reliable interface inventory exist? Not a list of interfaces the engine has configured, which is easy to export. A list of what each one is for, who consumes it, and what happens clinically or operationally if it stops. If that document doesn't exist, building it is the first phase of the project and it will take longer than the migration itself.
Can you run both engines at once? Most organisations can, but licensing, network position or message-source constraints sometimes prevent it. If parallel running is impossible, the risk profile changes entirely and the approach below needs adapting with your clinical safety officer before you start, under DCB0160.
The ten-step checklist
- Export the engine configuration, then verify it against reality. Take the full configuration export as a starting point, not as the truth. Compare it against actual message traffic over a representative period. Configurations accumulate routes that no longer fire and lose routes that were added outside the normal process. You are looking for both.
- Identify the consumer and the clinical impact for each feed. For every live route, name the receiving system, the team that owns it, and what they would notice if the feed stopped. "Nobody would notice" is a valid and useful answer that means the feed is a decommissioning candidate rather than a migration candidate.
- Classify feeds by risk, not by volume. A low-volume feed carrying pathology results is higher risk than a high-volume feed populating a reporting extract. Rank by clinical consequence of failure and by how quickly a failure would be noticed. Feeds that fail silently belong at the top of the attention list regardless of volume. If you are unsure which national services a feed touches, NHS Spine explained covers what sits behind each one.
- Agree exit criteria per feed before any migration work starts. Reconciliation method, acceptable discrepancy categories, soak period, rollback trigger and the named person who can call it. This is the same discipline set out in legacy EHR migration without a big-bang cutover, and skipping it is what turns a parallel run into an indefinite one.
- Stand up the new layer in receive-only mode. The new engine receives a copy of live traffic and produces output, but nothing downstream is routed to it. This surfaces format, encoding and volume problems before they can affect anyone. Pay particular attention to HL7 v2 encoding and segment-level differences between the two engines.
- Parallel run one feed, reconcile, and hold. Start with a feed that is moderate risk and well understood, not the easiest one. The easiest feed teaches you nothing about the problems you'll hit later. Reconcile against the exit criteria and stay in parallel until they're met.
- Switch that feed's downstream consumer to the new layer. One feed, one consumer, with the old route left configured and ready to re-enable. Watch it through at least one full business cycle before moving to the next.
- Repeat, batching only feeds that share a consumer. Feeds to the same downstream system can reasonably move together, because the rollback route is the same. Feeds to different consumers should not be batched, however similar they look, because a shared switch removes the isolation the whole approach depends on.
- Leave the old engine running and empty. Once the last feed has moved, the old engine keeps running with no traffic routed to it for a defined period. It is your rollback path and, more usefully, your evidence: anything still arriving at it is a source you did not know about.
- Shut down, retaining configuration and logs. Archive the configuration export and message logs before decommissioning, to the retention period set out in the Records Management Code of Practice and your local information governance policy. Interface behaviour questions surface months later and the archived configuration is often the only remaining record of how something used to work.
The three steps people skip
Three items in that list get dropped under time pressure, consistently.
Step 2, consumer identification. It's tedious, it requires chasing people, and the engine configuration looks like it already answers the question. It doesn't. The configuration says where a message goes; it doesn't say whether anyone reads it or what they do with it. Skipping this is how a reporting feed that fed a regulatory submission gets migrated with the wrong field mapping and isn't noticed until the submission fails.
Step 6, starting with a moderate feed rather than the easiest one. Teams naturally pick the simplest feed first to build confidence. The result is a first migration that surfaces none of the real problems, and false confidence going into the second. Pick something representative.
Step 9, the empty running period. This is the one that causes actual incidents. The old engine gets shut down as soon as the last known feed moves, and three weeks later a quarterly batch fires from a source nobody inventoried. Leaving it running and empty converts that from an incident into a log entry.
What to do when the inventory is wrong
Assume it will be. The question is what you do at the moment you discover it.
When a feed appears that isn't in the inventory, stop migrating and add it properly: consumer, owner, clinical impact, exit criteria. The temptation is to treat it as a small addition and migrate it alongside whatever you were working on, which reintroduces exactly the undocumented dependency you're trying to eliminate.
Two or three surprises are normal in a mature estate. A steady stream of them means the inventory phase wasn't finished, and continuing to migrate against a known-bad inventory is how these projects end up costing more than the replacement they were meant to enable. Before committing to a target, it is worth being clear about what you are moving to: why legacy integration engines cannot handle modern healthcare workflows and point-to-point integrations vs an orchestration layer both cover the difference between replacing an engine and changing architecture.
