Juan Pablo Gallegos → Work → Galicia Seguros
Galicia Seguros
Owning the seam between a modern interface and a mainframe that wasn't going anywhere.
What changed before the long read
The case is about making a modern insurance experience possible without pretending the legacy core could move.
Context
Galicia Seguros ships insurance products through one of Argentina's largest banks. The new products needed a modern purchase and management experience.
Everything underneath them — policy issuance, billing, customer-of-record — lives in decades-old Java core systems that were not being replaced and were not going anywhere.
Problem
A modern frontend and a legacy mainframe speak different languages: different data shapes, different latency profiles, different failure modes.
Letting the frontend talk to the core directly would either freeze the interface to the mainframe's contracts or push a pile of integration complexity into the browser. Neither was acceptable for a bank-grade product.
Constraints
The legacy core was immovable and authoritative — it owned the truth, and it would not change to suit us.
Bank-grade reliability and audit requirements applied to everything that touched a policy.
Three products to ship, a team of four, and a fixed timeline.
Role
I was technical lead for a team of four. I owned the architecture of the seam between modern and legacy, set the team's working conventions, and stayed close enough to the code to own the hardest integration points myself.
System shape
A backend-for-frontend sits between the modern clients and the legacy core and brokers every conversation between them:
The BFF translates between the UI's task-shaped contracts and the mainframe's record-shaped ones, aggregates several legacy calls into a single client request, and isolates legacy quirks — encodings, session semantics, error codes — so they never surface in the frontend.
An anti-corruption layer keeps the legacy data model from leaking into the modern domain; the old shapes are translated at the boundary and stop there.
Key decisions
One service owns the legacy contract, so the frontend stays clean and the immovable core stays untouched.
The BFF exposes "buy this policy," not "call these six mainframe transactions in this order." The client speaks intent; the BFF handles the choreography.
Legacy data models are translated at the boundary and never leak inward, so the modern domain stays coherent regardless of how the mainframe is shaped.
Trade-offs
Gained
- The frontend evolves without ever touching the mainframe
- Legacy weirdness is contained in a single service
- Three products shipped on shared, repeatable infrastructure
- Clear contracts the team of four could build against in parallel
Cost
- An extra service to run, monitor, and own
- A BFF can become a dumping ground without discipline
- The team needed shared conventions to keep it coherent
Outcome
Three insurance products are live at the bank, running on top of legacy systems that never had to change. The seam held under bank-grade requirements, and the team shipped all three on shared infrastructure they could reuse.