Modernising a monolith without rebuilding everything

Almost every company that has operated software for a long time eventually wants to get rid of its monolith. It has become slow, hard to test, feared at every deployment. The first idea is usually: rebuild everything. That is almost always the most expensive and riskiest option.

The reason is simple: a monolith is not just code. It is code, data, processes, organisation and years of constraints that nobody can name any more. Trying to replace all of it at once means solving this complexity anew — with a team that is just leaving the old solution and does not yet understand the new one.

Why the big rewrite fails

Rewrites rarely fail because of technology. They fail because of:

• Underestimated business logic: What looks like fifteen edge cases in the old system is often fifteen legitimate business rules that must be rediscovered in the new system.
• Longevity of the legacy system: While the new system is not finished, the old one keeps running — and is being developed at the same time. The target moves.
• Missing value in the meantime: Months or years pass without the company seeing a measurable benefit. That erodes support and budget.
• Organisational resistance: People who work in the old system are seen as blockers, even though they are often the ones who know the exceptions.

The better way: Strangler Fig pattern

The Strangler Fig pattern does not replace the monolith in one go; it grows it out. New features are built outside the monolith, legacy pieces are gradually replaced by new implementations, and data flows through a facade or API.

The decisive advantage: every step delivers standalone value. The first new services are not architecture goals but business features. They are put into production before most of the monolith is touched.

Finding the right cut

The first step is not technical but domain-based. We model the core flows with the team and the business unit as an event stream. Often it turns out that the monolith would already fall apart domain-wise if you looked closely at the data flows. An event modeling sprint is the right starting point for that.

The next cut should:

• deliver business value that can be measured in a few weeks;
• decouple data and processes that are still stuck in the same module today;
• be low-risk — so not the most used feature first, but also not a forgotten corner that nobody cares about.

Domain-driven slices, not microservices

We deliberately do not talk about "microservices" as a goal. Microservices are an operational form, not an architecture goal. The goal is to identify domain-coherent slices that can be owned and evolved independently. Whether a slice is a service, a module or a bounded context inside the monolith is a secondary question.

These slices have three properties:

• Domain coherence: They belong to a business process, not a technical layer.
• Clear ownership: A team or person is accountable.
• Independent deliverability: Changes can be deployed without touching the rest of the system.

Data migration without standstill

The biggest challenge in modernisation is not code but data. Anyone migrating data needs a strategy for both directions:

• New write paths: Data that is newly captured lands in the new system.
• Legacy stock: Existing data stays in the monolith initially and is projected or synchronised when needed.
• Cutover: At some point the leading source switches. This does not happen over one weekend but over a controlled period in which both systems run in parallel.

Ownership and handover

A monolith that has grown over years often has no single owner. Before technology is modernised, it should be clear who is responsible for the new slices. Otherwise a new system is created that is technically cleaner but still organisationally owned by nobody.

That is why modernisation at KAIHITO is closely linked to our ownership and team setup: new slices get a name from the start, not just a role.

Short version

The big rewrite is almost always the worst option. The monolith can be modernised step by step if you find the right domain-based cut, migrate data carefully and give new slices clear ownership from the start. Then every step delivers value before most of the legacy system is touched — and the team keeps the ground under its feet.

If you want to check what your system can actually evidence today, the provability check asks ten questions about exactly that. The wider frame — from NIS2 to the EU AI Act — is collected under provability.