The Challenge
A regional financial institution faced a formidable challenge: its 40-year-old core banking monolith hindered agility and innovation. The antiquated system struggled to keep pace with customer expectations and regulatory changes, which necessitated frequent updates and posed significant operational risks. The complexity of the monolithic architecture led to high maintenance costs and limited the bank's ability to launch new digital services efficiently.
Regulatory compliance was another pressing issue. The outdated system was not conducive to meeting modern compliance standards, increasing the risk of regulatory penalties. Additionally, the institution aimed to enhance its customer experience by offering real-time, personalised banking services, which the legacy system could not support.
The Solution
To address these challenges, Adyantrix was brought on board to overhaul the core banking infrastructure. Our team proposed a comprehensive migration from the monolithic architecture to a cloud-native, event-driven microservices architecture. This modernisation effort aimed to deliver agility, scalability, and resilience for the bank's operations.
We began by conducting a detailed analysis of the existing system and defining a microservices strategy tailored to the bank's requirements. This involved decomposing the monolith into discrete, independently deployable services, each responsible for specific banking functions. We utilised domain-driven design principles to ensure that these services aligned with business goals and facilitated seamless interaction through APIs.
The migration process also leveraged cloud platforms to enhance the scalability and reliability of the new system. Our DevOps team ensured continuous integration and deployment pipelines were established, thus accelerating development cycles and enabling rapid deployment of updates.
Key Results
With the transition to an event-driven microservices architecture, the financial institution achieved transformative results. System agility saw a marked improvement, allowing for swifter response to market changes and enabling the bank to launch new digital products up to 50% faster than before.
Operational costs decreased by approximately 30%, as the streamlined architecture required less maintenance and reduced dependency on legacy technologies. Additionally, the new system's ability to support real-time processing meant enhanced customer experience, with a 25% reduction in transaction processing time.
Regulatory compliance was brought in line with current standards, mitigating the risk of penalties and enhancing trust with stakeholders. The bank now enjoys a future-proof, scalable system that positions it competitively within the rapidly evolving fintech landscape.
Ultimately, our approach not only resolved the immediate issues of a cumbersome legacy system but also laid the foundation for future growth and innovation, truly revolutionising the bank's core operations.
Technical Approach
Decomposing a 40-year-old COBOL and PL/I monolith into a cloud-native microservices architecture is one of the most technically demanding categories of enterprise software engineering. The Adyantrix team applied a structured approach grounded in domain-driven design (DDD) and the strangler fig migration pattern to de-risk the transition:
Domain identification and bounded context mapping: The first step was understanding the monolith's internal structure — a non-trivial task given that 40 years of accumulated business logic had produced a codebase with deeply entangled responsibilities. The team conducted a series of event-storming workshops with the bank's domain experts to map the key business events (AccountOpened, TransactionPosted, LoanDisbursed) and identify the bounded contexts that would become the boundaries of the new microservices.
Technology stack selection:
- Java 17 with Spring Boot 3 for service implementation, providing a mature, well-supported framework with strong support for reactive programming patterns.
- Apache Kafka as the event streaming platform, providing durable, ordered event logs that served as the communication backbone between services and the audit trail required for financial regulatory compliance.
- PostgreSQL for services with relational data requirements (accounts, customers, products); MongoDB for the notification and preferences service where document-oriented storage was more natural.
- Kubernetes on AWS EKS for container orchestration, providing the self-healing, auto-scaling capabilities essential for a financial system with strict uptime requirements.
- AWS API Gateway as the externally facing API layer, handling authentication, rate limiting, and routing to internal services.
- HashiCorp Vault for secrets management, ensuring that service credentials, encryption keys, and API tokens were never stored in code or configuration files.
Strangler fig migration: Rather than a big-bang cutover — which would have been commercially unacceptable for a live banking system — each domain was extracted incrementally. A facade layer intercepted calls to the legacy monolith and progressively routed them to the new services as each domain reached production readiness, with the monolith handling the remaining domains until full migration was complete.
Implementation Highlights
The migration was structured across four phases spanning 18 months:
Phase 1 — Customer and account services (months 1–5): The customer profile and account management domains were prioritised for first extraction, as they had the cleanest internal boundaries and were the prerequisite for all downstream services. A read-replica of the legacy customer database was maintained in sync with the new customer service throughout the transition, providing a fallback path if issues arose.
Phase 2 — Transaction processing (months 4–10): Transaction processing was the most technically demanding domain, as it required guaranteed exactly-once delivery semantics for financial postings — a fundamental requirement given that double-posting a transaction has direct financial consequences. The team implemented the outbox pattern: every transaction command was written to a PostgreSQL outbox table within the same database transaction as the business record update, and a dedicated relay service consumed from the outbox and published to Kafka, guaranteeing that every committed business event was eventually published to the event stream.
Phase 3 — Lending and products (months 8–14): The lending domain introduced additional complexity due to the regulatory capital reporting requirements that attached to every loan origination and repayment event. The team worked closely with the bank's compliance and finance teams to ensure that all regulatory reporting hooks were preserved and that the new event schema supported the data extracts required for IFRS 9 provisioning calculations.
Phase 4 — Decommissioning and hardening (months 14–18): Once all domains had been migrated, the legacy monolith was progressively taken out of service. This phase also included comprehensive performance testing under simulated peak load conditions, penetration testing of the API gateway layer, and a full disaster recovery rehearsal.
Throughout the migration, a feature flag framework allowed new service endpoints to be deployed to production in a disabled state and activated incrementally — first for internal testing users, then for a small percentage of live traffic, then for full production volume — with the ability to roll back to the legacy path within minutes if issues arose.
Measurable Outcomes
The quantified outcomes of the modernisation programme were assessed at the 12-month post-migration mark:
- New digital products launched 50% faster, measured as the time from business requirements sign-off to production deployment for three new product launches in the post-migration period, compared to the last three product launches under the legacy system.
- Deployment cycles reduced from quarterly releases to daily deployments, enabled by the CI/CD pipelines and the elimination of the monolith's release coordination overhead. The engineering team moved from 4 production deployments per year to over 200.
- 30% reduction in operational costs, driven by the elimination of expensive legacy hardware maintenance contracts and the move to consumption-based cloud infrastructure pricing.
- 25% reduction in transaction processing time, as the event-driven architecture processed transaction postings asynchronously and in parallel, compared to the synchronous, serial processing of the legacy system.
- System availability improved from 99.1% to 99.95% measured over the first full year of post-migration operation. The improvement was primarily attributable to the fault-isolation properties of the microservices architecture — a failure in the notifications service no longer caused the transaction processing service to degrade, as it had under the monolithic architecture.
- The bank successfully passed its annual PRA/FCA regulatory technology assessment without findings related to core system capabilities for the first time in six years.
Lessons Learned
A legacy core banking migration of this complexity generates hard-won insights that apply to any financial institution considering a similar transformation:
- The strangler fig pattern is not optional for live banking systems. The temptation to plan a clean-room rebuild and big-bang cutover is understandable — it is architecturally simpler to reason about — but the commercial and regulatory risk of cutting over a live banking system in a single event is unacceptable. The strangler fig approach, whilst more complex to manage, allows risk to be distributed across many small transitions rather than concentrated in a single high-stakes migration event.
- Event sourcing and the outbox pattern are essential for financial systems. The exactly-once delivery requirement for transaction events is non-negotiable in banking. Standard at-least-once Kafka delivery semantics are insufficient; the outbox pattern is the correct solution and must be designed in from the outset rather than retrofitted.
- Domain-driven design workshops are an engineering investment, not a process overhead. The event-storming workshops at the outset of the project consumed approximately six weeks of senior engineering and domain expert time. That investment paid back many times over by preventing the most costly mistake in microservices migration: drawing service boundaries incorrectly and discovering the need to redistribute responsibilities between services during the implementation phase.
- Regulatory compliance requirements must be modelled as first-class architectural concerns. Financial regulation is not a constraint to be accommodated after the architecture is designed — it must be woven into the domain model from the first workshop. Data lineage, audit trails, and regulatory reporting requirements influenced service boundary decisions on this project in ways that would not have been visible without early regulatory engagement.
Why This Approach Worked
The modernisation succeeded because it was grounded in a clear-eyed assessment of risk and a deliberate strategy to distribute that risk rather than concentrate it. By migrating one domain at a time behind a strangler fig facade, the bank was never more than a configuration change away from reverting to the legacy system for any given function — a safety net that gave the engineering team the confidence to move quickly without recklessness.
The event-driven architecture was the right foundational choice for a financial institution because it aligns naturally with how banking actually works: as a sequence of immutable business events (deposits, withdrawals, transfers, loan disbursements) rather than as a mutable state database. By making events the primary record and deriving current state from the event log, the architecture simultaneously solved the audit trail, regulatory reporting, and system integration challenges — three problems that the legacy monolith had addressed with three separate, poorly integrated mechanisms.
Speak with our Custom Software Development team at Adyantrix to find out how we can support your next project.
Work with Adyantrix
If you are looking to tackle a similar challenge, Adyantrix has the expertise to help across the full project lifecycle. Our custom software development practice covers tailored applications built to your exact workflows. Our cloud & DevOps practice covers cloud infrastructure, CI/CD, and platform engineering. Our IT consulting practice covers technology strategy, architecture review, and digital transformation advisory. Our data engineering practice covers pipeline design, streaming, and data infrastructure. Get in touch to discuss your requirements — no commitment required.
