How these projects fail

Eleven failure patterns account for most of what I have seen go wrong. Almost none of them is technical.

1. The method was chosen before the target design was. A team picks a migration method early — usually the one that moves data fastest, sometimes the one a vendor recommended — and then discovers the target design implies a different one. The method then constrains the design rather than serving it, and the platform arrives looking like the old one with a new logo. The business case said modernisation; the outcome is a lift.

2. Everything was migrated because nothing was assessed. Nobody was willing to own a retirement decision, so the default was to move it all. The project is then two to three times larger than it needed to be, and a large part of that effort goes into converting, validating and re-testing artefacts nobody reads.

3. The data workstream was planned and the consumption workstream was assumed. The data lands on time. Then the reports, feeds, semantic models and departmental tools take twice as long as anyone budgeted, because that work depends on business owners’ attention rather than engineering capacity, and business owners have day jobs.

4. Rehearsal proved the happy path. The rehearsal ran cleanly, timings looked acceptable, everyone was reassured. Nothing failed, so nobody found out that the restart procedure was untested, the runbook was wrong, or the recovery took four hours nobody had allowed for. The first real failure then happens at 2am inside the cutover window.

5. The project shape was chosen without looking at the architecture. A wave plan was applied to a layered platform that cannot be sliced vertically, and wave one’s presentation layer turned out to depend on integration tables owned by wave three. Or a big-bang plan was applied to a sprawling line-of-business estate that would have decomposed easily, taking on a blast radius nobody needed to accept. Both are the same mistake: deciding the shape from risk appetite rather than from the structure of the thing being moved.

6. The temporary component became permanent. A shortcut built to demonstrate early value acquired users, then downstream dependencies, then a support arrangement. Nobody would fund removing it because it worked. The organisation now runs a bypass around its own integration layer, indefinitely, and the architecture it migrated to is compromised in the same way the one it left was.

7. The programme was judged on the criterion it was best at. Acceptance was defined around something measurable and demonstrable — usually performance — while the real risk sat in scope, dependencies or the consumption layer, where nobody had a test. The chosen criterion was met comfortably and the programme failed on something it had never agreed to measure.

8. Divergence was treated as a defect list rather than a workstream. The platform went live, the numbers differed, and every difference was handled as an individual incident by a service team with no memory of why the old logic worked the way it did. Confidence in the new platform never recovered, and in the worst cases the organisation quietly went on reconciling against a system it had paid to replace.

9. The migration was built from runs rather than modules. A long single-unit load failed at some late percentage, for a different reason each time, and every failure returned the project to where it started. Progress was not slow so much as periodically undone, and the team could never say with confidence how much was actually finished.

10. The abort point was negotiable. A stop-or-continue milestone was agreed in advance, missed on the night, and then argued away by a team that was invested, exhausted and confident of catching up. The window closed with the migration incomplete and no time left to rewind, and the business opened on a broken platform.

11. The rollback boundary was theoretical. The plan said rollback was available. In practice the target had taken writes, two downstream systems had switched, and the source had drifted. The decision to continue was never made — it just became impossible to do anything else. Every subsequent problem was then handled under pressure with no fallback.

A common thread runs through all of them: each is a governance failure that presents as a technical surprise. The technical work on these migrations is, by and large, well understood. The scoping, ownership and decision discipline around it is what varies between the projects that land and the ones that do not.