Navigating Legacy System Migration in the London Market

Jun 30, 2026 Data Advisory, Data Migration

Data migration is often described as a technical exercise – a project for the IT department, with the business brought in for sign-off. In reality, it is just as much a business challenge as a technical one. In the London Insurance Market, it is even more so.

Move records from system A to system B, transform the data to fit the target data model, test, reconcile, go live. Simple enough on paper. But in the London Insurance Market, that plan tends to fall apart quickly. The systems are fragmented, the processes are inconsistent, and the data is far more complex than it first appears. Projects run over time and over budget – often before the real work has even begun.

Most of the problems that cause this are not technical. They come from business processes that were not fully understood, complexity that was not anticipated, and decisions made too early with too little information. Organisations that get migration right usually recognise this from the start. Those that do not tend to find out the hard way, somewhere in the middle of delivery.

A market that does not map cleanly

London Market claims are structurally more complex than in most other insurance environments. A claim may be processed through central Bureau systems or handled entirely outside them – and these two paths produce fundamentally different data flows and structures. A single organisation may operate multiple source systems for claims. Data for one logical claim can be split across those systems, sometimes with different or outright conflicting values. One claim in the legacy world can map to multiple records in the target, particularly when financial structures diverge.

What looks like a straightforward mapping exercise, quickly becomes something closer to interpretive work. For each field – date of loss, claim status, financial reserves – teams must determine which system holds the authoritative value. Sometimes a data exists in only one system and has to be pulled from there regardless. Other times, claims that span multiple systems need to be matched and merged, with different fields sourced from different places – financial data, for instance, is often (in London Market set up) held separately from the claims handling record entirely. The answer is rarely obvious, and it is almost never the same twice.

The data quality problem nobody budgets for

Alongside structural complexity sits a more mundane but equally damaging problem: data quality. Legacy systems in the London Market frequently hold data that was never designed to be migrated anywhere. Critical claims information often lives in manual files – spreadsheets tracking complaints, legal actions, or watchlist statuses – maintained outside any governed system. These lack standardisation, contain inconsistencies, and frequently rely on free-text fields that carry meaning only to the person who wrote them.

Legacy systems introduce further complications of their own:

Historical records may simply not exist – messages and activity logs captured only after a certain system implementation, leaving earlier claim histories incomplete.
Data inconsistencies between systems caused by poor synchronisation or write-back architecture, where updates made in one system never reliably propagated to another.
Records that technically exist in the database but are invisible in the user interface – logically deleted claims that surface only during extraction.

Each of these forces teams to make inclusion and exclusion decisions before the migration logic can even be designed. It is not uncommon for this scoping exercise alone to generate documentation running to dozens of pages – simply to establish what should be migrated at all.

Why projects are consistently underestimated

Migration projects in this space are easy to underestimate – and for reasons that are not always obvious until you are already in them. It is rarely down to negligence. It comes from a structural gap between what is known at the point of estimation and what the work actually turns out to require.

Three root causes recur with enough consistency to be worth naming.

The first is lack of domain knowledge. Teams often begin migration planning without deep familiarity with London Market-specific processes and system behaviours. Estimations fail because the estimators do not yet know what they do not know. A common example: a project scoped around two source systems and two claim types, where the estimator did not know at the outset that one claim type could exist in both systems simultaneously. In the London Insurance Market, it is standard practice for Bureau claims to hold financial data in the main financial system rather than in the Writeback – but without that market knowledge going in, it simply does not appear in the scope.

The second is unknown data models. Even when the systems involved are known, their underlying structures are not always well understood – even by the people using them. Some legacy systems behave unpredictably, store information in non-obvious ways, or contain undocumented quirks that experienced users have learned to navigate without ever articulating. Without this knowledge embedded in the project team early, solutions get designed on incorrect assumptions and require significant rework when reality asserts itself.

