A Migration Project Is an Operating-Model Audit in Disguise

You scoped it as moving data from one system to another. What it actually does is expose every undocumented workaround, ownership gap and hidden assumption your firm runs on.

You scoped it as moving data from one system to another. What it actually does is expose every undocumented workaround, ownership gap and hidden assumption your firm runs on.

You budgeted for a data migration: extract, transform, load. What you got was a forensic audit of how your firm really operates — the workarounds, the orphaned records, the ownership nobody claims — and it arrived without warning, halfway through.

A migration is sold, scoped and funded as a technical task: move the data from the old system to the new one. That framing is almost always wrong, and the wrongness is expensive. What a migration actually does is force every piece of the firm's operating model into the light at once. It exposes the undocumented relationships, the free-text workarounds, the records that were quietly decoupled years ago, the dependencies nobody wrote down, and the ownership gaps that business-as-usual politely conceals.

A migration is not a file transfer. It is an operating-model audit that happens to be triggered by a change of system — and firms that scope it as the former are repeatedly ambushed by the latter.

BAU hides what a migration reveals

The reason a migration surprises people is that day-to-day operations are extraordinarily good at hiding their own imperfections. A process that depends on one person knowing that a particular field is unreliable, or that two records are really the same client, or that a workaround exists for a case the system never handled — that process runs perfectly well, every day, because the knowledge is carried in people's heads. Nothing forces it to be written down. Nothing tests whether the data actually supports what everyone assumes it supports.

The pattern I return to is that a migration is the first event in years that interrogates every one of those assumptions simultaneously. The moment you try to extract the data and reload it somewhere else, the tacit knowledge that held everything together is stripped away, and the gaps become undeniable. Records that were decoupled turn out not to link. Notes captured as free text turn out not to map to any field. Documents turn out to be attached in a way that does not survive the move. None of this was a secret. It was simply never tested — until the migration tested all of it at once.

A migration does not create these problems. It reveals them. The firm was always running on them; it just never had to look.

What a migration actually surfaces

The findings of a migration are remarkably consistent across firms, because they are findings about how operating models decay rather than about any particular system. Table 1 sets out what a migration reliably exposes, and what each finding really tells you about the firm.

Table 1 — What a migration surfaces: reading the findings as an operating-model audit

Scope it as discovery and redesign, not transfer

If a migration is really an operating-model audit, then scoping it as a file transfer guarantees a budget and timeline that cannot absorb what the migration finds. The predictable result is a project that appears to be running smoothly until the discovery phase hits, at which point every week produces a new structural surprise and the plan disintegrates — not because the team is weak, but because the plan was built for the wrong activity.

The correction is to scope the migration as two-thirds discovery and redesign and one-third transfer, and to fund it accordingly. That means explicit, protected time and budget for process discovery — finding the workarounds, mapping the relationships, resolving the ownership gaps — and for remediation, before any data moves in anger. It also means setting the leadership's expectation up front that the migration will surface operating-model debt, and that surfacing it is a benefit, not a failure. A migration that finds nothing has almost certainly not looked.

This reframing also changes who should be in the room. A migration scoped as a file transfer is run by technologists and project managers, because moving data looks like a technical task. A migration scoped as an operating-model audit needs the people who actually run the processes — the ones who carry the tacit knowledge the system never captured — because they are the only ones who can tell you which records are really the same client, which workaround exists for which exception, and which field everyone has quietly stopped trusting. The single most expensive mistake I see is a migration staffed entirely by people who can move the data but cannot interpret it. The data moves; the meaning is lost; and the firm discovers, months later, that it migrated its problems faithfully into a more expensive system.

This is exactly how AI transformation fails

The reason this belongs in a discussion of AI is that AI transformation fails in precisely the same way, for precisely the same reason. Automating a process means encoding the process as it is documented — and a migration proves that the documented process is not the real one. The real process is riddled with exceptions, workarounds and tacit corrections that a human operator applies without thinking. Automate the documented version and you scale the assumptions embedded in it, exceptions and all, faster than any human process ever could.

A migration is therefore the cheapest possible preview of an AI transformation's risk. It shows you, before you have automated anything, exactly where your operating model diverges from its own documentation — which is exactly where automation will break or, worse, silently do the wrong thing at scale. A firm that has run a genuine migration audit knows where its exceptions live. A firm that has not is about to discover them the expensive way, with an agent instead of a data-extraction script. Treat the migration as the operating-model audit it already is, and you have done the discovery your AI programme was going to force on you anyway.

The next time you scope a migration as extract-transform-load, ask yourself: are you moving data — or are you about to run the operating-model audit your firm has been avoiding, whether or not you planned for it?

Next: the technical minimum for senior operators — The COO Doesn't Need to Code. But They Need to Understand What Code Changes.

Sources: JFSC, Guidance on the use of AI in Jersey's financial services sector (2026) — Principle 2 (data quality, auditability) and the illustrative scenario on process assumptions; AI Strategy in Jersey FS, Series 1 Part 3 (data readiness) and Series 2 Part 4 (foundations for scaling).

Professional disclaimer: The views expressed are my own and are shared for general informational purposes. This content is intentionally non-confidential and does not include proprietary, client-specific, or employer-sensitive information. It is not legal, regulatory, investment, or professional advice; readers should seek appropriate advice for their circumstances.

Financial services leader (20+ years) | Lean Six Sigma Green Belt | London School of Economics (LSE) AI Leadership Accelerator

A version of this article was first published on LinkedIn as part of the Sequence body of work. This is the canonical version.

The views expressed are the author's own and shared for general information. This content is intentionally non-confidential and does not include proprietary, client-specific or employer-sensitive information. It is not legal, regulatory, investment or professional advice. © 2026 Paul Soares. Sequence is the trading name of Sequence Advisory Limited (in formation) · hello@sequenceadvisory.com