Migrating an insurance core system is difficult enough. Doing it while policies are being issued, claims are being processed, and customers are still using the platform creates a different problem: how do you change the system without disrupting the business that depends on it?
Insurance systems accumulate complexity over time. A rule that started as a simple validation may eventually affect a database trigger, billing, document processing and another system. That makes the traditional approach — building a new system and switching over on a chosen date — particularly risky.
At Shaped Thoughts, we have worked with InsurTech and financial platforms where insurance core system migrations had to happen while the existing platform remained in production. Our approach is to understand the current system before defining new boundaries, move functionality in controlled increments and treat data consistency as an ongoing engineering problem rather than a final migration task.
Here are three lessons from that work.
1. Understand the domain before extracting anything
Documentation for a ten-year-old insurance core is rarely enough to explain how the system actually works. Important rules may be buried in stored procedures, database triggers, validation code or fixes added years ago that never made it into the documentation.
Consider a policy address change. In a legacy system, updating an address may trigger several downstream operations: recalculating risk, updating billing, generating documents and notifying another system. What looks like a simple database update can therefore affect several parts of the platform.
That is why we start with the people who use the system. We work through real workflows with underwriters, claims handlers and operations teams and follow what happens to a record at each stage.
For example, the transition from a Quote to a Policy may look like a simple status change. It can also change the required data, trigger validations and move ownership of the record. Downstream processes may change as well.
Map dependencies before defining new boundaries
Code and databases often contain details the documentation leaves out. Before changing anything, we use characterisation tests to see how the system actually behaves. SQL definitions and production logs are useful too. They can reveal validation rules, unusual payloads and less common workflows that never made it into the documentation.
This helps us identify dependencies that are easy to miss when looking only at the application structure. Billing and accounting, for example, may be tightly coupled to other parts of the core and difficult to move safely at an early stage. A document workflow or a specific quoting capability may have clearer boundaries.
The goal at this stage is not to extract anything. It is to understand what the existing system does, which components depend on each other and where the real boundaries are.
2. Move one capability at a time
Replacing an entire core system at once creates a difficult problem when something goes wrong after cutover. The cause could be a change in application logic, a data issue, a broken integration, or a business rule not captured during the rebuild. When everything changes at once, isolating the cause becomes much harder.
For this type of migration, the Strangler Fig pattern provides another option. A routing layer sits in front of the existing platform, allowing individual capabilities to move to new services while the remaining traffic continues to use the legacy system.
The choice of what to extract matters more than the pattern itself.
We look for a capability with a clear business boundary and manageable dependencies. Document generation might be one candidate. A quoting workflow might be another. A highly interconnected billing process is less likely to be a good starting point.
Once the new service is ready, the router can send requests for that capability to it. Everything else continues to go to the legacy platform. Users and external clients can keep using the same endpoint.
Validate before changing write ownership
The legacy platform stays in control while the new service is being tested. The two implementations process the same requests, and we can compare their results before making any changes in production. We need to understand any differences between them before the new service takes over writes or production traffic.
Feature flags and routing rules then allow us to move a specific operation to the new service without changing the rest of the platform.
Once a capability is running in production, we monitor how it behaves with real traffic. If we find differences or edge cases, we fix them before moving another part of the system. You don’t need to wait for the whole migration to finish before finding out whether the approach works.
Over time, the new architecture takes responsibility for more functionality while less remains in the legacy system. Only then does it make sense to plan removing the old components.
Each step also gives the engineering team another opportunity to test assumptions about the domain, data and integrations before taking on the next part of the core.
This kind of incremental modernisation is often more practical than replacing a live insurance platform in one go. Cloud architecture, APIs and event-driven integrations can provide the boundary between the existing core and new services, allowing parts of the platform to evolve without requiring a full cutover.
Explore our Cloud Solutions & Integrations →
3. Keep data consistent between old and new systems
Running two implementations side by side creates another problem: the data they depend on needs to remain sufficiently consistent for the migration to be safe.
Take the address example again. If the legacy system receives the update, a service that depends on the new data needs to learn about that change. Waiting for a nightly export will not work for a workflow that depends on up-to-date policy information.
We use Change Data Capture (CDC) for this. Tools such as Debezium can read changes from database transaction logs and publish them as events for downstream services. This allows changes in the legacy database to feed new services without adding more business logic to an already complicated application.
Track ownership and reconcile data
CDC does not solve the whole consistency problem, though. During a migration, we need to know which system owns a particular piece of data, how updates flow between systems and what happens when a message is delayed or fails.
That means monitoring the data pipeline and having reconciliation mechanisms in place is just as important as getting the event stream working. The migration also needs checks that can identify missing, duplicated or inconsistent data before those differences affect downstream systems.
Shadow traffic provides another way to validate a new implementation. Production requests can be processed in parallel by the existing and new implementations, with the new result recorded for comparison rather than returned to the customer.
This gives the engineering team concrete examples of where the implementations differ before the new service takes responsibility for the response.
How to modernise an insurance core system without downtime
No single architecture pattern makes a legacy migration safe. The difficult part is identifying the real boundaries in the existing system. You also need to trace the dependencies between them and decide which changes you can introduce without disrupting production.
For an insurance platform, this usually means keeping the existing core in production while introducing new capabilities around it. The legacy system may continue to own some data while other capabilities move to new services. We only change that ownership once we understand the dependencies and have tested the new service against real production behaviour.
APIs, cloud architecture and event-driven integrations can provide boundaries between the existing core and new services. They allow individual capabilities to evolve without requiring a single large cutover.
The result is a controlled transition rather than one high-risk migration event. The team can move one part of the platform at a time, validate it in production and address problems without rolling back the entire migration.
That is the approach we use at Shaped Thoughts for insurance core system migrations where taking the existing platform offline is not an option.
Planning a legacy insurance system migration?
Keeping a live core system running while moving functionality into a new architecture requires more than a migration plan. You need to understand the existing domain, establish clear service boundaries, connect old and new systems and validate each step before changing where production traffic goes.
Shaped Thoughts helps insurers modernise legacy systems through incremental migration, cloud architecture, APIs and event-driven integrations.