The third is a persistent misconception about what drives effort. The assumption that migration complexity scales with record volume is intuitive but wrong. In practice, complexity is driven by the rules – the mapping logic, exception handling, and conditional logic required to transform data correctly. It is also driven by the number of source systems and claim types involved, because each combination can require its own mapping to be defined for the same field. Migrating 30,000 claims can require nearly the same design effort as migrating 600,000, because the underlying rules are the same regardless of how many records flow through them. This is worth understanding early, because it changes the conversation with the client – if the effort is similar either way, it is worth asking whether migrating a small volume of historical claims is actually worth it, or whether a different approach makes more sense.

The configuration trap

One of the more consequential decisions in any migration programme is whether to run migration and system configuration in parallel. It can seem like a reasonable efficiency measure and in some ways it is. But it comes with a trade-off: the target data model keeps changing.

Every configuration update can invalidate previously defined mappings, forcing rework across multiple components simultaneously. Teams find themselves in a cycle of designing, building, and then redesigning as the ground shifts beneath them. The work is not wasted in any single iteration, but the cumulative cost of continuous rework can be substantial.

An alternative approach – less common but worth serious consideration – is to sequence deliberately: stabilise the target system configuration and data model first, then design and execute the migration. This extends the overall timeline, but it typically improves predictability and reduces the kind of late-stage rework that causes the most damage to delivery confidence and team morale.

What good migration actually looks like

Successful migrations in this environment tend to share a few characteristics that are easier to describe than to execute.

Strong business involvement is the most consistently important factor. A knowledgeable product owner or domain expert – someone with genuine claims experience, not just a stakeholder slot in the governance structure – is essential. Not for sign-off, but for co-creating the rules that no analyst can derive from system documentation alone. This role requires both deep process understanding and the analytical patience to work through ambiguity carefully, not just resolve it quickly.

Clear documentation matters more in migration than in almost any other delivery context. Scope definitions, field-level mapping rules, exception handling logic – without exhaustive documentation, decisions get lost, inconsistencies compound, and traceability disappears. Teams that underinvest here consistently find themselves relitigating the same questions six months into delivery.

Iterative discovery is also essential. Even with strong upfront planning, edge cases will emerge throughout execution. The teams that handle this well build continuous refinement into the rhythm of delivery rather than treating it as a deviation from the plan. They expect to find things they did not expect.

Finally, experience with the specific source systems involved dramatically accelerates delivery. Knowing how a system actually behaves – not how its documentation says it behaves – allows teams to identify issues early and avoid building on incorrect assumptions. This is harder than it sounds: many legacy systems simply do not have a data dictionary or any meaningful technical documentation. Knowledge lives with people, not in files.

Testing is the other area that is easy to underestimate. Every mapped field needs to be tested – not just once, but against each individual rule. If the logic says "if date of loss is null, take the inception date instead," there needs to be a real claim in the test population where that field is actually null, so the rule can be verified in practice. The same applies to source conditions: if only open activities are being migrated, or only the most recent activity for claims closed more than five years ago, each of those conditions needs a test case of its own. Every data transformation needs to be covered.

This is a significant amount of work. But finding an error early is far less costly than finding it late. Every fix made after the fact has to be applied in multiple places, and every change carries the risk of affecting something else downstream. Thorough testing, done early and systematically, is not a quality gate at the end of the project – it is one of the most important workstreams running through the middle of it.

Migration as a knowledge problem

Perhaps the most useful reframe is this: data migration in the London Market is not primarily a technical challenge. It is a knowledge problem.

Knowledge of business processes. Knowledge of systems that are often niche, poorly documented, and understood only by people who have worked with them for years. Knowledge of the historical decisions and workarounds that shaped how data was captured in the first place.

Where that knowledge is present – and effectively integrated into delivery – migration becomes manageable. Complex, demanding, but manageable. Where it is absent, even well-funded projects with strong technical teams struggle to deliver what was promised.

For organisations planning a London Market migration, the implication is clear: the investment required to understand the business and its data is not a precondition to the real work. It is the real work.