How we're replacing a 20-year-old core system for the Slovak Insurers' Bureau

Twenty years of change in one system

SKP runs on a legacy system with roughly twenty years of development, tweaks, added rules and the technical debt that comes with them behind it.

The system still does its job, but it's increasingly hitting its limits. With every change, it's hard to tell what it will affect. In a regulated domain that's a serious problem, because a change in legislation or process can't be built on guesswork.

The real challenge, then, was to redesign a complex domain from the ground up around what SKP and insurers actually need today, without losing the know-how held in the old system, without stopping operations, and without leaving grey areas for an audit to find. In practice, that meant five specific tasks, covered in the chapters below.

A system that can't be switched off

SKP can't afford downtime. This isn't an application you can turn off, rewrite and switch back on a few months later. Claims recovery runs continuously, payment schedules stretch over months or years, and reminders can't wait for the new system to be finished.

That's why, from the start, we also designed how the new system would safely coexist with the existing environment. We're preparing the transition module by module. We migrate data into the new system retroactively, module by module, and handle integrations by functional area of the application. The actual cutover to live operation happens all at once, at release.

Rules that existed nowhere in writing

One of the biggest risks was how scattered the knowledge of the original system was. Some rules were documented, others only lived in practice, and others only became clear once we examined specific scenarios in detail.

This showed up most clearly in the integrations. The new system has to connect to synchronous and asynchronous interfaces built more than fifteen years ago, whose behaviour was never documented. We pieced together the specification for these interfaces after the fact, combining reverse engineering with verifying behaviour against real scenarios.

In parallel, we built up a picture of the whole domain through workshops with the client. Walking through the existing screens and listing features wasn't enough. We needed to understand what happens when a regulation changes, where a claim originates, how roles and permissions work, which steps must be auditable, and where the biggest operational risks sit. The result was a shared map of the domain that let us decide what belonged in the first release, what could wait, and what needed a completely fresh design.

We also assumed from the start that even a thorough analysis wouldn't surface everything up front. Part of the business logic only became visible once the system's foundations were in place and we were working through real scenarios.

A rewrite wouldn't have solved the problem

We could have rewritten the old system in a newer technology. That wouldn't have addressed the underlying problem. So together with the client we took the harder route: a greenfield redesign of a regulated domain.

We treated the old system as a source of knowledge. It held years of exceptions, rules, decisions and practical needs. Where it answered the question "why is this done this way," it was valuable to us. Where it simply reflected historical constraints, we looked for a better way.

We took the same approach to the interface. Users spend entire days in it, so we prioritised consistency and easy orientation: one design system across every module, filterable tables wherever caseworkers deal with large volumes of records, and a personal agenda that shows every user their tasks, priorities and deadlines in one place.

Every action needs a trail

In a regulated domain, knowing that something happened isn't enough. You need to know who did what, when and in what context. That applies doubly to claims recovery. Every reminder, payment or change to a payment schedule needs a clear, traceable record that the internal team, the legal department and any audit can follow after the fact.

All key events therefore flow into a central log. Every entry records who performed an action, when and in what context, whether it's a change to a claim's status, a change to limits, or a data export. The log can be filtered and exported, so records for the internal team, the legal department and audits can be prepared easily, without needing a developer. Access to the log itself is permission-based and reserved for management and administrator roles.

The system also handles delegated case management. When a caseworker covers for a colleague, the system records who acted for whom and for what period. That helps with audits, and with day-to-day operations and resolving ambiguity.

Turning one large scope into a deliverable plan

At the outset of a large enterprise system, everything looks equally important. You can't plan delivery around a brief like that.

So together with the client we split it into areas that could be analysed, designed and built independently, and agreed what the first release had to include. The condition was that it had to be usable immediately after launch, not only once everything else was added.

It also changed how the client thinks about the project. At the start, everything belonged in phase one; after a few rounds, the client was deciding for itself which features shipped immediately and which could wait.

Delivery itself didn't follow a classic waterfall. Analysis, design and development ran in close step, sometimes in parallel. The scope was refined continuously along the way — a deliberate choice: we built new findings in as soon as they emerged, rather than a phase later, when the same change would have cost far more.

Java, Spring Boot and integration contracts

The new system is built on Java and Spring Boot, with REST/OpenAPI interfaces, clearly defined integration contracts, a well thought-out role and permission model, and QA processes and testing built in from the start of development.

What matters is that the system stays understandable, can keep evolving, and is being built as maintainable code worth investing in for the long run. SKP needs the confidence that, a few years from now, it won't be solving the same problem again, just in a more modern package.

What SKP gains

SKP gets a system that becomes the new foundation for further growth and the start of modernising the whole organisation. Claims recovery, financial administration of liabilities, payment schedules, reminders, records and correspondence, and document storage all move into one clear place instead of scattered processes.

The system also includes a personal agenda for every caseworker. Tasks such as sending a payment demand, preparing a lawsuit, or checking a payment all have an owner, a deadline and a priority, so the team sees the state of both claims and its own work.

Alongside the system, SKP now has a living specification of its key processes, an audit trail for sensitive actions, and a clear plan for what belongs in the first wave and what comes next.

The MVP was delivered on the agreed date, and the project is continuing towards full rollout. The new system respects how SKP works today, while giving it room to change processes and respond to regulation without having to work out from scratch, every time, what a change will touch.

What the project taught us

The biggest legacy projects are often held back not by old technology, but by a lack of clarity: how processes work, who owns what, what happens when rules change, and where the truth about the system actually lives.

SKP confirmed that good modernisation starts with being able to understand a domain, name its rules, and turn complexity into something a team can work with. Only then is it worth writing new code.