.avif)
This article provides a detailed look at replacing the core system during Direct's transformation.
What is a "core system" and why change it?
By core system, we don't mean a data warehouse, but the primary insurance system —a live system that executes processes for key entities: policies, partners, agents, and claims. The heart of our operations.
Direct inherited its first core. After a long debate over whether to "buy an off-the-shelf solution or develop our own," the decision was made to go our own way —partly because there is virtually no wide range of ready-made products for a universal insurance company, and off-the-shelf solutions would have forced us to adapt our business to the system, rather than the other way around.
The original ambition was modest: "We want what we have, just faster and more stable." The inherited system barely monitored anything. Users could change almost anything with minimal validation. Over the years, however, expectations shifted: it was meant to become a full-fledged information system with processes, automation, and digitization—and eventually, a potential product to sell to others.
The decision: iterative, not "big bang"
Most companies approach a replacement as a massive project: long discovery, extensive analysis and design, lengthy development, followed by adaptation and migration. Years of work behind closed doors, then a big bang.
We decided to develop the core iteratively and incrementally to give it the same agility as the rest of the development process. The reason was simple:
Every part developed delivered immediate value. Once the process for changing a client's name, phone number, or contact details was automated, we could immediately measure how much time it saved the front-line staff.
How it worked in practice
When we organized our teams by business segments in 2023, each team developed its own part of the core system. Some parts were shared (documents, communication history), while others were specific—claims for insurance settlement, contracts for administration, or sales tools for B2B. Each part added value, allowing the Product Owner to prioritize it accordingly.
The key was reframing the concept of "done": the core is done at any given moment—and yet it will never be truly finished, because we never had a final "end state" in mind. It wasn't until 2025 that we reframed the goal into a more tangible milestone: when we turn off the old core — meaning when the entire company is running on one new system.
Fast deployment = fast feedback
We got the new core to users very early—around 2021–2022, even before the value streams. At that time, it could only do one thing: search for data. But what took long minutes in the old system (leaving both the operator on the line and the client waiting) it could handle in seconds.
The trade-off: for a while, users had to operate two systems in parallel. The gain: we acquired a system that could be developed based on real feedback — and that is a huge difference compared to how such systems are usually built.
One example says it all: the customer care backlog included "we want to be able to change a phone number automatically." In the old world, that meant manually finding and rewriting numbers on all contracts. What about duplicates? What if the client has their grandmother's number in the system and verification is needed? These needs were collected, refined, developed, deployed — and the user was using them right away.
What it cost us — an honest look at rework
Iterative core development has its downsides, and it’s only fair to admit them:
- Because we wanted to deliver value early, we sometimes didn't consider enough alternatives — we built a few things ourselves instead of integrating ready-made market solutions.
- Some components had to be replaced on the fly — typically the BPM engine, which is different from the one we started with. By being able to swap it out, we also proved that we could do it.
The amount of rework was therefore higherthan if we had gone through a thorough up-front analysis. But in exchange, with every iteration, we were deploying directly into the system that will run for many years to come — we digitized the company directly in the target system, without any intermediate layers.
Market comparison: two paths to the same goal
This experience led to a public panel discussion on core system replacement, where I represented the agile approach alongside a colleague from Kooperativa, who represented the more traditional, planned one. It is not a battle of Waterfall vs. Agile — both insurance companies are solving the same problem and have a lot in common. But the contrast is instructive:
Interestingly, the end of both paths can look very similar. The difference lies in when the user receives value — and whether you reflect their needs continuously or only according to a plan that is several years old.
Five things worth remembering from this
- "Done, yet never finished." Every new core eventually becomes legacy (with a lifespan of 20–30 years). That is why it must be modular and designed for component replacement — and you need to actively manage technical debt (the 50:30:20 rule is used for this).
- Watch out for vendor lock-in. A system dependent on an aging supplier is difficult to renew.
- The core itself does not deliver value. Until you guide clients to the functionality via web and mobile, the core is only a third to half of the work. (This mistake — the expectation that "once the new core is here, everything will be solved" — cost us the most.)
- Measure value from the first iteration. For us, thanks to the transition to a more scalable architecture (the old core was licensed based on database cores), we started saving money from the very first iteration — and this aspect is even part of the business case.
Technology for interest: backend Java / Spring Boot, PostgreSQL database (chosen early, before it was mainstream), RabbitMQ messaging, frontend React and Angular depending on the application. We maintain a unified tech stack intentionally so that people can be rotated between domains without having to learn a new stack.