Before you Migrate, Discover

Written By Daniel Pears

How Data, Process, Code, and Design Documentation Discovery Changes the Equation

We have spent the last two posts mapping the problem. Migration costs in insurance are high, unpredictable, and shaped by drivers that compound in ways most business cases refuse to model. Data complexity, regulatory overhead, vendor lock-in, undocumented business logic, and the sheer organisational weight of the work. These are not risks that can be managed with a bigger contingency line and a braver project manager. They have to be addressed at the root.

So what can actually be done? Increasingly, the answer starts well before anyone opens a migration tool or types the words data mapping. It starts with discovery, but not discovery in the vague, consultancy-engagement sense, where a friendly slide deck arrives and nothing changes. Discovery as a structured, evidence-based exercise across four dimensions: data, process, code and design documentation. Each one targets specific drivers of cost. Together, they turn a migration from an act of faith or opinion into an informed programme of work, which is, historically, a better foundation.

Data Discovery: Knowing What You Have Actually Got

The data quality problem we outlined in the previous post, the duplicates, the mystery codes, the 60 to 80 percent of data that insurers themselves describe as inaccessible, does not appear at migration time. It has been there for years, accumulating in systems that were never designed to surface it. It is the loft of the organisation, full of things nobody has the heart to throw out.

Data discovery is the discipline of profiling, cataloguing and assessing that data before any migration planning begins. It answers the questions that derail projects when they are asked too late. What data do we actually hold? What condition is it in? What is active, what is historic, and what is genuinely dark? Where are the gaps, the duplicates and the transformation challenges quietly waiting to become line items?

Automated discovery tools now identify up to 40 percent more dependencies than manual documentation processes. That is not a marginal improvement. That is the difference between a migration plan built on visible reality and one built on hope. When projects involving 10 million or more records overrun 61 percent of the time, a 40 percent improvement in upfront dependency identification is not a nice-to-have. It is the single most effective thing you can do before a budget is committed. For UK carriers navigating FCA expectations around data accuracy and traceability, data discovery also builds the compliance evidence base from the start. Audit trails become a natural output of the work rather than something retrofitted in week 37 by someone staring at the middle distance.

Process Discovery: Understanding How the Business Actually Works

Migration programmes learn a particular truth the hard way. Systems do not operate the way the documentation says they do. They operate the way people have made them work over years of workarounds, exceptions and undocumented practices. The documentation, where it exists, usually describes an ideal world that ended roughly when the original project sponsor left.

Process discovery, and particularly process mining, addresses this by building a picture of actual operational behaviour from system event data, rather than from workshops and interviews that capture how people think things work. In insurance, process mining has been shown to reduce operational inefficiencies by up to 30 percent and cut claims processing times by 40 percent. Those are useful numbers, even before you factor in the value of no longer mistaking opinion for fact. The value for migration is not only in the efficiency gains. It is in avoiding the migration of broken processes. Without process discovery, organisations risk spending a lot of money faithfully reproducing inefficient workflows on a new platform. They automate somebody’s workaround from 2014, preserve a bottleneck that once had a reason, and miss the chance to rationalise before they rebuild.

The London Market’s Blueprint Two programme is, at its heart, a process transformation initiative. The 800 million pounds of projected savings do not come from moving the same processes to new technology. They come from rethinking how placement, claims and settlement actually work. The same principle applies at individual carrier level. Process discovery before migration means you move what matters and leave the rest where it belongs, which is behind you.

Code Discovery: Surfacing the Logic That Nobody Documented

This is where the tribal knowledge problem meets a practical solution. Legacy insurance platforms, many still running COBOL, RPG or heavily customised Java, contain business rules that exist nowhere else. Rating logic, underwriting thresholds, exception handling, regulatory calculations, embedded in code written by specialists who may have moved on several PAS implementations ago. PwC’s finding that 70 percent of the average insurer’s IT budget goes to maintaining legacy systems is not only a cost problem. It is a knowledge problem wearing a cost problem’s coat.

