advanced 2 min answer

Most large modernisation programmes are late, over budget, or abandoned. What are the recurring structural causes, rather than the project-management ones?

modernisationsecond-systemcoexistencescopeoraclefailure-analysis
Show the full answer Hide the answer

The recurring structural causes

1. The second-system effect. The replacement is scoped to fix everything the old system did badly and to unify processes that diverged over twenty years and to introduce a canonical data model and to move to a new integration platform. Each is defensible alone. Together they mean nothing can be delivered until everything is delivered, and the old system must be kept alive and changing throughout.

2. Perpetual coexistence. Some slices migrate, some do not, and the organisation ends up operating both systems permanently with a synchronisation layer as a standing tax. This is the most common outcome and it destroys the business case entirely — the programme delivered work and no benefit.

3. Undocumented behaviour discovered late. Odd behaviours in the old system that look like defects turn out to be undocumented handling of real edge cases. Every one found after cutover is an incident; every one found before is a requirement nobody knew about.

4. No business sponsor per slice. A technical programme with a technical sponsor loses priority whenever anything else is urgent, and modernisation is never the most urgent thing in any given week.

5. The data problem underestimated. Traffic routing is straightforward; deciding which system owns which entity during a multi-year transition, keeping both correct, and reconciling drift is where these programmes actually consume their time.

What changes the odds

  • Strangler-style incremental replacement, with a slice in production early. Nothing disciplines scope like real traffic.
  • An explicit non-goals section, reviewed as seriously as the goals.
  • Traffic shadowing before switching, which finds behavioural differences no test suite will.
  • Migrating ownership per entity, deliberately, so there is a defined end state rather than indefinite dual-write.
  • Decommissioning as a dated, owned deliverable per slice. A slice is not migrated until the old path is switched off.
  • A business sponsor and a benefit per slice, so each has a reason to be prioritised.

The framing that matters

A modernisation programme's risk is concentrated in scope and in data, not in technology. The technology is usually the easy part, which is why programmes staffed entirely with technologists and scoped by ambition fail so consistently.