Java monolith to microservices modernization

Context

Aseguradora Continental Mexico runs its policy-issuance and claims core on a Java monolith (version 8) over 12 years old, with nearly 2.8 million lines of code in a single repository. The system is critical — running 24/7, managing policy issuance, premium calculation, and claims management — but every deployment required a nighttime maintenance window and any small change needed full regression testing.

The challenge

• 3-4 week deployment cycles for any change, even minor tweaks.
• One large team, no clear module ownership — any developer could break unrelated functionality.
• Implicit dependencies and hidden coupling between the issuance and claims modules, undocumented.
• Java 8 at the end of its extended support cycle, with libraries carrying known vulnerabilities with no available patch.
• High risk of a "big bang" migration: the system couldn't stop or degrade during the process.

The solution: incremental modernization with the Strangler Fig pattern

Instead of a full rewrite, the team adopted a gradual extraction strategy, backed by AI tools to speed up legacy-code analysis.

APPROACH

• AI-assisted dependency mapping: before touching code, a real coupling map of the monolith was generated (not the documented one, the one actually existing in the code), identifying which modules could be extracted first with the least risk.
• Strangler Fig pattern: an API Gateway was placed in front of the monolith; each business capability (quoting, issuance, claims management, billing) was extracted one at a time as a Java 21 microservice, gradually redirecting traffic without shutting down the original system.
• Low-risk first: started with customer-facing features (policy status inquiry, notifications) to gain experience before touching the transactional issuance core.
• Assisted code generation: for lower business-complexity modules, an AI assistant generated the microservice's base scaffold (OpenAPI contracts, Spring Boot skeleton, initial unit tests), always with human review and approval before integration — no generated code went out without a senior developer's validation.
• Data: each microservice adopted its own database; synchronization with the monolith during transition via Change Data Capture (CDC), avoiding error-prone dual writes.
• Asynchronous messaging: events via Kafka between extracted services and the remaining monolith, to decouple without breaking business consistency.

Results at 10 months

Metric	Before	After
Deployment frequency	Every 3-4 weeks	Several times a week
Cycle time (commit to production)	~18 days	~2 days
Production incidents per deploy	Base 100%	-54%
Modules extracted as microservices	0	7 of 12 domains
Automated test coverage	22%	68% (extracted)

The system never stopped operating during the transition; modules not yet extracted still run in the monolith, now isolated behind the API Gateway, without blocking progress on the rest.

Key success factors

• Never "big bang" — the Strangler Fig pattern allowed progress without risky maintenance windows or stopping the business.
• Start with the lowest risk to build confidence before touching the transactional core.
• AI as an analysis and scaffolding accelerator, not a replacement for human judgment — all dependency mapping and generated code went through architect and senior-developer review.
• Explicit API contracts (OpenAPI) from the first extracted service, avoiding recreating the monolith's hidden coupling in the new architecture.

Lesson to replicate

Modernizing a critical system isn't won by rewrite speed, but by reducing the risk of each step — extract, validate, deploy, repeat — with AI tools accelerating analysis and scaffolding, but never replacing human validation on a system the daily business depends on.