Legacy Platform Modernization for a Financial Services Firm
A 12-year-old monolithic core platform was preventing a mid-size financial services firm from shipping features, scaling operations, and meeting evolving compliance requirements. We decomposed the system into independently deployable services without downtime.
94% reduction
Deployment time
6 weeks → 4 hours
40% reduction
Infrastructure cost
Right-sized cloud resources
Zero
Downtime during migration
Live traffic maintained throughout
The challenge
The client operated a monolithic Java EE application managing loan origination, risk assessment, and customer records. Deployment required a 6-week release cycle, each carrying significant regression risk. The team couldn't confidently ship new features or comply with new regulatory reporting timelines.
Objectives
- Eliminate the 6-week release bottleneck without a big-bang rewrite
- Enable independent deployments per business domain
- Reduce infrastructure costs by right-sizing cloud resources
- Meet new regulatory reporting timelines
Discovery
We spent two weeks mapping the existing system's bounded contexts, data flows, and cross-domain dependencies. Domain experts from the client's engineering and compliance teams participated in structured workshops. We identified four high-coupling pain points — customer identity, loan origination, risk scoring, and reporting — and sequenced extraction by risk and business value.
Strategy
Rather than a rewrite, we applied the strangler-fig pattern: new functionality would be built as services, and legacy domains would be extracted incrementally under live traffic. A shared API gateway provided a stable interface for consumers during the transition. Feature flags controlled cutover at the domain level, allowing rollback without deployment.
How we approached it
We designed a strangler-fig decomposition strategy — extracting bounded contexts incrementally while maintaining live traffic on the legacy system. Each service was re-platformed on Spring Boot with PostgreSQL, deployed via Kubernetes, and fronted by an API gateway. Feature flags allowed controlled cutover. The legacy system remained the system of record until each domain was fully migrated and validated in production.
Architecture
Eight independently deployed microservices, each owning its own database schema. An API gateway handled routing, authentication, and rate limiting. Kafka provided event streaming between services for eventual consistency in cross-domain workflows. Each service had its own CI/CD pipeline with automated integration tests against a shared staging environment.
Implementation
We extracted services in four phases over 14 months: reporting first (lowest risk, highest compliance value), then customer identity, then risk scoring, and finally loan origination. Each extraction included a parallel-run period where the new service processed real traffic alongside the legacy system, with output comparison to verify correctness before hard cutover.
Key decisions
Rewrite vs. strangler-fig — a full rewrite would have been faster to design but would require a maintenance window and carry higher regression risk.
We chose the strangler-fig approach, accepting a longer timeline in exchange for zero downtime and the ability to validate correctness incrementally in production.
Shared database vs. per-service databases — a shared schema would have simplified the early extraction phases but would have reintroduced coupling.
Each service owns its schema from day one. Short-term pain from data duplication was accepted to preserve the long-term architecture.
What changed
Deployment cycles dropped from 6 weeks to 4 hours. Infrastructure costs fell by 40% through right-sized cloud resources. The engineering team regained confidence to ship independently, with zero downtime across the entire migration.
Impact
The engineering team moved from 6-week release cycles to daily deployments. Compliance reporting, previously a manual 3-day process, became automated. The client could respond to regulatory changes in weeks rather than months.
Lessons learned
- 1Domain expert involvement in the extraction sequencing decision was essential — pure technical sequencing would have missed the compliance deadline.
- 2Parallel-run periods caught 11 subtle behavioral differences between the legacy and new implementations before cutover — none would have been caught by unit tests alone.
- 3API gateway adoption by internal consumers needed more upfront communication; some teams had hardcoded direct service URLs that required remediation.
“Synerfex didn't just modernize our platform — they helped us understand why it was the way it was, and what it would take to change it properly. That depth made the difference.”
Engineering Director
Engineering Director