There is a planning technique from decision research called a pre-mortem. Before a project begins, the team assumes it has already failed, then works backwards to explain why. It surfaces risks that ordinary planning meetings suppress, because it is socially far easier to explain a failure than to predict one.
Healthcare has the largest worked example available. The VA's electronic health record modernisation programme has run years behind schedule, absorbed vastly more money than planned, paused and reset multiple times, and drawn repeated critical findings from the Government Accountability Office, including a 2026 report calling for urgent action to support accelerated deployments.
The instructive part is not the scale. It is that the failure modes are ordinary. Private health systems and health tech companies reproduce them at smaller scale with smaller budgets and far less room to recover from a pause.
So here is the pre-mortem. It is 2028. Your modernisation failed. This is the report.
1. You changed the system before you understood it
The single most common root cause, and it precedes every other item on this list.
Legacy systems carry decades of configuration, local customisation, and undocumented decisions. That configuration is not incidental to the system, it very often is the system. Teams that begin transforming code before producing a full dependency map, an interface inventory, and a record of what the business logic actually does are working from an incomplete specification and do not know it.
Early signal. Nobody can produce a list of every interface the system talks to. If that list does not exist in month two, it will not exist at go-live either.
2. The clinical intelligence never made it across
Order sets, decision support rules, and documentation templates that clinicians use daily turn out to have no equivalent in the replacement system. This is usually discovered mid-migration, at the point where the cost of discovering it is highest.
These artefacts represent years of accumulated clinical judgement. They were built incrementally, by people who have often left, and they are rarely documented anywhere except inside the system being retired.
Early signal. Your migration plan has a line item for data and no line item for clinical configuration.
3. Customisation debt broke on contact
Legacy healthcare systems accumulate custom workflows, local reports, and bespoke interfaces. Every one of them is a dependency. Modernisation breaks a fraction of them, and because they were local rather than vendor supported, nobody owns fixing them.
Early signal. When you ask which customisations are still in use, the answer is a shrug or a spreadsheet last edited three years ago.
4. Migration altered patient records
The most serious failure available in this category. Data migration errors that change clinical records are worse than downtime, because downtime is visible and corrupted data is not.
Format conversion, code set mapping, and field semantics that differ subtly between source and destination all introduce silent error. A field that means one thing in the old system and something adjacent in the new one produces records that are structurally valid and clinically wrong.
Early signal. Validation is planned as a phase after migration rather than as a gate at every stage.
5. Go-live was a date rather than a condition
The second most common failure point after migration itself. Go-live gets fixed as a calendar commitment, usually communicated upward early, and then defended past the point where the evidence supports it.
Big bang cutovers concentrate every unresolved risk into one weekend. Phased go-live is slower on paper and dramatically cheaper in practice, because failures arrive one at a time and remain recoverable.
Early signal. The go-live date has not moved despite the scope having changed twice.
6. Security ran after the migration instead of alongside it
Modernisation exposes the vulnerabilities that were hidden inside decaying infrastructure, and the transition window is exactly when both old and new systems are running, permissions are broad, and monitoring is incomplete.
There is a compliance dimension too. A gap in HIPAA safeguards during a migration is not a technical debt item to be cleaned up later. It is a violation, in a period when the organisation is least able to detect one.
Early signal. Security review is scheduled as a phase near the end. It should be a parallel track from week one.
7. Clinicians were told rather than asked
Clinical teams shaped by years of a legacy interface do not absorb sudden workflow change, and the ones who resist are frequently right, because they know things about the workflow that never made it into a requirements document.
Adoption failure looks like technical failure from the outside. The system works, and nobody uses it as designed, so the benefits case never materialises.
Early signal. The project has a communications plan and no clinical design partner. This is where UI and UX design earns its budget, well before launch.
8. It was run as an IT project
The underlying error behind most of the others. Legacy modernisation touches revenue cycle, clinical operations, staffing, and compliance. Run inside IT with an IT sponsor and an IT budget, it lacks the authority to make the operational decisions the work actually requires.
Early signal. The steering group has no operational or clinical leadership on it with the power to say no.
What the version that worked did differently
The successful projects share a shape, and it is less dramatic than the failed ones.
They inventoried first. Dependency map, interface inventory with behaviour documented for every connection, and clinical configuration catalogued before any decision about approach.
They rarely replaced everything. Full replacement is the highest risk path available and is justified far less often than it is chosen. The common alternative is the strangler fig pattern, where new functionality is built alongside the old system and traffic moves across incrementally until the legacy component can be retired. Slower, and survivable.
They modernised around the record system rather than through it. Where the constraint is that data cannot get out or new services cannot get in, an integration and API layer solves the actual problem at a fraction of the risk. This is often the honest answer, and it is the work Woltrio does most, through backend development, cloud engineering, and where it touches the record layer directly, custom EMR and EHR development.
They validated continuously. Parity checks at every stage rather than one reconciliation at the end.
When replacement genuinely is the answer
Modernising around a system is not always available. Replacement earns its risk when several of these hold at once: the vendor no longer supports your version, the system cannot expose FHIR R4 APIs and regulatory requirements now demand it, there is no cloud path, and the maintenance burden has grown large enough that continuing costs more than moving.
That last one is the decisive test, and it is arithmetic rather than judgement. When maintaining the existing system consumes the majority of the budget available, the status quo has stopped being the cautious option.
Even then, the sequence from the pre-mortem still applies. Understand, then inventory, then phase. The VA's programme did not fail because modernisation is impossible. It failed because the steps ran out of order.
Where Woltrio fits
Woltrio's healthcare legacy system modernization work usually starts with the assessment rather than the build, because the assessment frequently changes the recommendation.
A meaningful share of the time the answer is that the system does not need replacing, it needs an integration layer, an API surface, and a plan for the three components that actually hurt. That is a smaller engagement than most clients arrive expecting, and it is the one with a realistic chance of finishing.
Where a build is genuinely warranted, the same discipline applies: inventory before transformation, parity validation as a gate rather than a phase, phased cutover, and security running in parallel from the first week. Where scope is uncertain, a scoped MVP against a single component proves the approach before the organisation commits to all of it.
Start with a scoped assessment from Woltrio.
