Why does the big-bang EHR cutover keep failing?
A big-bang cutover has one property that makes it dangerous, and it has nothing to do with the software: everything changes at the same time.
On a typical acute estate, the EHR or PAS is not one system. It's the source of truth for admissions, discharges and transfers that a dozen or more downstream systems consume. Pathology, radiology, pharmacy, theatres, bed management, the data warehouse, e-Referrals, the discharge letter generator. Each of those has an interface, and each interface encodes assumptions about the legacy system: field lengths, code lists, message timing, how a patient merge is expressed.
When you cut over in a single window, every one of those interfaces changes on the same night. If pathology results stop landing at 03:00, you cannot tell whether the problem is the new EHR, the interface, the downstream system, or a mapping rule nobody documented. There is nothing to isolate. Rollback means rolling back everything, including the clinical data entered since the switch.
This is why the failure mode is so consistent. It's not that teams plan badly. It's that the architecture gives them no way to fail small. The same constraint shows up in older middleware, which we covered in why legacy integration engines cannot handle modern healthcare workflows.
What does a phased migration actually look like?
The alternative is to stop treating the migration as one event and treat it as a sequence of feed-level switches, each of which can be validated and reversed on its own. Outside healthcare this is usually called the strangler fig pattern: the new system grows around the old one until the old one carries nothing.
In practice that means four stages, run per interface rather than per system:
Stage 1: Mirror. The legacy system stays the source of truth. The new EHR receives a copy of the relevant traffic through an integration layer, but nothing downstream reads from it yet. You're populating the new system and finding out where the data doesn't fit.
Stage 2: Parallel run. Both systems receive the feed. The integration layer produces output from each and reconciles them. Downstream systems still consume only the legacy output. Discrepancies are logged, categorised and fixed. This stage runs until the reconciliation meets the exit criteria you defined before you started.
Stage 3: Switch. For that feed only, downstream systems begin consuming output derived from the new EHR. The legacy output is still generated and reconciled against it, but no longer routed. If the switch causes a problem, you route back to legacy for that feed. Nothing else is affected.
Stage 4: Retire. Once a feed has run on the new source for the agreed soak period, the legacy output for that feed is switched off. The legacy system retires one interface at a time until nothing depends on it.
The department or clinical area is not the unit of migration. The feed is. That distinction is what makes the pattern safe.
Where does the integration layer sit?
None of this works if downstream systems are wired directly to the legacy EHR, because there's nowhere to do the mirroring, reconciliation or routing.
The integration layer sits between the systems of record and everything that consumes them. The legacy system speaks whatever it speaks, usually HL7 v2 over MLLP, sometimes a scheduled file drop. The new EHR speaks something more modern, typically FHIR. Downstream systems expect what they've always received. If those standards are unfamiliar, NHS integration standards, mapped covers how they relate.
The layer's job is to normalise both sources to a single canonical representation, then produce the outputs each downstream system expects from that canonical form: one contract per system, with the transformation logic held in the middle rather than baked into each pairwise interface. That is the defining property of the category, which we set out in what a healthcare integration platform actually is.
The consequence for migration is that downstream systems don't know which source produced the message they received. That's the property you need. It's what lets you switch a feed's source without touching the consumer.
How do you validate a feed before you switch it?
Parallel running only works if you define, in advance, what "good enough to switch" means for each feed. Otherwise the parallel run becomes an open-ended comfort exercise and the programme drifts.
For each feed, write down:
- The reconciliation method. Message-count parity is the floor. Field-level comparison on the fields the downstream system actually uses is the real test. If the downstream system only reads the NHS number, date of birth and admitting consultant, reconcile those and don't drown in the rest.
- The tolerance. Zero discrepancies is rarely achievable and rarely necessary. Agree what categories of discrepancy are acceptable, such as a formatting difference in a free-text field, and which are blockers, such as a mismatched identifier.
- The soak period. How long the parallel run must stay within tolerance before you switch. Long enough to cover the feed's natural cycles: a weekly batch needs at least two clean cycles, a real-time ADT feed needs to cover a weekend and a bank holiday.
- The rollback trigger and owner. Who decides to route back to legacy, on what evidence, and how quickly it can be done.
Clinical safety review belongs here too, not at the end. The person accountable for clinical safety should be signing off the exit criteria for each feed, because those criteria are where the risk is actually being accepted. In an NHS context that work sits under DCB0129 and DCB0160.
What goes wrong in practice?
Three problems account for most of the difficulty. None of them are about which EHR you bought.
Patient identity. The legacy system and the new one will not agree on who every patient is. Merged records, historic duplicates, patients registered before NHS number was mandatory, temporary identifiers that were never resolved. The parallel run surfaces all of it. Decide early whether identity resolution happens in the integration layer or in the new EHR, and don't let it happen in both.
Terminology drift. Local code lists accumulate. The legacy system's ward codes, specialty codes and result codes will have drifted from whatever national standard they were once mapped to. The new EHR will expect the standard, typically SNOMED CT. The gap between them is a mapping exercise that has to be owned by someone with clinical coding knowledge, not left to the integration team to guess at. We cover the underlying model in SNOMED CT explained.
Timing semantics. Legacy feeds are often batch, or event-driven with implicit ordering. A modern EHR may emit events in a different order, or emit events the legacy system never generated. A downstream system that assumes "discharge always follows admission in the same message stream" will break when that assumption is no longer true. This is the least visible problem and the one most likely to surface in production.
There's a fourth problem that isn't technical: ownership. Every feed needs someone who can say what the downstream system actually needs from it. If that person left three years ago, finding out is part of the migration.
Where WeHub Studio fits
WeHub Studio is built for exactly the middle layer this pattern needs. Its processors handle HL7 v2 and FHIR natively, so a legacy feed and a modern one can be normalised to the same canonical form without custom code for each. Routing is configuration, which means switching a feed's source is a change you make and can reverse, not a release you deploy. And every message that passes through is logged in a form that makes reconciliation a query rather than a forensic exercise.
None of that replaces the work described above. It removes the part of the work that was never really about your Trust. If you are still choosing a layer, point-to-point integrations vs an orchestration layer compares the options, and decommissioning a legacy interface engine covers what happens to the middleware you already have.