AI-assisted code analysis is changing the arithmetic. Where manual analysis of a 300,000 line system might take months, AI-driven tools can produce comparable documentation, including plain-English explanations of business rules, data flow maps and dependency analysis, in days. BCG’s recent research on agentic AI and insurance modernisation describes this capability as transformative, noting that AI agents can automatically extract business rules, generate documentation and create process maps that accelerate one of the most punishing steps of any modernisation programme.

For migration, code discovery does two critical things. First, it creates a validated inventory of what the legacy system actually does. Not what people think it does, not what the original specification said it should do, but what it actually does today in production, with all its accumulated exceptions. Second, it provides a target-state reference. When you know exactly which logic needs to be reproduced, and which needs to be deliberately changed, you remove the ambiguity that causes scope creep, rework, and the sort of mid-programme surprises that push projects into the 83 percent failure category.

Design Documentation Discovery: Mapping the Architecture Before You Change It

The final dimension is the most often overlooked, and it is the one that ties everything else together.

Legacy insurance estates are not single systems. They are ecosystems. Policy administration platforms connected to claims engines, connected to billing systems, connected to regulatory reporting tools, connected to broker portals, connected to reinsurance interfaces. Many of these connections are undocumented. Some are understood only by the integration middleware managing them, which is cheerful in its own opaque way. Others exist as point-to-point interfaces built years ago to solve a specific problem and never formally recorded by anyone still in the building.

Design documentation discovery maps this architecture as it actually exists. It identifies every system, every integration, every data flow and every dependency, creating the enterprise-level visibility migration programmes need but rarely have at the outset. When BCG describes modernisation programmes being stymied by massive data sets, system dependencies, and product, market and regulatory variations across jurisdictions, this is the complexity they mean. It is complexity that can be mapped, understood and planned for, provided the discovery work happens first.

In the London Market, DXC’s migration of 70 billion rows of data and more than 200 business applications was not, at its core, a data migration exercise. It was an architecture migration exercise. Understanding what connects to what, and why, is the precondition for moving anything safely. Everything else is optimism.

The Compounding Effect of Discovery

What makes these four discovery dimensions powerful is not only what each one reveals individually. It is how they interact.

Data discovery tells you what you are carrying. Process discovery tells you how it is being used. Code discovery tells you what logic governs it. Design documentation discovery tells you how it all connects. Together they create a comprehensive, evidence-based picture of the legacy estate, which is the kind of picture that turns a migration from a high-risk programme into an informed, staged, controllable one.

The organisations getting this right are not necessarily the ones with the biggest budgets. They are the ones investing in understanding before committing to action. Running short discovery sprints, mapping business workflows, converting them into decision tables and acceptance tests, and validating against actual production behaviour. Creating what some practitioners call a living behaviour spec, a record of what the legacy estate really does before anyone tries to change it. Unfashionable work, by some measures. Also the work that keeps programmes out of the industry folklore pile.

With 74 percent of insurance companies still reliant on outdated technology, and the global policy administration market heading toward 31.6 billion dollars by 2032, migration is not a question of if. It is a question of how prepared you are when the moment arrives.




Starting the Conversation

Metamorphic was built on a straightforward conviction. Legacy systems are not the enemy. They hold the business logic, the decisions and the institutional knowledge that made companies successful in the first place. The challenge has never been to destroy and replace. It has been to understand what is there and make it usable.

Discovery across data, process, code and design documentation is how that understanding happens. It is not a phase that precedes the real work. It is the real work. It is what determines whether a migration programme delivers on its promise or joins the majority that do not.

If any of this resonates, whether you are early in thinking about a migration, deep in one that is proving harder than expected, or simply trying to get a clearer picture of what your legacy estate actually contains, we would welcome the conversation. No hype. Probably some awkward truths. The coffee is on us.



‍ ‍References and Sources

Dan Pears is a solution architect and co founder of Metamorphic Services. His work sits at the intersection of legacy systems, data, and the very human reality of organisational change. After years spent helping large enterprises modernise the right way, he now focuses on making AI useful rather than theatrical. He writes about technology with one simple belief in mind: transformation starts with understanding, not disruption.

Daniel Pears
Next

What's Really Driving the Cost of Insurance Migration?