Incremental overhaul of a contract management monolith

Context

A contract and claims management application developed over fifteen years, monolithic, with a single database of more than four hundred tables. Three teams shared the same codebase, with quarterly releases and test coverage limited to the most critical journeys.

Problem

Every regulatory change triggered production regressions and required two to three weeks of manual acceptance testing. Business rules existed only in the code, and peak load on the customer portal degraded end-of-day batch processing.

Objectives

• Restore monthly delivery capability with no production regressions
• Isolate batch processing from customer portal traffic
• Document critical business rules with executable tests

Role

Architect and lead developer on the first extracted scope, with an explicit objective of transferring knowledge to the internal teams from the third month onwards.

Solution

The work started with a safety net: two hundred and forty acceptance tests written against the observed behaviour of the most sensitive journeys and executed on every release. A technical seam was then introduced into the monolith to progressively route calls to new components without touching the rest of the code. The first extracted domain was contribution schedule management, chosen for its low coupling and business criticality. The new service ran in parallel with the legacy process for six weeks, with automatic comparison of results on real anonymised data. That period surfaced eleven undocumented edge cases, all handled and covered by tests before the switchover. Deployment was done service by service with a configuration-driven, reversible switch. At the end of the engagement three domains were extracted and a fourth was underway, with an internal team autonomous on the approach.

Architecture

The existing monolith remains as the foundation for stable business rules. Extracted domains are standalone Spring Boot services exposing an internal REST API and publishing events to Kafka for other modules. Each service owns its own PostgreSQL schema, migrated with Flyway, and never reads another service's tables directly. An application gateway preserves historical entry points during the transition and progressively routes traffic. Observability relies on OpenTelemetry, with a correlation identifier propagated from the portal down to batch processing.

Results (samples)

• Three domains extracted and running in production, a fourth underway
• Delivery cadence moved from quarterly to monthly
• Acceptance tests executed automatically on every release
• Batch processing isolated from customer portal traffic peaks

Indicators (samples)

• Manual acceptance duration per release

  15 days to 4 days

  Figure from a simulation exercise — demonstration sample

• Automated acceptance tests

  240

  Illustrative volume on a simulated scope — demonstration sample

• Domains extracted from the monolith

  3 of 12

  Scope deliberately limited to a first batch — demonstration sample

Technologies

• Java
• Spring Boot
• Angular
• PostgreSQL
• Flyway
• Apache Kafka
• Docker
• Kubernetes
• OpenTelemetry

Related services

• Software architecture and technical framing

  I design and review application architectures that match your real team, timeline and operations constraints. You get a reasoned target split into deliverable stages, not a two-hundred-page document.

• Legacy application modernisation

  I evolve legacy applications through controlled stages while production stays live. The goal is not to rewrite everything, but to take back control of a system you no longer dare to change.

• Java and Spring Boot back-end development

  I design and build robust business services with Java and Spring Boot, tested and observable from day one. The delivered code is readable, documented and easy for your team to take over.

• Observability and application performance

  I make your applications diagnosable: correlated traces, useful metrics and alerts that signal a real problem. You move from interpreting symptoms to identifying the cause.