Most conversations about EUC migration risk focus on assets that block a migration outright — the spreadsheet nobody understands, discovered mid-programme, causing delay. This brief is about a quieter, less-discussed cousin of that problem: the EUC that never gets blocked, never gets escalated, and never gets migrated at all. It just keeps running, in parallel with the new platform, because migrating it was harder than leaving it alone.
These assets are more dangerous than the ones that cause visible delays, precisely because they don't cause visible delays. The migration programme closes successfully. The steering committee signs off. Everyone moves on to the next priority. The spreadsheet, meanwhile, is still there — still feeding whatever it always fed, now completely outside anyone's active awareness.
A migration that "succeeds" on paper can still leave a real, unmanaged risk running quietly in the background.
Why migration failure isn't the real risk here
Data migration has a well-documented failure problem. Bloor Research's 2011 follow-up survey — one of the more rigorous, named studies on the topic — found that 38.3% of data migration projects overran their budget or timeline, or were aborted outright, with an average overrun cost of $268,000. Bloor's earlier 2007 survey put the figure at 84% of projects overrunning, running over budget, or being aborted outright — meaning the 2011 figures, stark as they are, actually represent a real improvement.
Those numbers describe migrations that visibly go wrong. But the asset this brief is concerned with belongs to a different category entirely: the migration that is declared a success, while one or two legacy tools are quietly excluded from that success — not through negligence exactly, but through a series of individually reasonable decisions that add up to something nobody actually chose.
"Nobody decides to leave an EUC behind. It happens through a series of small, reasonable trade-offs that nobody adds up until much later."
Five ways an EUC survives its own migration
In our experience, legacy EUCs don't survive a migration by accident. They survive through one of a small number of recognisable patterns — each individually understandable, none of them intended to create lasting risk.
Each of these is individually minor. Together, they explain how a well-run migration programme can close successfully while still leaving a genuine, ungoverned risk quietly operating in its shadow.
SS1/23's first principle requires firms to identify and classify all models — including EUCs — as part of an ongoing model inventory, not a one-time exercise tied to a specific programme's timeline. An asset left behind after a migration programme closes doesn't stop being a model in scope; it simply stops being tracked as one, because the inventory process that would have caught it was tied to a project that has since ended.
The same applies under BCBS 239: a leftover EUC that still feeds a regulatory return breaks data lineage in exactly the same way an unmigrated asset would — the only difference is that everyone involved believes the migration is finished, which makes the gap harder to find, not less real.
Closing the gap a "complete" migration leaves open.
A Greywood Analytics deconstruction engagement is equally suited to assets discovered mid-migration and assets discovered after a migration has already closed. For each asset in scope, we deliver:
- Plain English Summary — what the asset still does, and why it's still running after the programme it belonged to has closed.
- Dependency Map — every input and output the asset still touches, including any connections to the new platform it was meant to be replaced by.
- Dependency Mapping Narrative — the specific reason the asset survived migration, documented so the decision is finally visible rather than accidental.
- Risk & Assumption Narrative — a clear assessment of what depends on this asset today, and what the actual cost of finally decommissioning or documenting it looks like.
- Risk Register — the asset formally re-entered into active risk tracking, closing the audit blind spot directly.
A migration programme that closes on paper shouldn't mean a governance gap stays open in practice.
First deliverable pack typically received within 2–3 working days of engagement start.
The question worth asking after "migration complete"
If your organisation completed a system migration in the last few years, it's worth asking a simple question: does anyone currently own the legacy tools that didn't quite make the cut? Not "were they migrated" — but "did anyone actually decide what would happen to the ones that weren't."
For most organisations, the honest answer is that nobody made that decision. It simply happened, one deferred phase-2 item and one disbanded project team at a time.
"A migration programme can close successfully and still leave something running that nobody would sign their name to today."Greywood Analytics
If a recent migration programme left one or two legacy tools quietly running in parallel, we should have a conversation. Every engagement begins with a no-commitment scoping discussion.
Start a Conversation